AJAX & DOM Scripting: Just Build It

This is so true. It’s tough to convince clients to go this route still, but getting your hands dirty is truly the best (and often fastest) way to figure out if something is going to work.

Good article. I fully agree. In fact I feel the same about web design in Photoshop. Lately I find myself only doing the most important stuff in Photoshop and get to the HTML without ever having a 100% perfect PS engineered ‘preview’. Therefore I believe these principles also apply to common webdesign and not just AJAX stuff. If I had to do a ‘preview design’ for a client I can probably finish a real HTML one in the same time in which I’d create a pixel perfect Photoshop mock up.

Especially with Rails, it’s almost quicker to go in and prototype the actual running application than it is to construct storyboards, diagrams, and user scenarios. While those still have their place, depending on the application, in some cases a team can get just as far by talking about how it should work, interacting with the application, and then evaluating how the running application behaves.

Wireframes and storyboards become necessary, IMO when the project involves more people. I find it easy to ‘just do it’ based on what I have in mind when I am working by myself, but I believe it would be mayhem to follow the ‘hands on approach’ if you have to work as a team.

What to do then?

I normally mock together and animate the interface and application in flash.
Its the fastest for me personally and its then easier to demonstrate my ideas to the developer.

Back in the 90’s it was quicker to mock up (as well as use a WYSIWYG), but I’m thinking that web technology has become so elegant, what with CSS and Standards, that it’s hardly any more investment of time to jump to the build phase.

Tell it Garrett!

Pretty dangerous approach, Garrett. I know this approach is getting a lot of hype lately, but this attitude, taken verbatim, is largely what contributed to so many bad applications in the first place. This attitude is why Microsoft’s products are usually so miserable in the first couple of versions. The new wave of smaller teams with smaller products has a lot of wonderful advantages, but ignoring everything that makes software design effective is often just going to result in smaller bad applications.

I agree that functional specifications are useless. But I don’t think this is the right solution either. You’re just going from one extreme to the other without coming up with something that might actually be more effective than either approach.

Using the product as the spec is dangerous because it means that, much like Microsoft and many other companies, you’re relying on snap judgements while coding to decide how things are going to work in the end product instead of relying on legitimate user research, and you’ll likely still end up sticking to a bad idea because it took you valuable time to code.

Also, you say that you shouldn’t waste time on wireframes and storyboards because, ultimately, you just throw them away. But that just lands you in a different trap. If you code an application like it’s the final version up front, you spend a lot of time coding something that you still don’t know will work. If you write “prototype code”, you still have to throw it away. (Please, don’t ever put prototype code in a final product.) Either way, you end up “wasting” time.

But is it really a waste to throw away something that took 3 hours to create, but effectively showed users and clients (and you) how the tool might work, as well as flesh out ideas and bring to light potential problems? Or is it more of a waste to spend 4 days coding something that ends up being wrong?

Prototypes are the smart way to go. They have the benefit of being quick to build and quicker to revise. They give you something to show clients, as well as users. They give you something you can run through user tests. They show you where problems might come up. Writing production code up front is vvery dangerous, as it runs a high risk of being a huge waste of time and money.

One final note: It seems strange that a guy who offers Visio and Graffle stenciles and templates on every page of his web site would advocate ignoring these thigns and going straight to code. Are you changing your approach? (This isn’t an insult in any way – just curious about your process). (The templates and stencils are great, by the way.)

Seems to me that, instead of throwing away a great process, we need to invent better ways to storyboard AJAX apps, and quicker ways to prototype such tools. Let’s get to work on that instead of falling back into the same old mistakes.

The sooner you start running that interface through the real test of being used, the sooner you end up with accurate feedback and the correct interface.

Thanks for the clarifications. I agree with the preceding statement completely, but I do still think it’s more wise to start with something quick and easy to create that you can afford to throw away. Once you have your ideas solidified, then definitely move to the code and get something real in front of users. I’m all for iterative design – it’s a great way to leverage the benefits of the fact that your software is web-based – I just think something needs to come between project definition and product. Prototyping is not the perfect solution in many cases, but it does serve to illustrate ideas and incite more effective communication.

