User Interface Design: Lessons from an Indianapolis elevator
I’m guest blogging over at marketingtechblog.com today…go check it out!
User interface design: lessons from a gas station bathroom
When a new, sexy application or device comes out, we happily invest all kinds of time playing with it, figuring it out, and being entertained by it. The initial value is in experiencing the cool technology. But most applications aren’t that sexy, and their value is simply helping you get stuff done and staying out of the way in the process.
I was reminded of this when I had to make a pit stop during a recent road trip. Observe the following “user interface” from this lovely gas station bathroom:
Now consider these observations (although I’m talking about a gas station bathroom, consider the user interface design parallels):
- I just wanted to complete a process, one that I complete at least a few times every day. This shouldn’t be that difficult.
- I had to make myself vulnerable in an unfamiliar setting; the additional (and seemingly alarming) messaging was making me even more uncomfortable. I simply was not open to new instructions in that moment.
- I was never really sure if I was using this bathroom properly. Was door even locked? Was I seconds away from an embarrassing situation? I wasn’t sure.
- As I walked back up to the front to leave, there was another confused patron receiving instructions on how to work the bathroom. I wondered how many “support calls” like this the gas station personnel had to field during the course of a day.
The lesson is this: poor user experience and bad user interface design have a cost. It’s the difference between a happy user and one who feels the need to wash their hands before returning to work.
At war with the soda machine
Working here has made me infinitely more aware of usability in everyday things. Some days I think my hubby’s ready to throw his shoe at me if I say “that’s just not usable” one more time. We had one such encounter over the weekend when we stopped to get a soda from a conveniently located machine. (I apologize for the bad resolution – there’s only so much you can do with an iPhone in a shadowy hallway.)
Take a close look … if you put your coins in that machine, where would you instinctively want to push to deploy your soda? The big shiny button picturing the actual bottle of soda, right?
But no! There are still old-style buttons on the side that have to be selected for purchase.
It’s a small detail, but considering that soda companies are now using both functionalities, it made me pause before I actually made my purchase – it wasn’t automatic. If I had put my money in, pushed the button and gotten my soda, I would have thought nothing of this interaction. I wouldn’t have growled and said “this is bad usability.” My husband wouldn’t have rolled his eyes. And so on.
But the fact that the machine didn’t do what I thought it should at first glance made me feel like maybe I was doing something wrong, or maybe I was too old to understand these new-fangled machines, or maybe even the machine was broken. But none of those were true. And in the end, it just made feel like I should have bought a Coke.
I deleted my Twitter account!
I accidentally deleted my Twitter account last week. Yes, yes, I know—that’s like accidentally driving one’s car off the road or misplacing one’s pants. So how did I do it? Glad you asked.
Like many folks, I manage more than one Twitter account. For example, I have my personal Twitter account, a business account for Tuitive, and then a couple extra accounts related to some side projects. I mistakenly thought I was logged in as one of these extra accounts when I made my way to Twitter’s account deactivation screen, as shown here:
Notice anything telling in the above screenshot? I didn’t either, and that’s the problem! While this screen does a great job of describing the dire, irreversible nature of deactivating a Twitter account, there is no indication anywhere as towhich account I am logged into and about to deactivate. I assumed incorrectly and pushed the button.
I was pretty shocked when I realized I had deactivated my personal Twitter account. To add insult to injury, Twitter would not let me create a new account using my previous username or email address, meaning it wasn’t really deleted. It was just caught in some sort of Twitter purgatory, stuck between the world of the active account and that of the deleted damned.
Fortunately after a few days of pleading-via-email, Twitter support had mercy on me and restored my account. (It came with a polite admonition, however, that this was a one-time favor.)
So, happy ending. Crisis averted. Problem solved. But what a waste of time and energy, both on my part and that of Charles at Twitter support. Here’s a super simple usability tweak to the HTML on the Twitter account deactivation screen that I’m sure would have prevented this issue from happening in the first place:
The best part is, in the time it has taken for you to read this, a Twitter developer could have implemented this and perhaps prevented another careless fool like me from making a similar mistake.
Like many usability tweaks, simple changes have huge impacts that can prevent a lot of heartache. And we all know that an ounce of prevention is worth pounds of tech support.
The public speaker’s user experience
As those of you on our e-mailing list know, Tuitive is embarking on a campaign to become sought-after public speakers. While presenting in front of a large group scares the daylights out of most people, for some reason our motley crew is really excited by the chance to get out and share our expertise with the world.
So in order to prepare for this adventure, we’ve each been developing presentations on our area of expertise as they relate to Tuitive’s core mission – then giving the presentations to each other. I spoke at my high school graduation and I’ve taught dozens of courses all over this lovely country, but this little group made me more nervous than most. Something about the fact that they all know my strengths and weaknesses, I’m sure.
I’d worked diligently on my presentation (with the thrilling title “Your Client’s User Experience”), including talking extensively to Jon (our boss), digging up relatable stories, writing notes, rewriting notes, rehearsing, and even learning Prezi (new-fangled presentation software for those unfamiliar). I put several weeks into it. But no matter how much thought I put into it, no matter how many hours, I was still bored by the damned thing. And that boredom came across when I presented to the Tuitive team.
We have a policy of being brutally honest with each other about our performances. Not cruel, mind you, but honest. Our philosophy is (1) it’s better to hear it from a teammate than go out in the world looking like an idiot, and (2) what each of us does in the name of Tuitive reflects on us all. So they let me have it: it felt rushed, there wasn’t enough audience involvement, there weren’t enough images, and so on. They were all 100% right. And I could have handed everyone a list before I even turned on the projector telling them exactly the same things.
My disinterest in my presentation came through. It’s not that I didn’t believe what I was saying, but it all seemed so elementary and common sense – like something you could find easily in 20 different business self-help books at Border’s. It didn’t feel useful and therefore I had no passion for it.
A couple months back, however, I had given a presentation to the team that I waspassionate about: grammar. No laughing – I love grammar. Perhaps it’s because it’s been hammered into me since I was old enough to talk, but I have a passion for it, and it makes me absolutely insane to hear the English language butchered regularly.
You might assume that a presentation on grammar would be far more boring to the audience than one about creating a positive client experience, right? But no, the team really liked the grammar presentation – we spent well over 2 hours going through it and discussing it, and it’s definitely changed everyone’s writing and speaking styles. Although we still have the same technical skill sets we had before the grammar lesson, we all now sound more intelligent and competent in our writing and speech.
So why did this presentation have more impact than the one about client experience? Because I was able to put myself into it. I’m passionate about educating others on this subject. (I’m passionate about client experience, too, just not about educating everyone on the subject!) My enthusiasm was infectious, the audience got involved, they remembered what they’d been taught.
The irony of the poor user experience I’d created for the attendees of my presentation on improving client user experience was not lost on me. So I’m keeping that client user experience presentation, working on improving its content, getting the audience more involved, slowing down, and finding my passion for educating on that subject as well. But for the moment, the grammar presentation is out front with me, ready to educate the world about the difference between “that” and “who.”
Viva usability
After spending a few days in Las Vegas recently, I began to notice that Las Vegas is built to overwhelm your senses, but not to allow you to actually accomplish anything meaningful. With this shocking realization I came up with 10 Las Vegas strategies that you should NOT use on a website.
- Impossible navigation – Take some water and a GPS with you and I will see you in 2 days.
- Overabundance of useless content – There is so much to see, but none of it really matters.
- Noise – It is too loud to talk. Let’s leave or go towards the loudest thing we can find.
- High cost of simple decisions – Bottled water should not cost $5.
- Misdirection – You could win a car… but you won’t.
- Lies – Free isn’t even free in Las Vegas
- Bigger is better – TVs, cars, casinos, European landmarks, 70 oz. cocktails.
- Shock and Awe – They have canals filled with water … inside a shopping mall … inside a casino.
- Elvis and pirate ships – This is self-explanatory.
- Shotgun marketing – When you target everyone, you hit no one.
These rules are certainly not enough to ensure a positive user experience, but they are a great place to start.
Until next time, keep it usable Internets… and the house ALWAYS wins.
It’s not about you
Are you about to take on a big website redesign? How about rebuilding that clunky-but-critical software application? Before you dive in, remember that the final arbiter of quality is not you, it’s your users. Here are a few steps to better understanding their needs and behaviors before you spend any precious programming dollars:
Do your user research
Start with any quantitative data, such as analytics, that you already have to see what your users are (or aren’t) doing. For additional insight, you can user-test the current site or software to see firsthand what delights and what frustrates your users. Talk with colleagues in sales or customer service to learn current and persistent user issues. Even if this research data already exists in a report somewhere, make the time to talk. The empathy engendered from an actual conversation with people “in the trenches” will naturally equip you to make more user-centered design and development decisions.
Build a prototype
Actually, make that “prototypes” (plural)— no one creates a perfect prototype on the first try. But that’s the idea: to fail as quickly, as cheaply, and as often as possible knowing that each iteration gets you closer to a solution worth building. Certainly you can build effective prototypes with HTML or Flash, but Acrobat, Powerpoint, and even paper and pencil are still excellent tools to get your ideas into a tangible format. In doing so, you can better communicate, evaluate, and test your ideas. Speaking of testing…
User testing
When some think of user testing, they imagine white lab coats and clipboards. Unfortunately, many also imagine delays and extra expenses. When forced to choose between this and no user testing at all, most choose the later. For shame! On smaller projects or those with a wicked-tight deadline, take the guerilla approach: find 6 to 10 coworkers, parents, spouses, neighbors (whoever is willing to help) and observe them individually as they complete one or two of the most important tasks on your prototype. This won’t give you all of the insight or fancy reports that formal usability testing provides, but testing even just one person is 100% better than testing no one. The results might surprise or even frustrate you, but better to know these things now than after the project is otherwise done.
The right design
It’s true that we human beings like shiny, pretty things. In technology, nicely designed interfaces are perceived as easier to use than non-designed ones. This doesn’t mean your project should be a beauty contest, however. For example, imagine if Google’s screen design utilized rich imagery and elaborate screen transitions. While this might be appealing in another setting, it would be a complete nuisance on a search screen. For Google, and indeed many others, the most “beautiful” screen design is often the simplest.
It’s worth it
We know very well the pressures on a new project to quickly “get to work” building something. It’s unfortunate when steps like user research, prototyping, and user testing are the first things to go when budgets and timelines tighten. The irony is that these will often save time and money in the long run, and ultimately keep you from unwittingly rebuilding a merely better-looking version of what doesn’t work.
What requirements?
I’m sure you’ll all be excited when I reveal that my husband gave me a humidifier for Christmas. It’s not a sexy gift, but I was genuinely happy to get it (my static-laden cats were happier than me– in theory, at least). The humidifier is lovely – tall and thin, and fits subtly into any room. It keeps the upper floor of our house nicely humidified (to the cats’ delight), and only goes through a tank of water per day. Despite all these wonderful features, I discovered a huge usability flaw the first time I went to fill the tank.
It has a lovely handle on top, as you can see:
But when I removed the tank to fill it, my user experience became a lot less delightful. The bottom handle is actually the lid to the opening for filling:
When I remove the lid to fill the tank, where do I grip it? Instead of a convenient handle to hold while I fill the tank, I’m left with a few less-than-ideal options. I can hold it by the water-delivery stem, and pray that it won’t get wet and slip – or become overly stressed by the weight and snap off. I can set it in the bathtub to fill, resulting in a great deal of overspray (to the cats’ dismay). Or I can hold it by the lip of the opening (which is kind of sharp). I generally opt for the later, resulting in less mess than option 2 and less danger than option 1. (That’s not entirely true – I generally opt to have my husband fill it, but that really is how he holds the tank.)
Perhaps the humidifier’s designers believed all their users would set this tall tank in kitchen sinks to fill. Nice idea, but I’d have to carry the tank downstairs every day to fill it. And like most consumers, I’m inherently lazy; an extra trip down the stairs every day isn’t appealing. That leaves me to choose between a deep bathtub and a shallow bathroom sink.
Grumble.
So aside from being irritated daily, what can I take away from this humidifier lesson? Requirements.
If a project team doesn’t fully flesh out requirements in the early stages of a project, and doesn’t keep revisiting requirements as the project progresses, that team will end up with an unfillable humidifier.
Or an unusable website.
When starting a project, it’s imperative to take the time to fully consider requirements. Most project teams are eager to get a project rolling – to jump right in and start seeing results. That’s great; we all love results. More importantly, though, we love successful results. Without fully identifying the objectives, scope, and end users, any project’s risk of failing to meet the project’s goals skyrockets. The impact of missed requirements can be huge, and that impact only increases as the project moves through its lifecycle.
That’s why it’s key to hold a team kickoff meeting. To document objectives, scope, personas, and site architecture. To review every deliverable with the team. And to test the product with end users. Because without knowing requirements, how can any project team accurately build any product for anyone?
Hey technology, where are your manners?
While syncing my Google calendar with my Outlook calendar, I received this message. I love that it warned me before taking a seemingly drastic action, but how do I know which 136 events it’s even talking about? I’m guessing it was referring to one or two reoccurring events that got moved or rescheduled, but the point is that I wasn’t sure and had NO way to find out. I clicked “yes” hoping it wasn’t 136 client meetings. (Fingers crossed…)
This geek-speak gave me a chuckle while I waited for my computer to begin its back-up. (My computer is either extremely slow at “reticulating” or has a crazy amount of “splines.”) Perhaps I shouldn’t complain – the back-up went fine – but this unhelpful message had a be-quiet-the-adults-are-talking tone that I found a bit pretentious. I don’t like when technology talks down to me.
This bizarre message from Outlook surprised me. No apology, no explanation, no suggestion…just a curt refusal to perform its intended function and one lone “OK” button for me to acknowledge its belligerence. Fine. But no, Outlook, it’s not ok.
At the end of the week, I thought I’d leave all these techno-hurdles behind and go fill up my gas tank. I pulled up to the pump, swiped my plastic, and waited for the electronic nod to begin my part of refined oil consumption. Instead, I was accused of some apparent “invalid loyalty.” Maybe that was just more geek-speak for a bad card swipe, I thought, so I swiped my card again. Invalid loyalty. What was going on here? Had I broken some solemn vow to Speedway? “It’s true,” I was prepared to tearfully confess, “I’ve been seeing other gas stations!” Turns out, though, that the pumps were simply set to align with the company’s current “loyalty card” marketing push. What a great example of marketing and engineering teaming up to complicate what should be a simple transaction.
As an aside, I was surprised that I couldn’t solve this pump problem on my own (I had to ask the attendant for help), but I was more surprised at how my expectations—my mental model—of how I thought a gas pump should work blinded me from considering other alternatives. But in my defense, I think it’s reasonable to expect things to work the same way they worked the previous 100 times.
It’s interesting to note that, other than Outlook refusing to send my email, the technology at hand worked exactly as designed: my Google calendar reconciled my events, my online back-up ran faithfully, and I drove away that day from the pump with a full tank of gas. Yet the user experiences were needlessly clunky. And as this blog demonstrates, that’s what we remember.
