Designing for everyone

At the last Communitech usability peer-to-peer meeting, Adam Baker, UI Designer at Google, took us through an interesting exercise. Working in teams of four, we had to design the user interface for an application used to order pizza. Each team was given a constraint to work with. My team's constraint was that our user has an old blackberry and is travelling home from work, on a train.

All my team members had had sufficient time to introduce ourselves to each other, and we did not find it very hard to communicate our ideas, to talk about our design decisions and come to a compromise where needed. Our design met the simplicity criteria and consisted of one screen that asked for input for the telephone number, the delivery address and the delivery time. We considered using one screen per input to accommodate the small screen size, but settled on the one-screen design for ease of readability and navigation.

At the end of the eight minutes allotted for the exercise, we were asked to merge with another team and to re-design to accommodate the second set of constraints. The new constraint we had to deal with was that our user is blind. To adapt to this new constraint, we adopted the merging team’s idea of a voice-enabled application that tried to automatically get all the input from information already stored on the blackberry, and then repeated all this information to ask for a verbal confirmation. Since we were also working with an old blackberry, we designed the application to simply dial the phone number of the pizza store and to let the computer system at the store handle the voice input processing. We also switched to our original design consideration of one screen per input to simplify voice processing.

Our merge flustered us a little bit initially, but we thought the new constraint did not change the user interface design enough to cause us much concern. However, we were asked to merge yet again. This time, we moved from eight team members to sixteen, and we took on two more constraints; the first was that we were dealing with a first-time online user, and the second constraint was that the user had only two minutes to order the pizza.

The last merge was more challenging, particularly because the team size was too large to be able to gather and ponder over every person’s input, and because we had the least amount of time to make design changes. We were faced with numerous questions; are we mandated to use an online application, instead of an installed application? How will a voice-enabled system be able to verify all the input within two minutes? If the application is dependent on a phone connection, and the user is travelling on a train, what will happen if the train goes through a tunnel and the connection is lost? Our blind user will be caught unawares in this situation. How will the application recover from this and will the user have to start all over?

We did not have enough time to answer these questions in a satisfactory manner. There were, however, many lessons to learn.

1. The exercise tries to simulate what it is like to design for an extremely large audience, all with different constraints.
2. The larger the design team, the harder it is to come up with a simple solution.
3. Different design teams bring different perspectives into the design process.
4. One solution is not necessarily correct.
5. The more constraints there are, the more complex the interface becomes, and it risks becoming inconsistent.*
   
   

Here are some general guidelines and retrospectives that Adam shared with us:

1. Understanding your users requires creativity. You have to be able to differentiate between different users and recognise common patterns in order to group your users. Instrumentation and A/B Testing are two techniques commonly used to recognise usage patterns. We can measure by answering questions such as how long, how many, how often and when.
2. Designing Google’s Search UI was like designing for the back-country, where everything must be light-weight, multi-purpose, fast and adaptable.
3. Little things matter. Simply changing the shade of a line colour can make a large difference in the user’s satisfaction.
4. Intent is ambiguous. What does it mean when a user types in “TV” into the search UI? Does the user want to know the difference between a plasma and an LCD TV, or does the user just want to know what’s on TV? Keeping in mind sensitive issues, what results do you display when someone types in “Where do babies come from?”?
5. The design of Google’s search UI was all about co-operation between people from various disciplines.
6. The aim is for speed and simplicity of design. While most people do not search all day, many people search something every day, so speed is crucial. Similarly, a simple UI should highlight the obvious, and then provide details that users can delve into if they want.
7. The design commonly reflects trade-offs between speed and elegance.
   
   

* The combinations of constraints other teams dealt with were:

• The user is a nine-year old with an I-Pad, and is ‘just like us’.
• The user has both an I-Pad and an old blackberry, has two minutes to order the pizza, and cannot type.
• The user is a nine-year old, is blind and illiterate and wants to order hundred pizzas for hundred separate locations.