In design, we push ourselves to see past what our users do, and try to understand why. It’s challenging to keep that sort of high-level focus. But it’s essential to creating something that fits into the larger workflow: into the lives of our users. We build answers to life’s challenges.
But sometimes the answer is that your user can’t wait to stop using the thing you’ve slaved over.
“What does the user want to do?”
The scenario: your team’s had a twenty minute conversation about whether Trending Stories should appear on the left or right side of the page, and have formed strong, intricate opinions about HTML5 and font sizes. The developer’s worried they’re going to have to rip out all CSS and rework it, while the product owner is talking about ad placements and mindshare.
And then Upanita says, “What does the user want to do at this point?”
And you fight about that for a while, because marketing would love for the person to click on more stories and sell more ads, visual design wants to enhance the reading experience by balancing the weight of the body content and the surround, and engineering just wants the page architecture to be flexible enough so that next week they can rearrange it to fit their new favorite web framework.
“The goal,” Upanita asks wearily. “What’s their goal? Why are they here?”
And you all look around, because they’re trained not to say “The user is here to visit our website.” That doesn’t lead to good design outcomes; it doesn’t lead to products that fulfill real user needs.
But on a certain level, that’s what the site is designed to do.
Meta-Goals: Why Does Your App Exist?
To understand this situation, we need to go one level beyond user goals, and think about the goal behind the goal. I’m going to call this the meta-goal: it’s a category of goal, a raison d’etre for your site beyond “sell shoes” or “aggregate news” or “maintain a web presence”.
There are three meta-goals when using an app:
- Stop Using This App
- Keep Using This App
- Live With This App
Let’s examine each in turn.
Meta-Goal 1: Stop Using This App
You might call these transactional applications. The goal of a stop-using is to finish some task, and then go back to whatever you were doing before.
That old UX classic, the ATM, is a perfect example. No one says “I’m heading out tonight to use the ATM all evening! It’s going to be a hot night in front of a tiny screen for me!” No — their meta-goal is to be done using the ATM; it’s a step in a larger plan, one that involves having more cash or fewer deposits on one’s person.
ATMs are designed accordingly. They’re very task-focused; the design seeks to minimize steps and maximize throughput.
Likewise: a grocery check-out kiosk; a “new mail” notification on your smartwatch; a voicemail system; the interaction between the customer and the cashier at Starbucks. These are all designed to let you achieve a specific set of goals in as efficient a way as possible.
As a result, stop-using apps are amenable to traditional goal-based design. Identify the user’s goals, minimize the steps needed to achieve those goals, and grind it down to the bare essentials. Trickle in some delight, so that it’s a pleasant experience, and can have got a great user experience.
Meta-Goal 2: Stay In This App
The stay-here application is the exact opposite. Its goal is to keep you here— to make you want to stay there. These are the ‘lifestyle’ sites, the ones that suck you in all afternoon or until three in the morning.
Facebook is the modern exemplar; its continuous scroll sucks you in, then feeds in more and more tenuously-connected content in an attempt to keep you scrolling. “The relative of a friend you last saw in 1982 just liked a comment on a post made by someone you don’t know! Check it out!” Anything to avoid the dreaded, and mythical, bottom of the page.
(You have reached the end of the internet. Please go back. Now.)
Many games work this way, too. Pac-man was intended to, though an infamous bug also gave it an “ending”. (Much to the chagrin of players skilled enough to play ‘forever’. I did see a guy hit this, once, in a bowling alley in my home town.)
Infinite-content games (e.g. procedurally-generated roguelikes) make this explicit. But even finite games have “stay here and play” as the meta-goal. They want to keep you happy to be playing, happy to continue what you’re doing through a repeated set of small, achievable tasks and subgoals.
When it’s done well, we call this ‘engagement’ and label it good design.
But it’s only good design if your user shares your meta-goal.
Sadly, sometimes designers of a stop-using app mistakenly believe it to be a stay-here. Sometimes there is pressure from other constituencies to “make the site sticky” (so we can serve them more ads, or for darker reasons like making unsubscription difficult.)
Unwanted “sticky” interactions are problematic. If the user wants to perform their goal and get out, and you make any of that harder, it chafes. It’s like that charity you sent a check to back in 2003 that still sends an envelope every week. Take a hint! It was transactional! Or an awkward conversation on an elevator that is taking too long to get to your floor; you both signed up for a quick social interaction, but are suddenly stuck with a longer one than either of you wanted.
The opposite is less problematic, but also common. If the app is too transactional, users may feel lost at the end of the transaction. “Okay, I read that article, and now…nothing? What else can I do here? Did they write anything else?” That’s a good indication you need to build in more engagement.
Meta-Goal 3: Live With This App
There’s a third, interestingly-different category, and it’s on the rise. This is the app or site which you use all day long as a part of something else.
The one you likely use every day is your car’s dashboard and center stack. (If you drive a car, that is.) Your goal isn’t to use the dashboard — your goal is probably something like “drive to work”—but the dashboard significantly enhances your ability to drive. The dashboard constantly shows you speed, which is helpful for avoiding tickets or for deciding whether to grouse about the slow-poke in front of you; it might also show fuel economy, which is helpful for learning to drive efficiently. On demand, it shows you error messages. It gives you control over entertainment, which isn’t necessary for the driving task per se, but which most of us consider an essential addition.
About fifteen years ago we collectively decided that showing movies in the dashboard was too much; it modified the experience from “driving augmented by the dashboard” to “watching a movie, occasionally checking in on the driving process”. It was dangerous, and now it’s rightfully outlawed.
Live-with interfaces have to respect the context of their use; they have to be designed to be used in situ. A recent example of this is CarPlay, Apple’s attempt to water down the smartphone experience to something that can be used moderately-safely when driving. It almost works, in that it is less distracting, but it’s also significantly less capable, and has a handful of annoying quirks which suck drivers’ attention away from the road. Frustratingly, it doesn’t integrate at all with the car systems; it’s simply a screen into a subset of the phone’s capabilities.
Live-with interfaces need much more context awareness than other varieties. They should be designed from the ground up for their intended use, and may need additional sensors or other input. That car dashboard is designed for use while driving, and has special knowledge of what’s going on in that car. Many dashboards won’t let you use certain attention-sucking screens when the car is in motion, and rightly so.
Likewise, a live-with grocery store app might need special awareness of the store itself. Phone apps exist that let you sort your grocery list by aisle, given a store; coupling that with accurate location sensing would yield a good source of information, but the app would also have to let you attend the environment around, you lest you crash your cart into everyone. And, of course, augmented reality can become susceptible to intrusive commercialization...
Live-with apps can also be play-with apps. For example, I play the tabletop miniatures game Malifaux.
There’s a lot of details that change during play. Each model can take damage, get poisoned, even be lit on fire. On top of that, it’s important to know what turn it is; what the score is; what objectives have been completed, and which are still available. Because it’s a tabletop game, players gravitate toward using physical representations of this state — small colorful markers, dice, templates, and the game’s signature playing-card-style stat sheets.
But a handful of phone apps have also sprung up to help you keep track of the details. Something as simple as a turn-counter, or as complex as a per-model condition tracker with awareness of each model’s abilities, can help the players focus on the strategy and visual appeal of the game.
Having bravely asserted that there are precisely three things in a category, I will now mention a bunch that don’t quite fit.
Variant: Go away, but come back
When you order from McDonald’s, the people prepping your burger and fries have a screen they interact with — the order screen. It tells them what to prepare; they push a button to acknowledge the order, turn their attention to the food station, and prep their part of it. Then they return to the screen, press a button to move on, and the cycle repeats.
This is a “go-away-and-come-back” situation, a combination of stop-using and live-with. The meta-goal of this sort of UI is to send you away; but the goal of the system as a whole is to keep them there until some goal is achieved: until their shift is over, until all pending orders are filled, or until some quantity is prepared.
Variant: The app is the environment
Some ‘apps’ aren’t really apps, per se; they’re the environment you work within. These are a kind of live-with apps, but the app is all around you. The user becomes part of the app; the fleshy appendage which performs the tasks that robots can’t yet do cheaply enough.
The modern assembly line is an example: a worker may have an assembly station with a large number of parts bins and tools around them. There are sensors — for example, IR triplights over the front of a bin—which detect if they try to perform steps out of sequence.
Variant: Enhancement Apps
One more variant to think about: enhancement apps. These are apps that fade into the background when used, making the user simply feel as if their own capabilities have increased.
Hugh Herr’s bionic leg hardware/software is one example. The ‘app’, such as it is, becomes a literal part of the user, expanding their capabilities. This is a variant on live-with, but one where the app is perceived as part of the user.
Research has shown that people quickly adjust their perceptions of their own capabilities when given something that alters them. Enhancement apps do this; even something as simple as a work glove, which allows you to pick up sharp things and apply more torque than you could with bare hands, is in this category.
In the software space, things like GPS-based navigation apps can fall into this category. The modern driver doesn’t worry very much about directions or maps ahead of time; in fact, we internalize our magical ability to navigate so quickly, many of us become lost and disoriented (literally) when driving into a place with poor signal, even if all the other, low-tech solutions for navigation (street signs and route markers; the sun and stars) still exist.
Designers of enhancement apps need to think carefully about how users will react to suddenly not having the capability, and whether if signal is lost, it’s necessary to interrupt before the user really needs the service.
Designing Using Meta-Goals
I challenge you to think about this framework the next time you set out to design. If you can figure out how your application fits within the user’s life, you can better figure out how to make it feel seamless, properly engaging, and well-situated.