In cases where larger teams are involved, perhaps on larger-scale applications, going straight to code means programmers are in the driver’s seat. In those cases, it’s wise to put skilled designers into position and let them do what they do best, leaving programmers to do what they do best. If you’re designing and building an application yourself, or with just a couple other people, then going straight to code is more feasible. Time will tell if this is the right approach for great web-based applications.

No solution is perfect all the time. With that in mind, statements like “just build it” can be dangerous. A more appropriate statement might be one more like what (good) programmers often say: “Use the right tool for the job.” Sometimes your way will work, sometimes not.

At any rate, I do appreciate your great insight most of the time, so please don’t think I’m on a witch-hunt. I’m only interested in presenting another angle. Doctrines can be dangerous, regardless of how correct they sound. This post just happened to be the most recent on the subject to catch my eye. No offense intended. Even though I don’t agree in this case, I am happy to see user-experience issues taking a front seat. It’s about time.

I agree with your sentiments that evolving an interactive prototype in lieu of wireframes/storyboarding increases efficiency, garners feedback quicker, and many other benefits. But I’m suspicious that you’d abandon documentation altogether for many of the same reasons espounded by other comments.

Perhaps wireframing as a skill should also evolve in tandem with the sophistication of the experiences they depict. Just as UI designers move away from thinking in “pages” and single Visio files, so should their artifacts, particularly for IA/UI/ID resources not nearly as adept as you in the art of prototyping (although I, like you, advocate your concept of a FEA).

I’ve found incredible efficiency in modularizing artifacts from flows to pages to components (a group of related elements) to specific elements – all in separate files – and then including each as necessary into multiple variations of something further up that hierarchy (much as you’d have nested includes of HTML). For example, if you’ve got a nav bar, header, table, etc, separate those as individual components, creating variations of each one and combining them purposefully into a single illustration of a page’s state at a given point in time.

Such an approach enables one to quickly create countless variations of components or pages to illustrate changes in data, state & display conditions within a richer client experience. Down the road, design spec then becomes far more fill in the blanks and quicker to execute because the illustrations tell so much of the story. Sure, it’s storyboarding, but utilizing the tools at a different level so that storyboarding is rapid and scalable.

Admittedly, you’ve gotta be dogged about reuse (use it twice? then extract it into a separate file) and a pretty efficient illustrator to be successful.

But the key is mastering File > Place (in Adobe Illustrator/InDesign, my preference) or Insert > Object > Create From File (Visio), and then cropping as necessary as you create 2+ variations per component in a single file.

PS: Love your articles & commentary!

“Just Build It!”. I love the phrase already. I totally agree with your points, and I hope to soon follow in your footsteps by publishing similar thoughts.

I agree with Nathans point that UI designers too often think in terms of page metaphors rather than behaviors. It reminds me of another generation when CD-ROM designers applied those paradigms to websites, with predictably disastrous results.

To Garrett’s point, every once and a while, you have a client who just needs to see it, for whatever the reason. But I think the primary dichotomy is between speed and veracity.

This is where I drag out the John Henry bit. No matter how sophisticated the tool, I can do five versions on a whiteboard in the time you can do one as a clickable prototype, and many more in the time it takes to do something on the computer that a client would accept a bill for.

Clients are always afraid that what they are looking at is what they bought – if you make it too real, it is common for them to be distracted by the specifics & ditch a good concept along the way. I find that whiteboard or pencil sketches allow the conversation to focus on the ideas, not just the colors.

I think the real problem is slow wireframes. There is no merit to taking a long time with these. At PFA we make them in Keynote or Powerpoint. As Garrett stated, they are work products, destined for the trash bin. The ideas they develop are not, though, and more iterations are always better.