Principles for Mobile Design

Creating Design Principles

I considered my continued failure to accept design principles to be a minor crisis of faith, so I muddled through with design patterns, and my ongoing user research has continually brought me closer to the way users actually work. But, after a while, I noticed that I repeated similar phrases over and over as explanations for designs, for patterns, or when arguing why we shouldn’t pursue some design idea.

When I put the design guidelines or principles for a project on the wall—or on the first page of a design document—I realized that many of them repeated from one project to another. I started to recognize that these weren’t project principles, but design principles.

A year or two ago, I settled pretty well on the following eleven principles that I’d derived organically from my actual design practice:

1. Divorce data from opinion.
2. Don’t assume all data is true for you.
3. There’s no such thing as a normal user.
4. Play to your strengths.
5. Let computers do computery things, so people can do human things.
6. Never build what you can borrow or link to.
7. Design systems to be resilient.
8. Respect user-entered data.
9. Create a hierarchy of tasks and stick to it.
10. Get the basics right first.
11. Delight who you can, but don’t anger anyone.

1. Divorce data from opinion.

The biggest problem with User Experience occurs when the rest of a project team confuses design with art and, knowing art is opinion, thinks we are doing our design work based on our opinions or instincts. That we’re basically doing it for ourselves, not for them, the product, the users, or the organization.

But User Experience is a scientific discipline. First and foremost, we offer designs that are based on evidence. Of course, you may have opinions and I do, too, but when I have an opinion, I make sure it is clearly differentiated from what I am deciding based on research, data, best practices, patterns, and heuristics.

As Richard Feynman said, “The first principle is that you must not fool yourself—and you are the easiest person to fool.” To both mitigate my opinions and to involve the whole team, I try to bring in others to help make decisions based on the evidence we can present, and I invite them to share their opinions, so we can discuss where the line between data and opinion lies.

2. Don’t assume all data is true for you.

Almost every UX designer I know would agree that our work is evidence based, but far too many of us fall for guidelines and pop-culture data points without understanding them.

Instead, remember your scientific principles of proof. Read the original papers, and read additional related research to find out what else is true. Do your own research on your product and users. Check. Double-check. Do not believe anything that gets sold as always or never because all users share some behavior.

Think about your product’s ecosystem and the total cost of a decision. Much data that insists something is true is very narrowly focused. For example, we hear that hamburger menus don’t work, but it turns out that’s true only for specific design cases on sales and marketing products.

Would getting the Buy Now feature to work well for new users mean that existing users would leave? A small portion of your users are probably responsible for most of the activity, buying, or viewing. Many summaries of statistics hide this, so you may drive yourself into failure.

Don’t boil things down too fast. Be open to opportunities and strange correlations.

3. There’s no such thing as a normal user.

People love infographics, easy to read maps, charts, and graphs, right? Well, some do. But people’s understanding of graphics and maps is normally distributed—that is, is distributed on a bell curve. Most people can derive value from graphic or spatial representations, but some understand only those; others understand only text charts, tables, and lists. Since I understand that, I always provide both. As just one example, note how Google Maps provides both maps and lists of nearby restaurants.

The same distribution is true for almost any specific type of information or interaction. Any particular design element probably won’t work optimally for some subset of your users, so build primarily for the best possible case for most users and provide alternatives for everyone else.

As evidence-based people, this is one of our biggest issues because there are always outliers. This is the reason I say almost weekly that “the plural of anecdote is not data,” and this is why we never make decisions based on just one user, one client, or one piece of feedback. Instead, we seek to understand the needs, behaviors, and preferences of the entire user base.

4. Play to your strengths.

Your organization, your product, and your platform do things differently from all others. Try not to see anything they do as a liability, but instead, seek out their strengths and use those. This is a struggle especially for mobile, even now.

I hear far, far too much about how smartphones are crippled by their small screens, slow processors, and bad networks. Aside from this not being entirely true, it also misses the point of mobile devices. They are portable, connected, sensorized tools that exceed the power of personal computers in many ways. Use the camera, location systems, the multitude of apps and services included, phone and SMS capabilities, and mobility to solve your issues and offer products in unique ways. And user friendly ways. Don’t get limited to solving for the technology alone. Build for the ways people actually work and, preferably, for the way your actual users work with your app or Web site.

