Designing Social for Mobile

Back in 2008, when I was head of design at Myriad, Europe's largest mobile software company, I wrote an essay for the first edition of Designing Social Interfaces, written by design superheroes of Yahoo! Pattern Library fame, Erin Malone and Christian Crumlish. I rewrote my essay earlier this year for the second edition, which was recently released.

When they reviewed the book's completed manuscript, though, the authors realized something they hadn't expected: the design landscape has changed so much over the past seven years that mobile is now everywhere. Infused in every chapter and every design problem. So my essay became superfluous. I include it here for your education and enjoyment - and I encourage you to buy their book, nonetheless, because it's awesome.

 

*****

Designing Social for Mobile

for edition two of Designing Social Interfaces, February 2015

I’ve been designing for mobile since before the first iPhone was released. People used to ask me all the time how I could stand it. How could you do anything on those tiny screens? A few years and a billion or so smart mobile devices later, no one’s asking that anymore. The app store model has changed the rules of engagement, the rules of design, and the competitive landscape, and almost overnight, we are all designing “mobile first.”

Mobile design to me (as compared to desktop design) is like writing sonnets—or better, haiku—as compared to writing free poetry. The structured nature of mobile design makes it more important than ever to understand our users’ passions, motivations, context, and decision-making processes.

With that in mind, I share with you my “Dos and Don’ts” for mobile design, some of which are the same as they were all those years ago, and some which have emerged as this space has evolved.

 

Do:

·      Use the 5-minute rule. Mobile users are, well, mobile; they’re going to use your application while standing in line at the sandwich counter/waiting at the bus stop/sitting on the couch waiting for the commercial to be over. Make sure that whatever your mobile app or site’s raison d’être is, it breaks down easily into short bursts of activity. Even better if those bursts of activity are super-entertaining or super-useful.

·      Focused research and task analysis. Figure out who your user is, what she cares about most, and what she’s really going to use your app for in those five minutes—and make sure your design does those top one or two things well.

·      Expect – and design for – interruption. Not only in the user’s thought process (what was I doing before I lost reception/had to pay for my takeout/arrived at work?), but also between apps AND between devices. These are hard yet important design problems to solve. Case in point: Five months (and at least four update patches) after iOS8 was released with its new multitasking features, I was still cursing every time I received a text that blew away a response I had been writing to another.

·      Dazzle (or at least intrigue) them quickly, or lose them just as quickly. Sure, your engineering and design geek buddies might have fun tinkering with the guts of the settings on their phones, but in the app store world, your users have lots of choice and little patience for delayed gratification.  Make sure your app demonstrates its value immediately.

·      Get familiar with the mobile ecosystem. Take a field trip to a local shop or three and play with the display models. Especially the Android ones, since there are so many. Develop a habit of watching people texting and playing mobile games on the train and reading their email in the elevator. Immersion can quickly make you a local in Mobile-landia, rather than a tourist.

·      Make informed, user-centered decisions about whether to start with a responsive mobile web site or a native app. The right choice is going to depend on your target user base, your business’ goals and engineering capacity. In short: Do you need to go broad, release a small set of features/content to as large an audience as possible, as quickly as possible? Then go mobile web. Do you need to go deep, impress the heck out of iPhone users right out of the gate, with the best possible user experience and use of the latest iOS APIs? Best be going native. Design leadership in the twenty-teens and beyond requires that you be able to facilitate this conversation, and make sure your team makes the most effective choice for the design problem you are solving.

·      Think about the business. How will your app make money? How will your social ecosystem sustain itself? One thing that’s changed is that more and more folks are willing to put up with ads, particularly relevant ones, to get something for free. What will inspire them to pay for the premium version (other than an assumption of annoyance that might no longer be valid)? It pays to understand your particular persona’s motivations.

 

Don’t:

·      …pare down the feature set too much. Sure, if you’re converting a successful desktop app or site to mobile, you MUST prioritize the flow hierarchy effectively. However, too many mobile designers – even of successful commercial apps – remove key features on a misguided search for “simplicity.” I mean, who thought it was a good idea to release the first version of mobile Gmail without search? Who on earth decided not to let me delete a Dropbox folder in a hurry while waiting for my latte, or reorder my Netflix queue during my bus ride home? There are plenty of interaction design patterns, such as the ones you’ll learn about in this book, that you can use to indicate hierarchy or relative importance. Use them.

