Note: This is a repeat of one of my more popular articles. It is reprinted here after several requests. Since I have a lot more readers now than I did when originally posted, I thought it would be a good time to recycle it. :-)
You don't have to be on this site for very long before you'll start picking out some common themes. Two of the topics that I am very passionate about when it comes to the development process are low-fidelity prototyping and usability testing. I truly believe that every developer (no matter what their preferred technology) can reap enormous benefits by adding these two simple techniques to their development methodology.
On the most recent Taking Notes podcast, I mentioned I have some articles about usability testing coming up. Well I do, but I thought it might be a good idea to cover the first of my two 'secret weapons', since usability testing actually follows as a logical extension of low-fidelity prototyping. With that, let's first define what low-fidelity prototyping is about. Due to its RAD nature, most Notes developers are very familiar with the concept of prototyping. In the case of low-fidelity prototyping, the word 'fidelity' refers to the level of detail in the design itself. That is:
Low-Fidelity = Quick & dirty hand drawn screens
High-Fidelity = Polished design or high-quality screenshots/mockups
Another name for low-fidelity prototyping is "paper prototyping" and perhaps this name more fittingly describes what you use in the process. I prefer low-fidelity prototyping because it sounds more impressive, and if I were a consultant, I could probably charge more (haha...OK...only kidding!). The purpose of the low-fidelity prototype is to allow you to design the interface of your application before you focus on anything else. Some developers think I am committing heresy when I say this, but I believe without a doubt that you can design a better application if you build the interface before you write any code!
One of the first benefits that low-fi prototyping brings you is the ability to talk to a customer in concrete terms very early on in the project. When they are giving you requirements, customers usually have very nebulous ideas about what they are actually looking for or what they are going to get. It is very powerful to be able to return to the customer shortly after the initial meeting with a physical object that they can review, manipulate (by turning pages), etc. This initial prototype may be completely wrong, but it gives you a common platform from which you can continue your discussions about the application. I think you'll be surprised at what additional information you uncover so early on. There are several other benefits that low-fidelity prototyping brings to the design process, but first let's take a step back and talk a bit about how you build one.
Perhaps one of the neatest things about low-fi prototyping (that's what the cool kids call it) is that it is so easy to do...and dare I say...a lot of fun. The tools of low-fidelity prototyping are all those things you used in kindergarten; paper, pencil, markers, crayons, scissors, glue sticks, etc. The key to low-fidelity prototyping is drawing out enough detail to allow the customer to figure out what is going on, but no more. The low-fidelity prototype is not meant to be polished. It's just a 'rough draft' of your screens. A lot of great work in design and engineering was initially conceived on the 'back of an envelope' and the concept is the same here.
To get the most benefit from this technique, you need to draw out all of your interface elements. This includes screens, menu items, dialog boxes, etc. Place only one element on a page (e.g. if you have 5 dialog boxes, use 5 sheets of paper, one for each dialog). This makes it easier to manage your design, especially as you work through multiple iterations. That's really all there is to it!
As you are beginning the work on your low-fi design, remember that this is the ideal time to 'think outside the box'. Try to forget the constraints of your development platform and instead focus on how you can design an interface that will be clean, efficient and easy to use. If you have the luxury, I think the ideal state is to stay technology agnostic. Design the interface, figure out what functionality is needed and then decide on which tool is the right one for the job. You can temper this with good judgment, of course. If you know you are building an application in Notes, don't design an element that you absolutely know you can't use in the client. However, some of the best interfaces I've made were initially born out of low-fidelity prototyping, followed by an exclamation of "There's no friggin' way I can do that!" A little perseverance and a lot of experimenting in this regard can pay off big time, though, so give it a try. The worst that can happen is that you fail, learn a lot from that, and then move on to plan B.
Once you have completed your first low-fi iteration, schedule some time with your customers to discuss it. See if they can understand the functionality without you explaining it to them. Are there glaring errors that are immediately evident or are they just bringing up subtle points? Make sure to take as many notes as possible, trying to capture everything the user points out or alludes to. You can often find important information in these notes...things the customer initially forgot to tell you, details on how computer savvy the user base is, etc.
So...You've built your prototype, met with your customers and got a couple of suggestions for changes. Time to go write some code, right?! Whoa, there partner...not quite yet. Unless you absolutely nailed it on the first try (probably not), it's time to build another iteration. On average, I'd say you'll build about three low-fi designs in a typical project. Each time, you'll refine and meet with your customer, coming closer to the final interface with each pass.
Let's return to discussing benefits around low-fi prototyping, since this is one of the stages where you really see a payoff. One reason low-fidelity prototyping works so well is due to the psychology of how we perceive quality. A user looking at an actual application on the screen is generally less apt to point out flaws, even if you only invested a little time in it. They think to themselves, "Gosh, he's already got something ready for me. I guess I can live with this, even though it's not exactly what I want." The customers tend to censor themselves, since they think you've invested time and money in the design. At this point, you might be thinking "Not my users...they hate everything and tell me so!", but most people will do this, just to varying degrees. Users generally have no problems, however, when you throw a hastily drawn piece of paper in front of them. When it looks like you had a little kid whip something together, the customer will definitely let you know what they think! :-) In fact, I suggest a little experiment. When you go into your low-fi meeting, strategically place some pens, pencils, crayons, whatever, in an area that the customer can readily access. I'll bet that when you set the prototype in front of them, they reach for one of those implements and start marking away. Let them! This is valuable, as it helps you see what they really want. It also gets the user emotionally invested in the design, which in my experience leads to increased satisfaction at the end of the project.
As developers, we benefit from low-fidelity prototyping as well. It may sound like this process adds time up-front and you're right...it does. However, once your prototype is pretty well finished, you've got a great plan for development. You won't be sitting there staring at a blank canvas, wondering how to start. Instead, the low-fidelity prototype provides great clarity and allows you to concentrate on the next important part of your process, actually writing the code. Also, since we've avoided code until this point, we've probably saved time and money. Often, the choice of interface elements we use dictates the most efficient path we take coding wise. Any time you start development by writing code puts you in danger of having to back track or rewrite in order to address UI concerns. Hopefully, you can see that capturing the specifics of the UI up-front helps mitigate these risks.
The definition, increased communication and clarity that low-fidelity prototyping can bring to a process is highly beneficial by itself, but it becomes infinitely more powerful when combined with our second 'secret weapon', usability testing. That's right...you can actually test your application using the paper prototype (how cool is that?) We'll explore this technique in a future post.
For now, let me leave you with a call to action. Give this process a try on your next project. It's certainly not hard and I think you'll find it very powerful. If your customers (or most likely your boss) look at you a little weird, be honest with them. Explain why you are doing this and the possible benefits (hint when dealing with the PHB* --> "It saves money!!!"). Let them know that it is a new concept for you as well and that you'll learn together. The customers will appreciate your openness and will most likely be willing to give it a go. My guess is that after the project, you'll be doing a lot more low-fi work.
Overall, low-fidelity prototyping is a super technique that I use all the time. I hope you find it as compelling as I do. Good luck!