Especially when it comes to strategy and other product-level decisions, don’t be swayed by personal opinions or biases. Don’t blindly chase the competition. You don’t know their strategy. They may appeal to a slightly different market or be able to execute certain features or services better.

5. Let computers do computery things, so people can do human things.

For any system you design, your biggest constraint and the most difficult thing by far to change is your users. Embrace this, and don’t try to change them. Training or FAQs sometimes attempt to change users’ behaviors to get them to act the way the system wants them to. I deeply believe this is something to be avoided. Successful, disruptive industries return to what users want instead of changing users to make them want a new product.

This strategy and mindset leads to some simple-to-remember design guidelines:

• Never ask people to type or select data that any computer already knows.
• Never require input in computer formats when it’s easy to parse from arbitrary, or human, formats. For example, phone numbers do not need hyphens.
• Don’t make people think about what the computer is saying. Display data in human-centric ways. Engineers must not write error messages because only they will understand them.
• Avoid error conditions that are caused by erroneous user input. Constrain, parse, or just live with the data. Do not gripe at users for their not being computers.

6. Never build what you can borrow or link to.

On a Web site or application that is designed for a personal computer, the right way to build a contact or complaint form is to create it yourself. You choose the fields, create a user interface (UI), create a link to send it to your own server, and so on.

However, for a mobile app, there is no reason to bother with that. You can easily and reliably link to an email client that the user already knows how to use and just leverage that capability. The same is true for many phone features.

A great way to sell this principle to your organization is the cost savings—no need to build what already exists. But it is also critical to delivering a good experience to users. A favorite story in this regard is about mapping. A client had, before I joined their project, built a sort of store locator into their app. It was heavily used, but users griped about it a lot.

The client’s roadmap included adding turn-by-turn directions and other such features. I sifted through users’ complaints and discovered that no one wants that. Instead, they want to view the map in their favorite, native mapping app. Which one? We don’t care. It’s whatever the users use. So, we ripped out all the mapping and linked to the native mapping app. Not much to build, no maintenance, no complaints, and increased visitors.

7. Design systems to be resilient.

Components, connections, and data will fail you. Users will do things you do not expect. There isn’t really a happy path, so stop designing that first and thinking everything else is a low-risk scenario or an error.

I bring this principle through to the user-interface layer. There is no fragmentation of viewport size or operating-system (OS) versions because I don’t create pixel-perfect Sketch or Photoshop pages, but specifications for systems. Lots of my drawings are essentially placeholders for which I specify, “Do whatever the OS default is here.”

Assume the unknown, and design your experiences to accept weird behaviors, bad data, and the unexpected with grace and charm.

8. Respect user-entered data.

On mobile devices, data input may be especially difficult. Even for personal data, the user might have to ask someone else for information or look up something. Then, if the user slips or presses the wrong button or the system loops back, the user has to type it all again.

Do whatever it takes to preserve user-entered data—from saving data as the user types and ensuring that auto-complete can bring back lost input; to not clearing forms when errors occur; to planning for a loss of connectivity.

Never, ever destroy user-entered data. I would go so far as to not specify those convenient delete-field X icons. If the user meant to tap Search and clicked Delete, there’s no way back from that. Backspacing through a whole field may be tedious for the occasional user, but it is safer for everyone else.

When losing user-entered data is unavoidable, encourage recovery. For example, when you have auto-suggest fields, prioritize the user’s typing, with recent typing first, so the user can efficiently recover the data by typing just a few characters.

9. Create a hierarchy of tasks and stick to it.

When I’m not doing information architecture and user interface / interaction design, I spend a lot of time doing information design. That’s somewhat of a pre-Internet term in common use by library-science and traditional information-visualization types. Since I originally came from the graphic-design world, information design makes sense to me, and those best practices informed a lot of my thinking early on.

Now, I apply the term information design to sort of mean information architecture, but on a page. Laying out a template using Post-its or by drawing big boxes before putting in the user-interface details, that’s what information design is to me—and, apparently, to enough other designers that I can usually use this term in workshops and talks without anyone being overly confused.

