Low-Fidelity Prototypes

Low-Fidelity prototypes help stakeholders concentrate on the subject matter by using familiar media. Such things as pencil and paper, whiteboards, flip charts, Post-it notes, index cards, and cardboard boxes can be employed to build effective Low-Fidelity prototypes (Figure 12.3). In fact, these prototypes may take advantage of anything that is part of the stakeholders' everyday life and do not require an additional investment.

Figure 12.3.

Effective prototyping tools do not have to be complex or expensive.

"To look at structure, the first prototypes are always paper."

Source: Hugh Beyer and Karen Holtzblatt, Contextual Design

The Low-Fidelity prototype is not meant to look all that much like the finished product. This is both good and bad. The good part is that no one will confuse the prototype with an actual product. It is obviously built with a minimal investment in time, and most importantly it gives no indication that it is anything other than an easy-to-change mock-up. The Low-Fidelity prototype encourages iteration, and it more or less indicates that you are not expecting to get the right answer on your first attempt. The bad part is that such a prototype sometimes requires more effort on the part of the stakeholder who is testing it to imagine that the whiteboard sketch is potentially his new product. However, the ability to make changes easily and the speed with which you can sketch out a prototype usually help you to bring things to life to help stakeholders take more advantage of their imaginations.

Prototyping is more convenient, and ultimately more accurate, if done one use case at a time.

We find that prototyping is more convenient, and ultimately more accurate, if the prototype involves a single business use case or a single product use case. As the prototype involves some simulated product, we will assume you are prototyping a product use case. We introduced business and product use cases back in Chapter 4. Recall that a business use case is an amount of work, triggered by an external business event occurring or by a predetermined time being reached, that takes place in a single, continuous time frame. It also has a known, measurable, testable outcome. A product use case is the part of the business use case to be done by the product. Because of the single, continuous time frame, it provides you with an appropriate amount of work as the subject of your prototype.

Let's look at prototyping by examining an example use case. The "Monitor untreated roads" use case, as shown in Figure 12.4, is suitable for our purposes. This use case is triggered periodically when it is time to monitor the road treatment: The engineer checks whether all the roads that are scheduled to be treated with de-icing material have been covered by one of the trucks. Thus we have to find all the requirements for this part of the product.

Figure 12.4.

The truck depot engineers are responsible for ensuring that all roads in danger of freezing are treated with de-icing material. Use case number 11, "Monitor untreated roads," represents this part of the work.

Your aim in building this Low-Fidelity prototype is to unearth the existing requirements that must be carried into the new product, along with the new, undreamed-of requirements. Let's assume the engineers are currently working with a system that supplies them with a list of roads, and use that as a starting point.

You can quickly sketch a Low-Fidelity prototype of the current situation, and then begin to explore improvements to it. The prototype focuses on what the product could do, for the moment ignoring any implementation details.

The point of sketching a Low-Fidelity prototype is to be quick. Demonstrate each requirements suggestion with another sketch or several alternative sketches. You might intentionally serve up several prototypes of the same use case, asking for the stakeholders' preferences and possibly more suggestions for alternatives. Once your stakeholders see you are simulating potential ways of solving their problem and realize their input is not only welcome but also necessary, they will almost certainly help you by suggesting their own enhancements and requirements. Experience has taught us a valuable lesson: Once you get people involved by making the problem visible, they tend to become very creative and imaginativeand sometimes your problem evolves into one of keeping pace with their imagination.

Get started by sketching what the stakeholders^[1] might be doing when using the product for the use case. Ask the stakeholders what part the product will play in their work, and note their ideas. In the "Monitor untreated roads" use case, stakeholders would most likely want the product to provide following information:

^[1] We say "stakeholders" rather than "users," because there are probably people other than users who are interested stakeholders for any use case.

• Roads scheduled for de-icing

• Roads that have been de-iced

• Relative positions of roads

"Paper is eminently practical and meets the primary need: It makes it possible to express the structure of the system and makes it hard to overfocus on user interface detail."

Source: Hugh Beyer and Karen Holtzblatt, Contextual Design

Now ask the stakeholders what they would do with this information. At this point you are not trying to design a solution to this immediate problem, but rather want to explore ideas for what a potential product might do and what the work might be with that product:

• "What is the best way of presenting the needed information?"

• "Is the requested information the right information for the work being done?"

• "Could the product do more or less of the work?"

Assume for the moment there are no technological limitations. Also, keep in mind you are not designing the product, but are capturing all the things it might possibly do to help the stakeholders do their work.

Sketch pictures to elicit ideas from the stakeholders. If they are having trouble getting started, then inject some ideas of your own. Ask them to imagine that they are doing the job of monitoring untreated roads. What other pieces of information would they need to do the job? Would they have to look for information somewhere else? Is all of the information in the current version of the prototype necessary to do the job of monitoring untreated roads?

As the prototyping proceeds and the engineers see your sketches, you hear the following:

"That's great. Now wouldn't it be great if we could see the major roads that have not been treated for three hours? But only the major roads the secondary ones don't matter so much. Our current system can't distinguish between major and secondary roads."

How long does it take you to add that requirement to your sketch? About ten seconds? How long would it have taken to modify the installed product if the engineers had asked for this requirement after delivery? Enough said.

By working with the engineers you generate a prototype that is possibly quite different from what they have at the moment. That is the point of the prototypeto change the work, and to discover new and better ways of doing the work. By encouraging the engineers to tell you more and more about the job, you uncover requirements that otherwise would not come to light. See Figure 12.5.

Figure 12.5.

By drawing this lowfidelity prototype on a flip chart or whiteboard, with the help of the truck depot engineers, you identify their requirements. They want the product to highlight the major roads within a district that have not been treated and are in a dangerous condition.

When you sketch a Low-Fidelity prototype, you demonstrate your ideas to the stakeholders and encourage them to iterate by changing and improving your ideas. Recall that a part of the requirements process is inventing a better way to do the work. (See Figure 12.6.) The prototype is an invention vehicle for you and your stakeholders to experiment with and to see how the proposed product could contribute to the new work.

Figure 12.6.

The low-fidelity prototype is informal and fast. No one will mistake it for the finished product. Because it is easy to change, stakeholders are willing to iterate, experiment, and investigate alternative ideas.

The low-fidelity prototype is not a work of art, but rather an ideagenerating device.

Low-Fidelity prototypes give the best value when you use them early in the development cycle. The stakeholders can give you more feedback earlier in the process when they are less fixated on the design or appearance of the product and are more interested in the overall structure and broad-brush functionality. At this stage, the users' ideas for the product should be fluid, and quick and easy experimentation will yield the best product.