How to Easily Prototype Your Android L Material Designs: TripAdvisor App Case Study

The following is an excerpt from The $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation for Material Design, iOS8, and RWD now available on Amazon.com.

One of my favorite examples is TripAdvisorâ€s Android 4.x app (NOTE: TripAdvisor is not a client of DesignCaffeine, Inc. and has neither commissioned nor reviewed this content). I donâ€t know what forces guided the designers at TripAdvisor to come up with this interface. My only point here is that if they had taken the time to test some early sticky note wireframes before building their app, they would have found some of the same issues we did. After all, As Jakob Nielsen so eloquently said, “there are no secrets of usabilityâ€:

So perhaps, if TripAdvisor would have known about the issues early, they would have had the time in their development process to draw and test some alternative designs. Using the $1 Prototype methodology, it took me less than 30 minutes to update TripAdvisor for Google Material Design with sticky notes, as shown at the end of this section. Unfortunately, as far the current TripAdvisor design goes, the interface does not perform as we as one would expect. Below are just a few of the issues we found in our testing.

We asked 6 participants to use the TripAdvisor app look for a hotel (this study was not commissioned by TripAdvisor). At first glance, this should be pretty easy: the homescreen uses a simple List of Links design pattern already listing a bunch of possible app areas you can access, and the Hotels are an easy #1:

Unfortunately, the issues come up as early as the following screen. In our testing, we found that for various mobile navigation and travel apps, the initial mental model is that the hotels youâ€ll find would already be “near youâ€, unless specified otherwise. In contrast, in the TripAdvisorâ€s app, the primary assumption is the reverse: unless you can figure out that you need to tap the “Find hotels near me now†checkbox, youâ€ll be searching world-wide hotels instead. Even when the participants figured out to look for it, the checkbox was hard to find: the label on the checkbox is unusually long and buries the keywords “near me†in the middle of a long sentence. Including the checkbox label itself, the phrase “Find Hotels†occurs three times on the same page, adding unnecessary noise and confusion. All these are likely factors contributing to the key finding: in our usability testing, many people missed the checkbox their first time through the flow. To add to the usability challenges, the checkbox is a non-standard Android UI control: it is hard to tap and seems to be placed too close to the search field.

When, despite these issues, our participants did figure out to tap the “Find hotels near me now†checkbox and got to the next screen, they promptly encountered additional challenges. Note the three tabs on top of the search results: Stay, Eat and See, which, as one participant put it, “sound like dog training commandsâ€. Second, these three tabs were confusing to many people because they already selected “Hotels†link using the initial List of Links on the homescreen. Thus the tabs seemingly invite them to “Stayâ€, “Eat†and “See†the hotels!

