A better design exercise
A bit of housekeeping, linking to this piece I wrote on Medium about evaluating design candidates when the UX team doesn’t share a set of core values.
Craig Mod, who convincingly argues that app development (and their success) is often completely senseless, drops this astounding wisdom on readers about halfway through the article:
The first pass should be ugly, the ugliest. Any brain cycle spent on pretty is self deception. If pretty is the point then please stop. Do not, I repeat, do not spent three months on the radial menu, impressive as it may be. It will not save your company. There is a time for that. That time is not now. Instead, make grand gestures. General gestures. Most importantly, enumerate the unknowns. Make a list. Making known the unknowns you now know will surface the other unknowns, the important unknowns, the truly devastating unknowns — you can’t scrape our content! you can’t monkey park here! a tiny antennae is not for rent! You want to unearth answers as quickly as possible. Nothing else matters if your question marks irrecoverably break you. Do not procrastinate in their excavation.
Craig’s words ring loudly in my ears. You want to unearth answers as quickly as possible. Do not procrastinate in their excavation.
Superb advice for the exploration phase of just about any project, not just app development.
Due to the fact that my posts on Tumblr weren’t being indexed properly, I decided to go the Octopress route.
I already miss Tumblr’s simplicity and the ability to post easily while mobile, but—blogs gotta be indexed, or what’s the point?!
See you at dannyoyello.com :-)
Something I hear from novice mobile designers lately is that affordances “aren’t needed anymore” because “users will just play with an app and figure things out.” When pressed by more senior members of a UX team, these designers often suggest making up for the missing affordance by highlighting the feature in a tutorial or displaying a screen overlay with tips on how to use the app.
Here are just some of the problems with that thinking.
Experimentation and reading require time that your users don’t have
In Fall of 2012 I piloted a study for my employer, Good Technology. Good makes apps for Android, iOS, and Windows Phone that let a company’s employees collaborate securely from wherever they happen to be throughout the day. I wanted to see how well our products supported senior executives, whose needs typically differ from those of the rank and file.
I was shocked at what I found. Our own big shots—the people with the highest compensation, the most stock options, and ultimately the most to gain from our company’s success—weren’t using our apps.
“I don’t have time to set up the apps,” one admitted. “I get to configuration and think, ‘I don’t have time for this right now. I’ll come back to it later.’”
“I never spent the time to learn it,” another said sheepishly. “I’m sure it would work, but I’ve just never tried it.”
It was hard to believe, but these executives were too busy for apps that could not only help them with their day-to-day work, but were the same apps upon which their own livelihoods depended.
In case you’re tempted to consider these executives outliers, even “average” users are becoming famous for trying an app once or twice and then deleting it. App creators have a very short window in which to hook potential users. Discovering hidden features and reading tutorials require a time commitment that a tiny fraction of your potential user base is willing to make. The bottom line? Don’t assume that anyone wants to invest time in your app.
Missing affordance means missing feature
As part of the same study, I interviewed an executive assistant who supported the Chief Revenue Officer. She was frustrated that there was no setting for the number of message-preview lines for the emails in her Inbox.
“Yes, there is,” I said. I had an inkling of what was going on, but I played dumb. “You didn’t find it?”
“No,” she said, and looked again at the app on her phone.
“Do you see a way to find Preferences?” I asked.
“Preferences? There aren’t any!” she said.
The tab bar across the bottom of her iPhone screen contained icons for Email, Calendar, Contacts, Tasks, and Documents. I reached over and swiped the bar from right to left. Suddenly, icons for Browser, Applications, and Preferences slid into view. She gasped.
Clearly, she hadn’t read the tutorial.
I could only be embarrassed for the UX team, because I knew the story behind the error. The lead designer hadn’t wanted to add an affordance for swiping the tab bar, and management had backed him on it. Some of us knew that some users would never discover the swipe—but we didn’t know there would be one just down the hall who was responsible for supporting our own Chief Revenue Officer.
Missing or “surprise” features result in annoyed users
I won’t forget one IT Director I spoke to during a usability test. He was trying to perform a task using the native iPhone calendar, and as he turned to show me the screen, the phone’s orientation rotated to landscape. Suddenly, he found himself looking at the calendar’s week view.
“What’s this?” he asked, startled.
From the tone of his voice I could guess what he was thinking, but I wanted to demonstrate his reaction to my team, who were observing the test from another room. “It’s week view,” I said. “You just turn the phone sideways, and…voilà!”
A storm cloud passed over his face. “Week view? Do you know how much time this could have saved me if I’d known about it? And it’s been here all this time?”
He was irate. iOS 5 had been out for months, but with no affordances to go on, he’d had no idea that week view existed. He lost some faith in Apple that day.
If you think users don’t need affordances because they can learn to use your app by playing around with it or by reading a tutorial or hints screen, think again. Most people are too busy to spend time getting acquainted with your baby. They’ll jump right in, skip tips, and miss important features—and some of them won’t forget that you wasted their time.
There’s an old saying that goes, “The only numbers developers care about are 0, 1, and N.” Sounds like the punch line to a bad joke, right? But what it means is that developers have to make sure their code accounts for those numbers.
Once I heard this saying, and the reason for it, I tried to remember those numbers when I was designing. For example:
As it turns out, there are other special numbers when it comes to UX design. One of them is the number 2, as I recently noticed while using Twitter for iPhone.
I have two Twitter accounts, and sometimes I switch between them to tweet different types of things.
Here’s what my main account’s profile looks like. If I tap the “Accounts” button, I get a list of my accounts.
To switch, I tap the button, pick my other account, and wait for the window to close.
But wait. I only have two accounts. Why, when I tap this button, should I have to see a list of accounts and manually select my other account? When I have two accounts configured, Twitter should just swap them. That button should just toggle between my two accounts. The number 2 is a special case.
So, some numbers to keep in mind while you’re designing: 0, 1, 2, and N. And there could be others, depending on the domain you’re trying to accommodate. You might want to add them to a design checklist that you keep for yourself to make sure you haven’t missed anything before your next design review.
Jack o’ many UX trades, master of some. Occasional writer. Friendly curmudgeon. Ex-Good Technology, Nokia, Valtech, Perficient.
Mountain View, CA