Adventures in overturning usability assumptions
The most humbling and enlightening parts of being a designer is when you look at your education — what you know about “best practices” and “modern usability” — and see that knowledge go to shit. When you realize that that’s not the way your audience thinks or uses your design. You question whether or not you’re a good designer. You question why you’re getting paid to be wrong.
Here are a couple of usability and visual design questions I’ve heard recently:
Question: “You’ve designed some stuff that looks so fresh and engaging! How do you think you’ll be able to engage kids?”
Answer: “I have no idea. Let’s see what the kids say.”
Put down that freshly forked UI kit and step away from Dribbble. Toddlers don’t care about “engagement drivers” and design that’s “clean” and “modern”.
I recently designed an app for kids. The target demographic didn’t exactly align with my own: This was an app that was to teach English-and-Spanish speaking kids age 3–6 about nutrition. The app was to be downloaded after watching a series of cartoons about nutrition shown during class hours.
There are plenty of examples of products that we as adults consider “beautiful” and geared towards kids: Tocaboca, for one. The nutrition cartoons were not what we considered to be one of those examples. Still, the kids liked the videos. It wasn’t our priority to design our assumption of what a “rich and engaging” experience was. It was our priority to create an experience that seamlessly translated from the cartoon they saw in class to the mobile app in their hands.
Question: “How do we make this app simple enough for [insert target audience who presumably doesn’t understand ‘tech’] to use?”
Answer: I don’t know how to make someone “understand” something they haven’t seen yet. Let’s observe how comfortable our users are with technology before making any assumptions.
We built an app for nurses. Observing them while they used the prototype was critical in defining our design decisions; decisions we wouldn’t have made if we had gone off of modern usability assumptions. For instance, a core feature of the app was to let nurses set deadlines on their tasks so they wouldn’t forget what they have to do throughout the day. The types of time-sensitive tasks nurses had to perform varied:
- Turn patient over in bed once a day, as needed
- Administer meds at 5:00pm, follow up in 30 minutes
- Change IV bag every 2 hours
In order to account for these types of time-sensitive tasks, we had to design an interface that was comprehensive yet simple enough to understand and follow. An early prototype used a tabbed interface and assumed that the nurses needed to see all available deadline formats to select a proper deadline.
After testing this iteration, we discovered that nurses found the formats confusing. Instead, they were tapping on the task title label, expecting to fill out the time there. This was in line with the way nurses traditionally took notes: with pen on paper. They would write down the task and then simply write the exact time they had to perform the task.
So we changed the deadline input to a dropdown with a default generic option. That way, when the nurse tapped on the question label, the select would open, letting them see their available options.
The conclusion is thus: What you assume to be best practices can be wrong. It’s important to establish to define customer behaviors so you can focus on one usability problem at a time.