Of course most hotel buildings are not edible, with the possible exception of the Gingerbread House from Hansel and Gretel (http://bit.ly/1dphansel). But it took most people a few moments to realize that “Stay†directly maps to “Hotelsâ€, “Eat†maps to “Restaurants†and “See†maps to “Things to doâ€. This kind of additional mapping is actively harmful: it is confusing because it shows items people have already selected and forced them to do the extra thinking to map the IA due to multiple inconsistent labels for the same item. Finally, the three tabs needlessly take up precious real screen estate on the results screen (more on this below).

Navigating from the homescreen is not the only way the TripAdvisor app can search for hotels. Tapping the magnifying glass from the action bar on the homescreen launches the search screen sequence shown below:

Assuming youâ€re still looking for a hotel, it seems reasonable to type in the word “hotel†into the search field (as an answer to the “What are you looking for?†question which comes up as the text mask when the field is first displayed). And indeed, many of our participants did just that. When they performed this search, they were in for quite a shock. Look at the screen carefully: the app certainly did find some hotels, but where? The results are hotels scattered around the world, covering parts of Spain, France, Washington DC and Austria. Now compare the structure of the search results you see here with the previous search results obtained by tapping “Hotels†on the homescreen: do you see anything missing? Thatâ€s right: prices, distance and the right caret. In fact, search and browse present two completely different UIs for the same exact information.

This is a huge problem. Not only was this confusing to our test participants, it duplicated the effort for the developers in having to create and maintain two sets of pages. And look at the filter link: in addition to the three filters that match the previous three tabs (“Hotelsâ€, “Restaurants†and “Things to doâ€) the app adds the forth filter that occurs nowhere else: “Locationsâ€. Also note that “Things to do†sports a different icon (“running manâ€) in the filter than it does on the homescreen (“binocularsâ€). Certainly the UI can be more consistent.

But there is yet a third way that TripAdvisor app can advise you (“â€But that is not all. Oh, no. That is not all…†said the appâ€, with apologies to Dr. Seussâ€s Cat in the Hat (http://bit.ly/1dpcat). If you look in the overflow menu, you can select “Near Me Nowâ€:

Although our participants thought that this option looked most promising at the first glance, the app did something very odd: selecting “Near me now†catapulted the participants into the “Eat†tab! Also note that in this case, the app served up the first type of search results, the ones with the three tabs. And as I already mentioned, these tabs make up the chrome that takes up a great deal of precious vertical screen real estate: fully a third of the tiny mobile screen:

Obviously there are better ways to solve this very common design problem. The following sticky note wireframes demonstrate my quick take on converting the Android 4.x TripAdvisor app into Material Design using the $1 Prototype methodology.

The $1 Prototype methodology is perfect for prototyping Android Material Designs. In fact, as you can see below, according to Googleâ€s official video titled: Google I/O 2014 – Material design: Structure and components, Google designers came up with the Material Design principles using paper prototyping methodology that at its core, is very similar to $1 Prototype (http://bit.ly/1dpmaterial):

Now in my own prototyping and user testing, I often find myself fresh-out of wooden disks, so instead I tend to use pre-formed round stickers such as these Removable Color Coding Labels from Avery (http://bit.ly/1dproundstickies) to simulate FAB (Floating Action Button), one of the signature features of Material Design.

Other than simulating the new FAB with a circular sticky note, there is little else you need to do differently to create Material Design prototypes using the $1 Prototype methodology. Of course, if you wish, you may create layers by cutting up colored sticky notes (as I did below to show you an example of prototyping layers). In most of my design work, I rarely have to use separate layers, unless I am specifically aiming to prototype and test the interaction between various layers (see Question #21: “How do I Test Material Design Transitions?†in Part 3 of the The $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation for Material Design, iOS8, and RWD book for more details on how to test complex transitions).

Beware spending so much time creating your prototype that you fall in love with its design: the prototype exists only to test one particular design direction, nothing more. Remember: the fidelity of the prototype should reflect the level of completion of your design. If youâ€re at the step that still requires you to fix your Information Architecture and content, it may be too early to worry about interface layer transitions. Spend your design time wisely to maximize brainstorming various design directions and testing them with real customers. Minimize the documentation—including needless “prototype beautification†to avoid what Timothy Ferriss wisely calls “W4W†(Work for Workâ€s sake) in his book Four Hour Work Week (http://bit.ly/1dp4hrww).

In my workshops, often the greatest challenge for designers is converting their existing Android designs to the new Material Design approach—making the interface both simpler and more visually rich than their corresponding Android 4.x designs, as well as laying out the “happy path†for the customers (using FAB as one of the tools). The following sticky note wireframes demonstrate my quick take on converting the Android 4.x TripAdvisor app into Material Design. Be sure to compare and contrast Material Design wireframes below with the Android 4.x redesign wireframes covered in previous question.

1) Homescreen

In accordance with Googleâ€s Material Design principles, I designed the first screen to be much more visually appealing. In particular, I replaced the List of Links pattern currently used by TripAdvisor with the 2-D More Like This design pattern, which shows the pictures of nearby attractions, restaurants, and hotels in several image carousels positioned as scrollable rows on the screen. Netflix, Gowala, Amazon, and many other mobile apps and websites use the 2-D More Like This design pattern to showcase visual content, because it helps the app to tell the story directly (instead of telling searchers about the story with a List of Links, the way the current TripAdvisor app does). See my Android Design Patterns: Interaction Design Solutions for Developers (http://bit.ly/1dpadp) for descriptions of 2-D More Like This, and 70 more design patterns.

In addition to the new design pattern, note that the naming convention for the screen is drastically simplified per Material Design guidelines, removing the filter strip element, launch icon, and any explicit branding in favor of using “Near Me†as the screen title itself. This simplifies the interface and navigation, allowing the content to shine.

Do I need a FAB?

You may have noticed that the homescreen did not include a FAB (Floating Action Button), a signature new element of Material Design. Should you have included a FAB? Google guidelines say that to include a FAB, the function it calls should reflect the “zeitgeist†of the app. For TripAdvisor, which relies so heavily on customer reviews for their content, the “spirit of the app†could be something like “Write a Review†function. The picture below shows what a homescreen with a “Write a Review†FAB may look like when prototyped using sticky notes:

However, before we celebrate the “FABulous cleverness of us†(http://bit.ly/1dpclevernessofme), it pays to think through what would happen if the customer were to tap the FAB button—that is, to walk through the flow of creating a new review from the homescreen. If you do, you may realize that itâ€s much more natural to create a review once you have found the object youâ€ll be writing about, and that starting a review from the homescreen is not, in fact, even close to ideal. If you tap the “Write a Review†FAB on the homepage, the first step of the workflow would be search—not the most satisfying scenario, and not likely what your customers would expect. Remember that while FAB us a powerful new feature of Material Design, not every screen needs or deserves a FAB. In this case, I would emphatically recommend not including a FAB on the homescreen.

The homescreen now serves two functions: first, it explains the IA structure of the app at a glance, and second, it helpfully lists the nearby points of interest (restaurants, hotels and attractions, etc.). This design basically all but eliminates the first tap, creating a convenient, visual “Browse Nearby†screen. Of course, in a city like New York, you may be within walking distance of hundreds of hotels and thousands of restaurants, so a 2-D More Like This carousel (that can comfortably show only about 8-12 results on a full-size mobile device) would present a rather limited number of options. We need to provide an additional way for people to access the bulk of the results, beyond 80-100 that can be shown on the homescreen. Time to dig deeper with the basic search.

2) Basic Search

The 2-D More Like This pattern makes extending browsing easy by providing a “More Like This†placeholder at the end of the carousel, which navigates to the bulk of search results in a particular category. Alternatively, the title of each row also navigates to the same place:

The category search results screen could look something like the sticky notes prototype shown below:

Note the filter overlay: it is rendered as a bright-colored teaser layer on top of the search results. Many of the students in my workshops asked me whether this is something people can discover on their own. Good question! Per Google Material Design guidelines (http://bit.ly/1dpmat), you do not need any identifying icon on this layer—the z-depth of the layer and its color alone should be enough of an indication to point it out to customers as an interactive element. So far that concept seems to work—I did not see any issues in our testing with sticky notes. However, it never hurts to launch the filter overlay in an open position to draw attention to this element, at least the first one or two times the searchers use the app.

As I mentioned, the whole idea behind using the $1 Prototype methodology is to be able to experiment rapidly with various design approaches. One alternative design worth trying might be to surface the various sort options (Nearest, Best, Cheapest) and a map as tabs on a secondary toolbar. This alternative design fits well with the Material Designâ€s directive of exposing more “happy path†functionality to the customer with additional toolbars:

Depending on the design, either the app bar or the additional toolbar (or both) can fold up and disappear when the searcher scrolls the screen. Alternatively, one or both bars can remain “glued†to the top of the screen. My recommended behavior in this case would be to hide both bars when the customer starts to scroll the search results page down, and bring them back the moment the searcher tries to scroll the screen upward. Early in the design process, this can be an excellent point to probe with your potential customers to get their opinions on the subject (See Part 3: Test, of the The $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation for Material Design, iOS8, and RWD book for more on asking non-leading questions).

Later in your design process, if you do decide to go with the tabs option and successfully nail down the rest of the design on this page, you may wish to create a couple of different wireframes to test various transition designs against actual customer behaviors. As we are using separate colored strips of paper for the app bar and tabs, testing various transition behaviors is pretty straightforward. (See Question #21: “How do I Test Material Design Transitions?†in Part 3 of this book for more details on how to test the hide-away elements).

3) Advanced search

As I described in the previous question, another way to access search results would be from the search icon on the app bar on the homescreen, which launches a dedicated search query screen. Just as we did in the Android 4.x redesign, we can again launch this dedicated search query screen showing recent search history and then add auto-suggest terms on another layer as soon as the customer begins to type:

4) Putting it all together

In summary, here are the four screens of the Parallel Architecture design pattern. Note that both the category browse and search using a typed query take us to the same search results screen:

We could have designed the app in many different ways, using over a dozen different design patterns. For example, the content categories (along with an additional way to access search) could have been located in the drawer, or tabs on the second screen could have been category filters (instead of the sort order and map options) to name just a couple of possibilities. Using sticky notes, you can rapidly design and test a variety of UI approaches and figure out what works best for your customers before you make a substantial commitment to code and release your app. This is as true for Google Material Design as it is for Apple iOS8 or any of the other mobile platforms—thatâ€s what makes the $1 Prototype methodology so powerful.

So that’s it for this case study! The $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation for Material Design, iOS8, and RWD book has 30 more practical mobile UX design topics written in a unique Q&A format. The book is now available on Amazon.com.

[signature]