This chapter is from the book
This chapter is from the book
This chapter is from the book
Common Questions
This section provides answers to common questions with regard to prototyping.
How Many Variations Should I Prototype?
Ideally, you should try to prototype a few divergent directions in the early design stages. As the design progresses, teams tend to get attached to one direction so it may be challenging to change course. Be sure to choose your prototype medium wisely—lower-fidelity options like paper make it easy to explore multiple directions, whereas some higher-fidelity tools tend to encourage incremental or superficial design changes.
How Much of the App Should I Prototype?
The scope of your prototype will depend on the design stage and your goals. At the onset of your project, it's beneficial to take a holistic approach to the prototype. This doesn't mean you must prototype every single screen and interaction, but you'll want to cover the primary scenarios identified in your up-front user research. In the middle to later design stages, you may return to prototyping to help resolve a particular flow or interaction issue. If you are creating a slideshow app, for example, you may want to fine-tune the transitions via a prototype.
What If the Designs Aren't Completely Worked Out?
You don't have to wait until every aspect of the interface is completely worked out. It's fine to use Wizard of Oz 4 techniques to demonstrate certain aspects of the app. Wizard of Oz techniques require a human to simulate app interactions. For example, let's say a usability participant wants to search restaurant listings on your app but you haven't coded search yet. With a Wizard of Oz approach, you could ask the participant to wait a moment while the app "processes" the request. In the meantime, you or one of your colleagues could search for the information and provide the results on the fly. In addition to uncovering usability issues, this approach could help you refine requirements before coding begins.
What If My Support Content Isn't Finalized?
Jared Spool recommends "Incredibly Intelligent Help" 5 to simulate a help system. Essentially, when users tap on help, the human "computer" responds to their questions. This approach provides a relatively seamless experience and can also identify areas of the interface that need design improvements or support content. On the other hand, be conservative with greeking, the practice of including lorem ipsum and other filler text instead of real text. If the text is central to the user experience, include draft copy and then iterate based on user feedback.
What Is the Appropriate Level of Fidelity?
The fidelity of your prototype should match the design challenge at hand as well as the stage in the design process. For example, paper prototypes (Figure 7.1) can typically uncover most flow and terminology issues but are less successful when it comes to low-level interaction issues. This doesn't mean that paper prototypes should always be your starting point. As discussed later in the chapter, some apps may require a higher-fidelity prototype earlier on.
)
Figure 7.1 Paper prototype for a gaming app
If you plan to present to company executives or investors, you should assess their comfort level with low- versus high-fidelity prototypes. Some individuals may view low-fidelity prototypes in a negative light since they can be "rough" in appearance. That said, if you want to convince them otherwise, consider how Jane Fulton Suri, a partner and creative director at IDEO, assesses whether a prototype is effective: "If it is [a good experience], people get so involved in the experience that they forget about the limitations of the prototype."
What Should I Do Before I Start Prototyping?
Before you start prototyping, create app sketches, as discussed in Chapter 6, "Exploring App Concepts." If you haven't done so already, place these sketches in a high-level application flowchart. Figure 7.2 illustrates an application flowchart for a dictionary app; notice how the legend includes symbols for supported gestures. A flowchart provides a holistic view of your app and serves as a blueprint for your prototype. In the early design stages, focus on the "happy paths" that represent typical scenarios, not ones that generate unusual error conditions. 6 Edge cases can be added once you narrow down your concept.
)
Figure 7.2 High-level application flowchart for a dictionary app
Other points to keep in mind when working on your app flows are the following:
-
Streamline, streamline, streamline.
As mentioned earlier, mobile users have limited time, so your app flows should be as succinct as possible without compromising usability. To that end, look for ways to combine or remove steps in multistep processes. For example, wizards are great for app setup and other linear processes (e.g., shopping checkout), but they can slow users down when used for frequent tasks, especially those with many optional items.
-
Provide multiple ways to access information.
Users are often faced with dead ends, particularly when drilling down list views, but the app experience can be more fluid. For example, news article views could have cross-links to related articles, but many apps force users to navigate back to the original list view. Similarly, maps that contain points of interest (POI) should allow users to go directly to the POI, instead of requiring them to return to the corresponding list view.
-
Keep users within context.
As much as possible, try to keep users within your app. Leaving your app means users will require additional time and effort to reorient themselves, increasing the likelihood that they will not return. For example, many apps force users to visit their web site for help via Safari. Unfortunately, if users can't easily refer to their original problem, the external help may be useless. If users must leave your app (e.g., for map directions), at least provide a warning. When users return to your app, they should see the last screen visited, known as "saving state."