Related to Rapid Application Development vs. Big Design Up Front is the question of what exact format the UI design work should be done in.
This is more important than user stories vs. use cases, class diagrams vs. ERDs and other such decisions, because UI design artifacts are the most user-accessible artifacts. That means they’re probably the only ones you’re actually going to be able to get users to look at. Try emailing a CFO a 100-page Word doc full of use cases sometime, if you don’t believe me. Then sit that same CFO down in front of Excel and ask for a rundown of their least favorite Excel features. Big difference!
Shockingly, users care about the user interface. They understand the functionality of the application through the model that the UI presents to the user.
So, if you want feedback, the easiest way to get users to give it is to put something in front of them that looks like the user interface of the application that you’re building. In fact, the highest-fidelity way to do this is to build the whole application, then let them use it and tell you what needs changing.
This is usually cost prohibitive, so there’s a trade off to be made: build something that looks kinda like the final application will look, but that takes nowhere as much time and effort to build, and hope that by the time you actually build the thing, it’ll be really close to what the users wanted.
No, scratch that. Users don’t know exactly what they want, generally speaking, so building what they wanted is impossible – they only know if they want it once it’s in front of them. They can’t just come out and design the whole system for you, in full detail, and hand you a spec. (I can picture a house I’d want to build if it were up to me, but I can’t tell you what brand and model of faucets to use, or what the roof should be made of. And I certainly wouldn’t know what to do to meet building codes.) That’s why people hire professionals – it doesn’t mean they’re stupid, it means they don’t want to have to deal with all the details themselves. That’s the designer’s job.
But users sure can tell you when a certain thing is all wrong, and what that thing should do instead, which is how you’ll have to get used to dealing with them. (I can tell someone that a faucet is ugly, or that I don’t like the shower faucets that hotels have that make you turn it all the way past cold to get to hot.)
So, hopefully by the time you build the thing, it’ll be minimally wrong, and won’t lack any essential features that everybody forgot about until just now.
Anyway, as I mentioned before in RAD vs. BDUF, you need to understand how inclusive you need to be of stakeholders outside of the core team, in order to build something that isn’t totally wildly wrong. At one end of the spectrum, you just can’t get any grasp of what the users are talking about, ever, and you can’t build anything because you just have no clue what to build. Time to find a different problem to try to solve. At the other extreme, you know what to do and you don’t need anybody’s advice. That’s often the case with writing small apps and scripts to serve personal needs.
In the middle are all the processes where you need to figure out a way to solicit user feedback. Do you need lots and lots of stages of feedback because you barely understand the domain? Or are you pretty sure of what needs to be done, but somebody else is paying so you have to make sure they get a chance to look at it and sign off before you proceed?
These are the questions you should answer so you know whether you want to start with cheap and low-fidelity wireframing tools, like paper prototyping (advocated by Jakob Nielsen and A List Apart), or if you should lean toward sophisticated, high fidelity tools like graphics wireframe drawings or, according to some, HTML wireframes.
Boxes and Arrows has an article entitled HTML Wireframes and Prototypes: All Gain and No Pain, which seems like a pretty bold claim to me. The article’s author basically argues that Dreamweaver is the ultimate prototyping tool, because it’s as easy or easier than all of the options, and it makes prototypes that look more like the end product will than any of the other options.
I disagree; I’ve used Dreamweaver and found it to be one of the slowest, clumsiest, most awkward applications I’ve ever used. But let’s assume that Dreamweaver could be replaced with a tool that was basically the designer’s favorite drawing program that they know and love, except that it saved in HTML format.
Now we’ve eliminated the new-tool vs. my-favorite-tool issue, so we’re left with the issue of a continuum of increasing levels of detail. Now, ask yourself this: do you really need to fill in all the details in your wireframe, or can some of them be left until later? This really depends on your confidence level in the accuracy of your initial design decisions, and whether the folks reviewing your wireframes will be able to look past the placeholders and focus on the stuff you’re asking them to review.
If your users can handle a whiteboard, then you can use that, and take digital camera pictures. I prefer that process instead of paper prototypes, partly because everyone understands that whiteboard drawings have a very constrained level of fidelity (no one will ask “but will the web site really be all purple?” just because you drew it in purple).
For later revisions, the argument that an HTML prototype will be so much cheaper because you’ll reuse it as the start of the real application is clearly invalid. After all, if it’s wrong and you need to change it, you wouldn’t use it anyway, so it only makes sense to work on wireframes in the tool that’s the easiest to use. I personally find that OmniGraffle is faster than a whiteboard, especially if I want to change something small, and typing is faster than writing with a big dry-erase marker, especially if I want to be able to read it.
It’s simply a matter of the cost to fill in all the low level details before you know if the high level details are right. It’s wasted work if you do it too early, and if you use HTML, the expectations of the reviewers will be higher, and your ability (and temptation) to over-tweak the look and feel and thus distract reviewers from the content and basic functionality you’re trying to focus on is high. Does it really matter if that’s a link, a standard button, or an image button, at this point? That’s the sort of thing that you don’t want to get bogged down on, but you will if you’re not very careful.
Toward the end of the design process, I agree that HTML is a format you’ll need to use, but only because at some point you have no choice but to write the HTML and CSS for the web site, and to make sure it works with all the appropriate browsers. But I strongly disagree with the argument that, say, tweaking the design in Photoshop first and then doing battle with IE 6’s interpretation of CSS is slower than doing it in Dreamweaver, and then cleaning up the HTML that Dreamweaver created when it’s time to make the app work cross-browser for real.
In other words, until somebody makes a WYSIWYG HTML tool that generates clean and maintainable, cross-browser compatible, standards based HTML and CSS, the step of making the full HTML and CSS mockup should be left until dead last. Maybe as Dreamweaver (or another similar tool) improves over time it’ll make more sense to use it earlier.
In the meantime, instead of building an overly pretty bunch of tentative wireframes, do some graphic comps and show users what the home page and a few subpages will look like. Then show them the home page comp and a low-fi home page wireframe, and say that for now they’ll be working with the low-fi versions that you can change super fast. They’ll very likely understand it.
If you have no choice, because the reviewers just don’t understand that the web site will look prettier than the wireframe, well then maybe Dreamweaver (or little stenciled HTML elements in your drawing program) are the right way to go. But don’t spin your wheels trying to get things to line up just right in Firefox and IE before you even know what the heck is supposed to go on that page. It won’t save you time.