When making sense of information on a mobile app or Web site, I follow one key guideline that I have discovered from my touch research: people look at and touch the center. Over time, I’ve evolved that to Point #7 in my column on touch guidelines: One, Two, Three for Better Mobile Design.

Present a hierarchy of information or functionality—preferably not more than three levels deep. Put the key items at the center of the page, secondary items along the top and bottom edges, and tertiary items behind menus.

Then, stick to the core of your design. If someone adds a feature, you’ll probably need to go back to the information-design exercise to make sure it fits. Maybe, you’ll need to blow up the whole design and start over. Squeezing something in rarely works. Design deliberately.

10. Get the basics right first.

Want to add virtual reality (VR), drag and drop, and artificial intelligence (AI)? Great. Can people read the content on all devices? Can they scroll with mouse, pen, and finger? Can they notice and click links accurately? Can they tell what icons mean, or do you also need text labels. Elicit wonder when you can, but never make the user wonder what you mean or are up to.

Meet customer expectations. When exceeding them, do it in a way that is not confusing or provides an obvious alternative. This often just means using the OS standards. Users should never have to guess how to use a user interface, but should be delighted by how you met their needs instead.

De facto standards are different from official standards. What are your customers actually accustomed to on their devices? Machine-era standards are just as important to consider. How do people solve their problems now? There is very often something to learn from the way print or hardware versions of legacy information products were made. They survived for decades or even centuries, so maybe there is a good reason for their design. Do you know why?

Understand your systems, your users, and how systems work. Great, simple solutions are the cool stuff.

11. Delight who you can, but don’t anger anyone.

Never frustrate or anger any of your customers. It is still good practice to design for specific groups of people. Create personas that are based on research and learn how certain people work with your product. But for each decision you make to target someone, think about the other side. Don’t anger, frustrate, or cause confusion to anyone else.

This issue exists at every level. Your product, user interface, interactions, the wording of text, and business practices must work not just for one persona, but for all users. Talk to some sales and marketing people at your company about the cost of acquisition, then use that data when someone says, “They’ll get over it” or “We can provide training.”

Of course, sometimes, you cannot change things. I have a lot of clients for whom business-practice changes are decided far above me in the hierarchy, or there may be regulatory constraints. At least, explain why certain things happen. Explain, in English, as early as possible, what will happen—or, if necessary, fake it. You can improve anything by at least simplifying or obscuring or obfuscating stupid behaviors. Bad back end? Set up middleware to cache data. Regional distribution agreements? Create a central eStore anyway and send orders to the distributors to fill.

Solve customer problems. Solve problems for all customers. As much as you can, solve all problems, for all customers.

What Are Your Principles?

I like these eleven design principles, and I think they provide a solid foundation. I use them daily and share them with my team and clients to justify my actions and help guide decisions when we’ve got competing ideas or there are technical objections to a concept. But these principles are mine.

You may disagree with my set, approach design from a different point of view, or have different or new takes based on your experience or because you work on different types of projects. You should have your own principles of mobile design, but they must be principles you believe in, can really internalize, and use every day to guide and improve your work. 

References

Association for Computing Machinery. Code 2018 Project. Retrieved July 18, 2017.

Babich, Nick. “Golden Rules of User Interface Design: 10 Usability Heuristics for User Interface Design.” UX Planet. February 10, 2016. Retrieved July 18, 2017.

Fight for UX. The First Five Principles of UX. Retrieved July 18, 2017.

Hoober, Steven. “An Introduction to Designing for Imperfection.” UX Magazine. July 29, 2013. Retrieved July 18, 2017.

Hoober, Steven, and Eric Berkman. Designing Mobile Interfaces. Sebastopol, California: O’Reilly, 2012.

Hoober, Steven. “Error Messages Are an Anti-Pattern.” UXmatters. November 9, 2015. Retrieved July 18, 2017.

Nielsen, Jakob. “10 Usability Heuristics for User Interface Design.” Nielsen Norman Group. January 1, 1995. Retrieved July 18, 2017.