The increasingly shrill decrying of texting while driving has made me more conscious of the alternatives, and a new problem arises for me as a designer.
Yesterday as we drive home, Alison is talking to my mom about radiation therapy appointments for my dad. Turns out we have the dates and times, so it would be most convenient to just go ahead and add it to my schedule so I don’t forget or have to call back. And our drive is around an hour, so its not totally plausible to just hope we remember until we get home.
So, I hand my phone to Alison who… stares at it. I think it’s trivially easy to use and am likely to keep buying handsets from this maker as a result. There’s a calendar icon right on the idle screen, for example. But she can’t find it. And when I tell her what to click, the calendar works differently from that on her mobile. And the text entry mode is different (space and next keys for predictive, for example, are there but in different places).
Whether it’s showing off pictures of the grandkids at a dinner party or trying to get a passenger to perform some navigational interaction to avoid distracted driving, I see this just getting more and more common.
“This” being the notion of first time use. Most mobile interactions I have worked on focus on learnability and habituated use. Whether it’s about learning the app/site, or just assuming the user has become used to their phone, the personal nature of mobiles means that’s a safe bet. But now I am starting to wonder if it really is.
Even aside from the stuff I do as a nerdy mobile designer shoving hardware into people’s hands – I am seeing more and more opportunities for device sharing. And it seems to be a known, if subconscious, problem to everyday people. Do you hold up the phone to show off the video, or pass it around? When they “break” it, do you tell them what to do, or have to take it back? (And how distracting is it to give step-by-step verbal instructions on using your phone to someone next to you, that you cannot really look at?)
A solution for me would be if all handsets, and all apps on the handset, were easy to understand for first time users. And I mean, arbitrary, ad hoc first time users. For example, I am playing with the Palm Pre; the neighborhood kids often want to mess with whatever new hardware I have laying around, and keep trying it out. As someone who set up a user profile and got the intro video/tutorial thingy, it’s reasonably easy for me to use. But the kids missed this. And there’s no affordances for back, or home, or killing an application. They are savvy enough to know those functions must be there, but still cannot find them.
So a first guideline for me is primary actions have to be obvious. This doesn’t preclude cool shortcuts with gestures or otherwise hidden features for the habituated user. But give an easy-to-use version as well, or add a hint.
Ideally, there would be more shared features between devices so it was clear how to perform at least the most basic functions on any device. Cars, for example, settled some time ago into a standard form, so you know how the turn signal works, and there are only so many ways the headlights are likely to turn on. And if you cannot drive a stick, it’s only one of two likely mechanisms, so you know you can’t drive that right off the bat.
And with these standards, there’s plenty of style, performance, build and design differences between makes, models and variants. For mobile (and really for interactive in general), I hope someday we can settle on some common UI components (and get everyone used to all of them) but for now, the best we seem to be able to do is emphasize guidelines and best practices.
Looking through my own design documentation, I don’t see anything consolidated about first-time use, so I thought about it a bit and have thrown together these guidelines.
Use common metaphors – Even if you are designing something with a different interaction method, you will tend to get far exploiting an existing metaphor. I cannot think of a calendar that uses a wheel or strip or dancing-antelope view; they all look like paper monthly calendars for a reason.
Make behavior predictable – If you employ a common UI element, make it act like it looks. Buttons should… submit things. Little, labeled enclosed areas with down arrows should open up into lists or menus. And if you make a wholly new interactive element, don’t hang it off one of these existing structures; make something new and give a (visual) hint as to what will happen when it’s activated.
Readability – I don’t mean that type needs to be big enough for the elderly, because you should be doing that anyway. I am referring more to comprehension. If someone can just stare at the icons in the footer and wonder what they mean (i.e. always), they need to have labels. If you are not sure, add labels. Or go ahead and test those icons in front of users, but you’ll be surprised at how badly it goes. Even when you think the plus sign is unambiguous, people who didn’t design or develop the product will wonder if it’s to add an event, a person, a profile, an access point, a new document or just opens up the panel to reveal more choices.
Make the structure visible – Your regular user can take time to get used to the underlying information architecture of your device/site/application. And often, it’s easily solved by having them explore (to even get lost they had to drive down from the top level). But casual users borrowing a handset might start anywhere. Do something to make the structure visible, or discoverable. Especially think about how misunderstanding the overall informational paradigm can get in the way of performing tasks. Auto-save vs. explicit-save is a huge problem in this space, and even causes issues when inconsistently employed for habituated users.
I am going to continue to keep my eyes open for interesting behaviors and opportunities to improve this, now that I am aware of it.