What's the right sequence of events for designing a Web app?

The answer is: there is no right sequence for designing a Web app. You can do design and programming , programming and design, in almost any order, and productivity seems to be about the same. Along the way, you have to figure things out about your application. So, let's look at the options for figuring those things out.

You can go through a lot of different stages when designing a Web app:

• Storyboard - A flowchart in which each box represents a screen, and each connecting line represents a link or submit
• Pencil sketch - the proverbial napkin, or if you must be more organized, a whiteboard
  
• Wireframe - a crude graphical mockup, often constructed in Powerpoint by a non-designer with limited pencil-sketching skills
• Graphical mockup - a photoshop picture of a page
• HTML click-through Wireframe - a text-mode HTML mockup constructed so that you can see the relevant data and linked together so that you can click through the workflow from the storyboard
  
• Text-mode prototype - actual software that does what you want, but without the design framing
• Programmer's prototype - The programmer's first cut at the software, using the pre-existing design elements and CSS provided by the designer or the project

I have tried many sequences and variations in the 13 years that I have been building Web applications. About 10 times, I was sure I had the magic secret formula for cranking out usable apps fast. In reviewing the results, I have reluctantly come to the conclusion that the order makes no difference to your productivity. You can take the mockup route. You can make a graphical mockup, and then an HTML mockup, and then write a program which copies the HTML mockup straight into the program templates and CSS. That works pretty well, if you keep at it until it works. Or, you can take the prototype route. You you can hack together a prototype version of the program, make sure it does what you want, and persuade a designer to come over and lay in the emphasis, styles, shading, and icons. That works pretty well too, if you keep at it until it looks good.

In practice, you make this decision based on who is better and faster - the designer, or the programmer. If you have a good, fast designer, you lead with mockups. If you have a good, fast programmer, you lead with the code.

I don't think you can skip the storyboard. Without the storyboard, none of the other steps make sense. But this doesn't need to take time to produce. I draw mine with a pencil and scan them, and I still get decent apps. You can also draw them on a whiteboard and take a picture of the result.

I once believed that it was a very good idea to build an HTML click-through wireframe mockup, on the theory that it would be faster and cheaper to test and change the workflow when it was in mockup form. However, now that we use more productive programming tools like Rails, it's just about as fast to build the prototype. And, designers work a lot faster on graphical mockups than in HTML mockups. So, we have abandoned the HTML click-through mockups.

In the intervening years, Web design has gotten a lot harder. Web designers don't just have to know HTML and some basic layout and font rules they learned from doing print design. To cover all the bases you need covered, a designer needs to know about the graphic artistry, various illustration tools, direct marketing, typography, HTML, CSS, Javascript, SCM, etc. It has become too much for any one human. So, you need to chop the job up into more pieces. And, it's likely that the programmers, who have a job that has become only marginally more difficult with time, can catch up or even run ahead of the mockup process. Nowadays a Web viewer is less likely to encounter hollow-but-pretty brochureware, and more likely to find skeletal applications that the designer has yet to civilize.

Some designers are great at making graphical mockups. They can really make Photoshop fly. You should take advantage of this. But what if that's all they do? You still need someone to translate this to HTML and CSS.

So, we do more prototyping now because design and mockup has gotten harder. But the basic rule applies: You go with the mechanism that is going to let you see results most quickly, and that depends on whether the designer is faster, or the programmer is faster.

If you are in a hurry, you run these processes in parallel. You ask the designer to make graphical mockups that show the design elements and common layouts. Then you can make images and CSS from that. During that time, the programmers are making code. The problems come after you merge these streams. Then, you have an application that works, and an incremental release process. It's less work to make all your changes right in the code. You have to make an extra effort to go back to mockup. Most people in this situation run a redesign, from mockup, every six months or a year.

Pencil sketches are still the fastest way to come up with good ideas. I used to run speed design sessions, which are sort of like speed dating. You start with a stack of printer paper and a few co-conspirators. You each spend two minutes drawing a screen. Then you put the results aside, and you do it again, with variations.

You can also apply pencil sketches to an application that is already built. Print out a bunch of copies of the pages, and start scrawling on them. Go for it. I invite you to try it on my app, and post the results.

The modern rule of good design is: Keep releasing, and keep improving.