Book Review: $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation

Prototype

Greg recommends discarding “the over-bloated, marketing-laden mess that most Web sites have become, and starting over, from the very core of the experience, targeting that feeling of empowerment, simplicity, and sophistication.” Where to start? The home page. It can be as simple as the popular List of Links design pattern. However, you must use a realistic—albeit sketchy—design. Greg encourages his readers never to use Lorem ipsum text anywhere in a prototype. You must use realistic text and icons to get realistic data from testing. But, remember, realistic does not mean polished, but rather meaningful.

The $1-prototype method involves drawing a minimal viable prototype (MVP) on a series of 3x5-inch sticky notes to simulate a mobile app on a smartphone. You can use different sizes of sticky notes to represent different sizes of smartphones or tablets. Start with the home page and create a new sketch for each page that a user would view while completing a task.

There’s no need to show every single detail that will appear in the final design. For example, if an app lists nearby restaurants, your sketch could show the full details for just one or two restaurants, not all the listings. Use a separate, smaller sticky note to represent the keyboard that slides up at the bottom of the screen or a drawer that comes in from the side. See Figures 4 and 5 for examples of a page with an added keyboard or drawer. In Figure 5, on the left is a prototype of an app page on which a yellow bar represents a drawer. The sketch on the right shows the activation of that drawer.

A small, circular, color-coded label can represent a Floating Action Button (FAB). It is important that such dynamic elements be represented separately, so you can add or remove them during testing to create a realistic simulation. You may be able to use some elements multiple times on the same project and maybe beyond. In his book, Greg shows multiple examples of such prototypes, with plenty of pictures, demonstrating this method step-by-step.

Greg advises that, in creating your prototype, you should be specific, but not make it overly complicated. He cautions that you not spend so much time creating your prototype that you fall in love with your design, then find it difficult to recognize its failings. Rapidly create and test your prototype, iterating to create the best design for your product.

Test

Next, Greg guides you in how to use your handy prototype for testing. He cautions his readers that, while many large companies perform usability testing only as a formality late in the design process, this approach does not help them achieve a strong UX design.

By creating a meaningful prototype quickly, you can test and iterate often, which enables you to get to the best design. You must find appropriate participants who have the necessary skills to use the app. Fortunately, most people use mobile apps, so you can find participants almost anywhere.

One of Greg's favorite places to find participants is in a coffee-shop line during the morning rush. In a humorous way, Greg explains that decaffeinated people make great test participants because they are a bit cranky and very straightforward with their feedback. He offers people a free coffee in return for their giving feedback on his prototype. In just a few hours, you can do usability testing with about 15 people, for only about $50.

For most mobile apps, you can do usability testing in an environment where people would actually use the app. Throughout the book, Greg reminds readers that by failing quickly and often, you can iterate to a better prototype.

He recommends starting a usability test with a stack of plain sticky notes with just the home page on top—so its weight feels similar to a smartphone. Then add or remove sticky notes as the user navigates through the app, performing a task you’ve asked them to do.

Of course, moderating a usability test is an art, and there are many considerations you must take into account. Greg recommends that you say little and avoid leading the participant to certain conclusions or to performing specific actions. Ask participants to perform a task, then observe them. Let them continue, even if they are failing. In fact, these moments of frustration—for both participant and moderator—may be the most instructive moments for improving the app design.

Of course, people will ask questions such as “What do I do next?” or “How do I do this?” Greg recommends answering such questions with another question—for example, “What would you do if I weren't here?” This simulates how a confused user would work with a real app in real life—when the project team is not at hand. Greg emphasizes that it is not what participants say that is most important; it is what they do. While participants’ words may differ, behavioral data will often be very consistent across a set of participants. Greg has provided several videos showing examples of usability testing.

Collaborate

The $1 Prototype method is a particularly good fit for agile development. I almost fell out of my chair laughing when I saw Greg’s description of what passes for agile development in many companies. I think he really nailed it! As depicted in Figure 6, a C-level executive declares from above that, from now on, the company will be an agile shop, and it will take much less time to launch products.

However, the company still has the same kind of design meetings—in which somebody stands at the front with a PowerPoint and disengaged people hide behind their smartphones, wishing the meeting would end already. Then, when management declares that it needs time estimates based on those few PowerPoint slides, the designers and developers freak out. Figure 7 shows Greg’s representation of such meetings. This just doesn’t work. But companies make this same mistake all the time!

So, what is a better way to approach agile design for a mobile app project? First, have a kick-off meeting, involving the entire team, in which you create storyboards for key user stories. It is vital that each team member be highly involved in creating these storyboards, as well as the overall design. Even people who swear they can’t draw should be involved. The drawings may be cheesy, but that’s just fine.

Remember, the focus is on the product, not the deliverables. Management and design and development teams can work together to quickly create a well-defined piece of the whole product. For the moment, forget about each person’s title and role. Just focus on creating great storyboards for a great prototype. Create your minimal viable prototype on sticky notes, then do usability testing. As shown in Figure 8, the goal is to quickly create a working prototype of a just piece of the product.

Greg discusses how to work with team members who are more comfortable with waterfall design or who disagree with the rest of the team about the direction the project should take. Since you can create these prototypes so quickly, it is possible to prototype multiple possibilities, then do usability testing on each of the designs. Sometimes, you’ll make very interesting discoveries through testing these divergent designs. Greg goes into great detail on how to encourage a team to design together, then later create good documentation. He repeatedly emphasizes that your focus should be on the product, not deliverables such as wireframes or other documentation.

Greg’s Day-Long Workshop

I had the good fortune of attending Greg’s “$1 Prototype” workshop at the Big (D)esign conference. In this workshop, we covered much of the book’s content and worked on storyboards and paper prototypes. Several participants presented their storyboards and designs, and we discussed what they might do next on those projects. We also explored how to apply the $1 Prototype technique to wearables. Guess what? They make sticky notes in the right size for those, too! See Figure 9 for an example prototype of an app for a wearable device.

Greg led his workshop with expertise and a healthy sense of humor. This made both Greg and his prototyping method seem very approachable. He was glad to answer our questions during and after the workshop. Throughout the day, our collaborative effort enabled us to learn and apply the $1 Prototype technique. Despite our being in a large auditorium, it felt like we were sitting around a large table, having a fruitful discussion. At the end of the workshop, I felt that I could immediately apply the $1 Prototype approach to my work. It was a day well spent.