Getting Lost in the Software: Context, Part 1

I’m a great driver. Well, I’m a pretty good driver. I’ve had some accidents, but they were all a long time ago. In the last millennium. And that’s like a thousand years.

But that’s not the point. I’m a pretty good driver, but I’m a bad navigator. I get lost. I rely heavily on GPS and Google Maps and Apple Maps and that weird navigation app in my car. I get turned around. I come up over the rise expecting to see the ocean in the distance, but I see downtown.

It seems to happen suddenly. I’m driving along, on streets I know, doing fine. I take a turn one block too early, and end up somewhere new. I don’t panic; I keep driving, looking for a new route back to familiar territory. Then suddenly I realize I have no idea where I am, or even which direction I’m headed.

The story gets boring fast: Google Maps saves the day, and I get back on track. But that’s not the point either.

This is, obviously, all about software. About user experience. About that point we have all gotten to in a UI where we suddenly don’t know where we are, which direction we are headed, or how to get where we want to go. But in software there’s no Mekhi Phifer Google Maps. Well, OK. There is. But that’s not the point.

The point is that people get lost in software. They lose track of where they are, how they got there, and how to get back on track. They push a button, submit a form, click on a menu, and suddenly things change from comfortably familiar to new and confusing. People hate that. I hate that.

It’s all about context. When I’m driving around town I am always — either consciously or unconsciously — looking for familiar things: streets, buildings, hills, lakes, oceans, mountains, Starbucks, whatever. These are my reference points. My context. I know where I am because I recognize that Starbucks. It’s the one without a drive-through. I hate that.

Context, that collection of familiar reference points that keep us from feeling lost, is sadly missing in a lot of software, especially enterprise software. It is often difficult to determine the following:

• Where you are
• Where you came from
• Where you are going
• How you get there from here

You know you’re lost in the software when you’ve just clicked on something, and suddenly everything familiar has gone away. Maybe a screen popped up in front of the screen you were on. Maybe something on screen disappeared. Or maybe you found your way into a new section of the software, but don’t know how to get back.

So you keep driving. You poke around, you hunt through menus, you even try right-clicking, because then you get what’s called a “context menu,” which should give you context, right? Yeah, no. You quit and restart the software. Sometimes it works, and you find your way. But all the while you’re wondering what happened, and you’re not sure exactly how to avoid it happening again (or what to do next time).

The problem is a lack of context. When there are not familiar reference points, and no indicators of which way to go next, getting lost is inevitable. Software lets you down by not giving you what you need, by not telling you what you need to know. Software could be so much better.

Let’s go off-road for a moment, and talk about video games (because that’s what we do; that’s all we do). Video games have a tendency to get context right. In most games it’s easy to find your way. The sign-posts are clear, the visual queues tell you exactly where you are, and often a game will actually push you in the right direction. Many games even talk you through the hard parts. They’re like Google Maps that way. I love that.

Think about it. How many times have you started a brand new video game, and within minutes or even seconds of starting the game, you can figure the following:

• This is you
• That’s your friend
• You are here
• Your friend is over there
• You want to get over there
• Here’s how you get there

And, while we’re at it, you quickly figure these out, too:

• Here’s what you have
• Here’s what you can do with it
• Here’s what you want to get
• Here’s what you’ll need to do to get it

In typical enterprise software there is no you, there is no friend (not even a co-worker), and there is rarely any indicator of where you want to go or what you want to do. There is only:

• Here’s a menu
• Here’s a widget

So we get lost. We all do, eventually. Not just the pretty good drivers, like me.

But it doesn’t have to be like that. Enterprise software could, in fact, get so much better. The solution is to learn from video games how to show your users where they are, where they want to go, and how to get there from here.

In the next few posts on Enterprise Playability we will discuss how to show your users where they are, where they want to go, and how to get there from here. Some of the ideas will include modern improvements on the breadcrumb trail, knowing where your users are going before they do, and literally installing Google Maps in your software.

The Metaphor: Sometimes a Desktop is not a Desktop

Software is often (though not always) designed using some sort of metaphor to give users some context, something familiar to recognize early on. The idea is that a more familiar interface will lead users to a quicker understanding of the software and what it’s about. The metaphor may also give users the sense of comfort that familiarity is supposed to breed (it is comfort, right?). Examples include the Windows desktop, which is supposed to look and act like a desktop; Excel, which looks like a ledger, or maybe just a pad of graph paper; and the contacts app on my iPhone that looks like an address book (or at least it used to).

The choice a designer makes about how to represent context in software makes a significant difference in usability. A well represented metaphor can give a user a reference point, something to help make software more accessible. Early understanding will come easier. Users see an interface and quickly think “Oh, OK. I get it.”

But as soon as that metaphor breaks down, and the connection to the real world is lost, the user becomes disoriented, and gets lost in the software. Sometimes that happens immediately: the Windows desktop doesn’t look like a desktop, it doesn’t work like a desktop, and the metaphor doesn’t hold. The same can be said for the Mac desktop. Neither is anything like an actual desktop. The metaphor has very little value, and the functionality of these “desktops” is easiest to understand if you just ignore the metaphor altogether.