·      …think that shrinking a desktop app down to mobile size is going to work—especially on a touchscreen. Many mobile designs that fail do so because the designer (or engineer) who built them assumed that a mobile device was just a very small computer. This is true both from a UI control standpoint (no hover, making clickable elements large enough for clumsy fingers) and from a “how people’s brains work” standpoint (context, as above and as ever, remains king).

·      …assume. You probably know what my dad says happens when you assume. What I mean in a mobile design context: my students were doing a project recently, geared towards increasing public knowledge of and access to below-market-rate real estate in San Francisco. They had a hypothesis that mobile access to this service might not be very important, because people who would benefit from the service might not have mobile device access. Their research proved them dead wrong – 80% of their target audience showed up to an informational workshop, smartphones in hand. Good thing they were such diligent researchers and designed from real user observation, rather than designing from stereotypes or “gut feelings.”

·      …think about software. Not so much in the Lakoff “don’t think of an elephant” sense, but more in the Tufte minimizing the “software artifacts” sense. Mobile design is incredibly intimate. That phone lives in your palm, in your pocket, under your pillow. It’s with you all the time. It flows in and out of your hand like an extra limb or an extra brain, available to fill in the gaps in your knowledge, ability, attention span, or location. When you’re checking Facebook, you’re not thinking about what buttons and sliders and widgets are on the screen, you’re having feelings about the people whose posts you’re reading. When you’re buying a plane ticket online, you’re not thinking about those buttons and sliders either -- you’re having feelings about where you’re going, whom you’re visiting, how much you can afford to spend.

Unless you’re an interaction designer, of course, in which case you’re thinking about the software all the time.

The point is, in mobile more than anywhere else we’ve designed for: if you’re having a conversation about features and what UI controls are on the screen, rather than the experience you’re delivering, you’re having the wrong conversation, and your app will suffer.

 

 

In 2009, when I wrote the original essay for the first edition of this book, mobile phones were highly disconnected devices. Heavy dividers separated social interaction in different applications – email, texts, or calls to contacts lived in their own silos, and Facebook, Twitter, and other networks lived in their own separate universes.

At that time, it seemed revolutionary to point out that “contextually speaking, mobile phones are by definition social networking devices,” and to encourage designers to “break out of the classic phone/phone book mental model and transform that experience to include 21st-century-style social networking.” It’s exciting to see that as a design community, we have taken up the challenge and initiated more transformation and disruption that I could have imagined.

The depth of connection enabled by the mobile user experience has increased along with this transformation, and brought with it not only new opportunities, but also privacy concerns we designers need to consider. I like to make an analogy to politics, which is what I studied in college. In government, there’s a tradeoff between Protection and Freedom. Individuals locate and re-locate themselves along that spectrum depending on their context (race or class, what’s happened in their local communities, whether it’s an election year, etc.) With respect to mobile design, the tradeoff is between Convenience (or Pleasure) and Privacy – and people will also locate and re-locate themselves similarly. The same hard-working tired mama, for instance, might bristle at letting an app her employer accesses save her credit card details, but not blink an eye at leaving the same data on the servers of an app company that allows her to press a single button and have takeout on her doorstep when she arrives home with the kids. The point? It’s become complex. Find out where your user stands, and why.

 

A few final questions to consider in your mobile experience design process:

 

·      What does the intimacy my user has with his/her phone mean for how s/he experiences mobile social networks? (Think about the difference between the majority of my Facebook or Twitter friends, as opposed to the ones whose updates I set to vibrate in my pocket.)

·      What experience am I offering my users to make it worth it for them to trust me/my app with their data? What is and isn’t ethical to do with the data, for the purpose of improving the personalization of their experience? How about for the purpose of improving the business’ bottom line?

·      What kind of experience can I offer my user that is special because I have an aggregate understanding of all the people participating in the ecosystem, what their relationships are to one another and to the content of this particular app?

 

If my own experience is indicative, thoughtfulness on these topics will make your design process more exciting, and your applications more compelling.