Are we done with the Mobile First meme, yet? Can we be? Please?
Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.
The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.
Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.
Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.
Those two things are: Flow and Context.
What is Flow?
Flow is the actual user experience, in many ways. If you like, you can think of flow as a really comprehensive set of user stories. When you think about user flow, you’re thinking about exactly how a user will perform the tasks allowed by your product.
To understand Flow, you need to answer questions like:
Where is a user coming from when starting to perform a task?
Where will a user end up after completing a task?
What happens if a user is interrupted?
Are tasks likely to be sequential, or will they be performed in random order at various times throughout the day?
Do the tasks involve producing content (emails, documents, designs, photos), consuming content (reading blogs, looking at pictures), or interacting in a lightweight way (liking, commenting)? If the answer is “all of the above,” which one do you want to emphasize at which points in the experience?
How will a user want to get to your product? Will she click a link in an email? Respond to a notification? Type in a URL? Put your app on her phone or tablet home screen? By the way, if you expect the latter, you’d better have a damn good reason why your user will want to do that.
Let me give you an example.
Imagine writing an email. Take a second and do this as a thought exercise. Walk yourself through the entire process of writing a message and sending it.
Did you imagine stopping halfway through to go look up a link that you wanted to include? What about starting the email from a web page or application rather than from your traditional email client? Were you imagining typing it on your phone? Your tablet? Your laptop? Did you start on one device and finish on another? Were you CCing somebody on it? BCCing somebody? Were you responding to somebody’s questions inline? Did you get distracted halfway through and go get your third cup of coffee and then forget to finish the email until the the next day? Just me? Yeah.
My point is that there is no single flow for writing an email. This also applies to buying a product or taking a note or snapping a picture or reading a blog post or pretty much any other remotely complex task. There are dozens of flows for each of them. If you are a designer or product manager, it is Your Job to think about all the different ways someone might use your product and either support those behaviors or prevent them.
A good example of anticipating and preventing unwanted behavior is the leakage prevention on Amazon’s checkout screens. Ever noticed that, when you’re checking out on Amazon, you no longer have a full header or footer? This prevents you from getting halfway through checkout, thinking you want to check on one more thing, wandering away from checkout, and then forgetting to complete the transaction. Once you’ve shown intent to purchase, they get you through the checkout flow with minimal distractions. They’re preventing unwanted behavior.
Amazon’s only header during checkout is designed to stop you from wandering off.
Also, have you noticed that, when you’re done checking out, that’s when Amazon shows you a bunch of other things you might like to add to the order? You’ve performed the task they’re interested in. Now they’re happy to re-engage you in the shopping process. These behaviors are purposely sequenced to maximize the number of items for which you actually complete a transaction.
What is Context?
If flow is the order in which users perform tasks, context is the space in which they are likely to perform them. If flow is the “how,” then context is the “where” and “when.”
To understand Context, you need to answer questions like:
Where will a user be when she uses this product? On a train? On her couch? In a car? On a factory floor?
What device will she be using? Will the device change at various points throughout the day or week? Is the device private (a phone), semi-private (a shared tablet), or public (a school lab or a terminal in a doctor’s exam room)?
Is she likely to be interrupted?
Is she likely to be moving?
Is she reliably connected to the internet? Are you sure about that? What if she isn’t?
Let’s look at another example.
I’d like you to think about the following task: you have a meeting coming up in a half hour, and you need to prepare. Seems pretty straightforward, right?
Now, did you imagine that you were in your car traveling to the meeting? Or were you at your desk at work? Did you already know the location of the meeting? Did you know your way around the city where the meeting takes place? Did you know the people you were meeting with? Were you responsible for bringing a bunch of things to the meeting? Were you giving a presentation at the meeting? Were you leading the meeting or attending? Was it on the phone?
These are just a few of the contexts you might need to consider when attending a meeting. In fact, if your product is going to support people performing any sort of complex behavior, you need to understand the context in which they might perform that behavior. And here’s the kicker: most behaviors are far more complex than you imagine.
Amazon also gives us a nice example of a context sensitive shopping experience. When I click search on the app on my Android phone, it immediately gives me the option to scan a barcode or snap a photo of a product. This is great for the times that I’m at a store and want to quickly check to see if I could buy something on Amazon and have it shipped directly to my house. Amazon is taking advantage of a unique aspect of the phone (the camera) to support a uniquely mobile experience (looking at something in a store and then searching for it online immediately).
Instead of thinking of the app as their normal shopping experience but shrunk down to fit on a smaller screen, they’ve understood the new behaviors created by context. Their app is even designed for easy context switching. For example, if I put something in my cart on my phone, I can obviously access it later on my computer. If I buy a book on my Kindle, it automatically downloads there, but if I buy a Kindle book from the website, it asks me where I’d like to read the book. The designers at Amazon understand that I’m not mobile first. I’m mobile sometimes. And I expect my behavior to be supported regardless of my context.
Why Is this important?
Too often when people design experiences, they start from the screen. They think “oh, people need to do x” and they start laying out a screen that will support that task.
The problem is that not enough designers think through what that “task” really entails. Tasks don’t live in a vacuum. People come to them from somewhere. They go somewhere afterward. They perform them in different environments with different levels of attention and varying amounts of time. An interaction on a screen represents a single moment in time. The user interaction encompasses that moment and everything that surrounds that moment.
Good interfaces take these differences into account. They support most of the likely behaviors and environments and prevent the truly undesirable ones. Good design doesn’t lose data or state just because a user has performed an action in a surprising way. Good designers need to think through all possible flows and take user context into consideration before even thinking about screen interactions.
And yes, good designers think about the interaction in a mobile context. They just don’t do it first.