There are other options. One is to forget about metaphors altogether, and let the software explain itself in other ways. Just make things easy to use, without focusing on holding a possibly tenuous connection to the real world.

This is the approach that Jonathan Ive prefers at Apple, and apparently there was some disagreement between Ive and Steve Jobs about skeumorphism: designing apps to look just like their real-world counterparts. The iPhone contacts app looked like an address book, the notes app looked like lined paper, and the calendar app looked like an expensive, leather-bound, paper calendar. They used to be skeumorphic, but Jobs is gone, and Ive has made some changes.

Eschewing metaphor works well, especially for simple apps on a smartphone. The metaphor can be distracting, or act only as window dressing, without improving usability at all. App designers have no trouble keeping app interfaces simple and easy to understand, without need for a visual link to the outside world.

But honestly, where’s the fun in that? If software takes a more literal approach, and provides a visual representation of the real world, the reference point can be established more deeply. If the connection to the real world can be held, the understanding will hold, too. As long as visual context is consistently represented, software remains accessible, understandable, and ultimately more usable.

Video games balance this equation a bit differently than most enterprise software and productivity apps. Games are often fully representational: they put you in a world that looks and behaves just like the real world. It’s extreme skeumorphism. Actually, it’s just realism. In 3D games you’re fully immersed (or at least somewhat immersed, depending on the quality of the game) in an environment. You interact with representations of things that are designed to look just like those things do in the real (or imaginary or fantasy) world. The more those things look and act like their real or imagined counterparts, the better the experience.

But all the while, video games present players with an added layer of interface, using heads-up displays (HUDs) and menus and mouse, keyboard, and touch interactions. None of those need to be exact representations of the real world. In fact, because the illusion of immersion works better with fewer distractions, HUDs and menus and any other UI elements are often minimal, hidden, or even semi-transparent. They cloud the action, so we keep them out of the way. You see only what you need to see at any given moment.

In video game UI, metaphor doesn’t help. A good HUD is easy to understand, but it does not necessarily correspond to something you might see in the real world. Even the most exceptional HUD proves the rule: in some first-person shooters there is a HUD that looks just like the HUD a soldier might have built into a helmet or goggles. But that’s not a metaphor: it’s an extension of the immersive experience. It’s literal. It’s realism.

Where does this leave us? Skeumorphism is an option. Metaphor is an option. But good UI can be much more efficient, and much easier to learn and use without metaphor, because if there is no metaphor, the UI doesn’t require that the metaphor hold its connection to the real world. The connection doesn’t break down, because there isn’t one. An immersive experience builds the best connection between the user and software, but even in immersive worlds we need UI elements that are not representational and are not metaphorical.

Motivation: What Makes Us Feel Good About Our Work?

Dan Ariely’s TED talk is a good one. It’s very straightforward, and gives some good ideas about what motivates people. It can be especially helpful when considering a rewards system within enterprise software. It’s important to think beyond the money that workers (our users) are rewarded with. The challenge is to include things like meaning, creation, challenge, ownership, identity, and pride. That notion — that we need more than just payment as motivation — is at the heart of enterprise playability.

Visual Environment

Video games often present players with a very specific, stylized visualization of an environment. That environment gives players a context in which to relate to the game and all of the objects in it. Visual representation and interaction with in-game items keeps players engaged with the game, and draws their focus into the activities they are participating in within the game.

Enterprise software, on the other hand, tends toward the abstract and metaphorical. Enterprise software designers prefer that anything that needs to be presented on screen fit within one of the widgets that are standard in the industry: drop-down lists, text boxes, buttons, data grids, radio buttons, and check boxes. These components make software design easier and faster. Enterprise software is often presented within a loosely defined metaphorical context: the desktop, the document, the worksheet, or the window. The connections between the real-world object and the software are few and generally not helpful. Knowing how to use the real-world object doesn’t help with learning to use the in-software object at all.

To resolve this disconnect between the real world and the user experience, an enterprise software designer can use the same strategy that video games do: Create a world within the software for users to enter. Give users a set of surroundings that are both familiar and helpful. Show them a world like the world they are working in. Users will be far more engaged, and will quickly learn their way around the software. Users’ experience in the real world will help them understand the software.

The Cocaine Thing

So this is apparently a thing: Video games tap into the same pleasure centers in the brain that are affected by cocaine. It’s true. There are studies and stuff. Even books.

So it seems like a good idea to do something awesome with that information. Why not use that ever-so-simple fact to inspire better enterprise software? Seems like a natural enough progression. If we really want to engage users, we should learn lessons from cocaine dealers. We should treat our users like cocaine users (in a good way, of course).

Full disclosure: I’ve never sold cocaine. Turns out I’ve never even used it (I only recently moved to LA). So the following ideas are pretty much sourced from movies, not real life. But how different can they be?

Here are eight lessons we can learn from cocaine dealers:

1. The first one’s always free
   Give users their first reward for doing little or nothing at all. The first reward should be just for showing up. Even if users haven’t signed in yet, they should feel like you already appreciate them, and have lots of rewards to give them.
2. The next score should always be within reach
   It should always be clear to users how they will get their next reward, and the tasks needed to get that reward should never feel like too much work.
3. It will take more and more to satisfy the jones over time
   Bigger and bigger achievements should always be just down the road. The same bonus for showing up won’t satisfy users every time. They need to feel like they’ve done more, and are being rewarded for more, each time. Balance this with number two, above.
4. If we do not satisfy the jones, our users will crash out
   If a user can’t score, that user won’t come back. That user will disengage and wander off, and re-engaging that user will be exceedingly difficult.
5. Users in a crisis will not be loyal to your brand
   Again, if a user can’t score, that user won’t come back. That user will go to someone else, someone who provides the rewards they are looking for. If you are not helping your users get what they need, they will find someone who does.
6. Users need you, and will come to you
   You help users get what they want. You make their misery tolerable. You are what they think about when you are not around. If those things are not true, you are not selling cocaine (or anything like it). If they are true, users will keep on coming back to you.
7. Users won’t always keep reasonable hours
   Availability, reliability, and ubiquity are must-haves in your industry. Your users will be thinking about you at all hours, and will seek rewards whenever the thought crosses their minds. You must be there for them at all times.
8. Users party in all kinds of places
   Wherever your users go, you need to be ready to support them. Be there for them at work, at home, and everywhere. Let them get their fix anywhere they go. Always be there for them, and always be ready to party.

Too much of a stretch? Maybe. Maybe not. But engaging users, and designing a user experience that keeps users coming back, is not easy. This is probably just what you need.

Real Rewards?

The question comes up often in designing gamified systems: Are the rewards actually worth anything? Can I trade then in for something?

Great article addressing the topic: Motivating Through Games.

At MOC1 we ran an experiment on this very topic, to see if rewards with little or no value (we used Post-It notes, each with a star scribbled on it) worked as a motivator. The experiment was short-lived, but highly successful. Team members responded brilliantly.

The notes themselves were posted to a bulletin board, under the names of the team members who earned them. So it was a leaderboard. It was clear that the notes themselves weren’t what people wanted, but rather to see a stack of stars under their names, and to have more than their teammates.

The team also responded well to Post-It stars given to the team on days when everyone on the team earned a star.

At one point one of the team members approached me to ask “Are these stars worth anything? Can we trade them in for something?” I just said “Right now I’m not sure.” It had no effect, positive or negative, on anyone’s behavior.

Our conclusion was that seemingly empty rewards are a strong motivator, when shown in a leaderboard.

Watch Magic Leap’s Video Of Seamless Augmented Reality Office Game Play

We could probably do this now with Google Glass…

Sight shows us just how awesome gamification can be. And apparently the answer is WAY TOO AWESOME.

Motivation and Ease of Use

The key components of Enterprise Playability are gamification and video-game-like usability. When designing an app with EP, a couple of important  questions must be addressed early on: What should users be rewarded for? And which functionality should be playable? Two of the fundamentals of EP are:

1. Make it easy for users to meet their own goals
2. Reward users for meeting business goals

Understanding user goals is just as important as understanding business goals. In user-centered design, designers must capture and design for both. 

Great video games are easy to play because they make it easy for users to understand what to do and how to do it. They keep users engaged by rewarding for meeting specific goals. Think of an arcade shooter: You pick up a gun and shoot at stuff. Fun! Easy to get! Your simple user goals (“shoot stuff,” “blow stuff up”) are easy to achieve. Your score, however, is tied to shooting the right stuff, and also not shooting the old lady holding a bag of groceries. Those are the business goals, and you get points when you get them right. 

In an enterprise app, core functionality should support the primary goals of the users, and make them easy to achieve . Rewards should motivate users to meet business goals. Think of a point of sale app. The user wants to inform customers, make sales, and get a big fat commission check. Management wants to sell more of the high-margin items, capture customer phone numbers for follow-up contact, and keep customers coming back. 

So the easiest activities in the app should be:

• Sell stuff
• Get information about stuff
• Sell more stuff

Rewards should be for:

• Selling the right stuff
• Capturing customer contact info
• Repeat visits from happy customers 

The end result is happy users who are excited about doing their best to meet business goals. 

Steve Blank: Lessons From 35 Years of Making Startups Fail Less

Off the topic of what to do (enterprise playability), and on the topic of how to do it, Steve Blank’s Lean Startup has the makings of a revolution. After you read Eric Ries’ The Lean Startup, and then pick up a copy of Steve Blank’s The Four Steps to the Epiphany, you will no doubt like me be looking for interviews like this:

http://99u.com/articles/7256/steve-blank-lessons-from-35-years-of-making-startups-fail-less