Principles exist at a higher level than any pattern. They can be considered patterns for the patterns, if you will. Each pattern, and each detail of interactive or presentational design, should adhere to each of these principles at all times.
Each section and chapter in the book will begin with a discussion of the core principles for their sections, as well as other helpful guidelines that apply to those patterns.
I have, in a few workshops, articles, and other working sessions started talking about how I have developed a few principles. And I think it's true. I don't use most of those I included in the original book day to day, but I do follow these few basic principles and express them to co-workers and clients. As I conceive of projects, sketch, and especially move from information gathering exercises to task mapping and interface sketching, I actually use these:
(Also see these. Maybe start with them??? http://www.fightforux.com/)
Divorce data from opinion
- “The first principle is that you must not fool yourself – and you are the easiest person to fool.” - Richard Feynman
- The biggest problem with UX is people confusing design with art, and knowing art is opinion, so thinking we are doing it for ourselves, not them or the organization.
- You can have opinions, and I do, but I make them clearly different from what I am deciding on based on research, data, best practices, patterns, etc. I try to bring others from project teams into these opinion-based decisions (lacking research to solidify them), to make the other side clearly different and involve them in the design process.
Think harder about data
- Don't assume everyone's data is yours. Get your own.
- Don't boil it down too fast. Be open to opportunities and strange correlations.
- Check. Double check. Do not believe anything that is "90% of users." In my experience, someone screwed up something and you are missing key users or a key market.
- Think ecosystems and total costs. Does getting the Buy Now feature to work so well for new users mean that the existing users leave? A small part of your user base probably does most of your activity, buying, viewing, etc. Many stat summaries will hide this, and you can drive yourself into failure.
Play to your strengths
- Build for devices and ways of working people actually use, preferably with stats for your existing users. Back any decisions on platforms and features with math.
- Don't be swayed by personal opinion or biases.
Let computers do computery things, so people can do human things
- Your biggest resource constraint, and hardest thing to change: your users. By far.
- Never ask for data that any computer you can get to, somewhere, already knows.
- Never require input in computer formats when it's easy to parse it from arbitrary or human formats.
- Don't make people think about what the computer is saying. Make it display in human-centric ways.
- Corollary: Avoid error conditions caused by bad users input. Constrain, parse or just live with it but do not gripe at users for not being computers.
Never build that which you can borrow, or link to
- Intents are your friend
- Usually, no email forms (load the email client), no typing addresses (get location), etc.
- If you built a map to give directions inside your app, you are doing it wrong.
Design systems to be resilient
- Corollary: Components, connections, data will fail you. Plan on it, and avoid showing errors to users.
- Corollary: Users are not an error. Accept what they do with grace and charm.
Respect user-entered data. Do whatever you can to not discard it
- Input is hard. Users slip. You have a new phone, or are borrowing someone else’s, and someone jogs your arm: suddenly minutes of typing is gone.
- Do whatever it takes to preserve user data—from saving as the user types so that auto-complete can bring lost input back, to not clearing forms on error, to planning for a loss of connection.
- Consider contexts and plan for crises and real-world behaviors, not bench tops and labs.
Create a hierarchy of tasks and stick to it
- At least per view, preferably per application
- Primary: 1-2, secondary: 2-3, tertiary" no more than 5. If you go deeper than this... I have no answer for you. Try not to.
Design from the center outward
- Make the interface reflect the hierarchy. Primary in the middle, secondary along the edges, tertiary in the Menu.
- E.g. Read a list of messages; compose, share, favorite along the edge; search, add, message, account, settings in the Menu.
Next: Heuristics for Evaluating Mobile Designs
Discuss & Add
Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.
Original 2011 Principles
These are minor modifications and a merging of several sets of mobile-centric principles dating to at least the turn of the century. They are true in their own way, but over time I have decided they are a bit more like key lessons or understandings about mobile users than principles of mobile UX design themselves.
Each of these principles could be discussed in great detail, and in fact we could have organized the book differently so that each of them was a chapter, with patterns associated to it. In the interest of clarity, the discussion of each of these is limited. If you are interested in further details on the rationale, these are generally discussed in greater detail within the patterns they apply to, as well as the chapter introductions.
Respect User-Entered data
Input is hard. Users slip. You have a new phone, or are borrowing someone else’s, and someone jogs your arm: suddenly minutes of typing is gone. Do whatever it takes to preserve user data—from saving as the user types so that auto-complete can bring lost input back, to not clearing forms on error, to planning for a loss of connection. Consider con- texts and plan for crises and real-world behaviors, not bench tops and labs.
Realize That Mobiles Are Personal
Although security is important, there is no longer the need to assume that maybe the website is being viewed on a library computer. Mobiles can be presumed to be “one device for one person,” and no one wants to have to regularly tell his device his name, location, or favorite music. Only implement passwords and clear personal information when required by law or regulation, and take other types of reasonable and transparent precautions to prevent misuse of information.
Ensure That Lives Take Precedence
Mobiles are contextual, meaning they are used alongside people’s actual lives. Desktops (and some other devices) can suck people in, so you can go ahead and issue alerts that blink in the corner of the screen and they will be noticed. Mobiles are glanced at, used in gaps between conversation and driving and watching TV. They are even used to enhance these other experiences. So make sure they don’t interrupt unless they have to. And if they have to, make sure they interrupt in a way in which the interruption will be noticed. A blinking LED, for example, is easily missed when a device is glanced at for a fraction of a second.
Realize That Mobiles Must Work in All Contexts
Make the device behave appropriately, or allow users to make the device behave appro- priately, to make it work where they are. Most devices are too bright at night, making it hard to read that last email before bedtime, or to tell what time it is when the alarm goes off first thing in the morning. If the phone doesn’t have a good way to change brightness, your app can override it or your website can just have a dark/light switch. Think about the context in which the device will be used.
Use Your Sensors and Use Your Smarts
Whenever possible, perform actions for the user based on sensors and user data. Why should you have to silence your phone for a meeting, when the phone knows where you physically are and knows from your calendar that you have a meeting in that room right now? Mobiles can be better than computers, because of their personal nature and their sensors. Use them.
Realize That User Tasks Usually Take Precedence
If the user initiates a task, and especially if the user is in the middle of a task, do not inter- rupt the user so that the task is ruined. When the user is typing an SMS, feel free to beep, but do not change the focus so that the user is suddenly typing in another field. And never cancel the operation to take the user to another page, losing her information.
Ensure Consistency
Whatever the rest of the application does, do that. And the application standards should follow the edict: "whatever the OS does, do that." Even if the OS does something dumb, it’s probably what the user expects, so changing the paradigm generally results in more problems than solutions.
Respect Information
Although presentation and visualization can be used to clarify information, or view it in different ways, do not modify the fundamental truth for saving space, or because you do not understand the value of it. More information than you might expect rises to life/ health/safety levels with the ubiquity of mobiles. Weather, for example, must be presented perfectly accurately. Know the difference between precision and accuracy, and under- stand implications of meter types, relative values, off-scale errors, and more. Naturally, these will change over time. Just in the past five years we have changed or expanded these several times. Be aware of the reasons these principles exist, and keep abreast of the industry so that you are aware of changes.
Although we feel these principles are universal today, you are very free to disagree. Many others do, and they have their own principles, or variations on the understanding of what these mean. Just be sure you develop a set of design principles or objectives for your work or your project, and then stick to them.
How Mobile is Different from Desktop
In retrospect, maybe the first few sentences of the book were not the right way to go. I assumed anyone bothering to pick it up already knew why they needed it and had a handle on the basic info. But I regularly get questions that indicate there are misunderstandings.
Mobile is Different
Don't focus on screen size.
- Use is different: I call even laptops "desktops" because they are used in ad hoc workspaces. Mobile is
- Devices are different: Size ends up being the least important. Entry is difficult and different, and sensors plus portability mean it has more information available than a "full sized" computer.
In many ways, mobile is not limited, but more capable than desktops.
Mobile is Huge
Just a few numbers that are shocking in February 2012. Most pulled from Tomi's quarterly review, so full credit:
- Today, if a telephone rings anywhere on the planet the odds are 5 to 1, that the phone ringing is a mobile phone.
- One fifth of all who have a mobile phone today, actually use 2 phones daily. Not just 2 accounts, 2 actual phones.
85% of mobiles used for SMS, only 83% use their mobile for voice calling. No longer a mobile phone.
- If you've heard that SMS is losing to Facebook and other IP services, it's not. 2011: SMS users grew 16%, traffic 18%, revenue 5%.
- MMS, where you send photos and videos over an SMS-like service, now has more users than the total of people who access the internet by any method.
- 19% of the Japanese use mobile payments, daily.
- 1.9 billion subscribers to news alerts (mostly SMS ones): 4x the circulation of all daily newspapers worldwide. That's more than the total number of television sets in use globally.
Other or different principles
I am constantly repurposing or changing these for specific clients. Occasionally I'll add one. I am going to start adding those as they might become real, universal principles in the future.
Users are the same person, everywhere
Single signon, single view, single data source. Regardless of touchpoint.
Quality Software
Not super related, it might seem, but I quite like this definition I got from @richcampbell, but which I think he says is not from him.
- Does what it's supposed to do.
- Is easy to use
- Is responsive.
- Is observable: you can tell what it's doing, and it does what you expect it to do.
Definitions of UX
I think that this does a rather nice job, in a comparison between UX and Service Design: http://dl.acm.org/citation.cfm?id=1836232
Experience design has been defined as the practice of designing products, services, events, and environments with a focus on the quality of the user experience and culturally relevant solutions, rather than a focus on increasing and improving functionality of the design
Pondering UX Principles
I am thinking we need to boil them down further. These are not even me really working on them, or praying for inspiration. Just noticing I tend to say this sort of stuff as the core proof. That might make them the real principles. These are in order. Once you solve 1, go to 2. Ideally.
- Don't frustrate or anger your customers.
- At every level. Your product, interface, interaction, wording, or business practices must all work for not just you, but the end users.
- Preferred: Stop it. Really. Even if it changes the way you do business.
- At least: Explain why. Maybe you really, really can't stop it due to government regulation or something. Then explain, in English, early as possible, what will happen.
- You can always do (more or less) the preferred one. Everything can be improved to at least simplify, obscure or obfuscate stupid behaviors. If, for example, you have a long-standing regional distribution system making online ordering "impossible," just lie to the online customers, and set up an order system that takes them in one portal and arranges to have them shipped from the regional distributors based on the mailing address. For example.
- Don't lie to your users.
- You can obscure things, sometimes, if the needs of #1 can only be met with this. But never lie.
- You lie more than you think. Be specific, accurate and truthful. Know how to represent data properly in graphs before you use one.
- Don't obscure or obfuscate the way your business process, data store, etc. If they are complex or evil, fix the underlying structure first.
- Lies of omission count. Got a 6 step process but don't say that? Your "Submit" buttons are a lie. Charging for a digital service, but don't tell anyone till the last step? That's a lie.
- Don't waste your users' time.
This is not just speed of response (though see https://developers.google.com/speed/docs/insights/mobile Google's target of 1 second responses) though that is good to remember also...
- ...but about not /wasting/ their time. Doing tasks they already did for example. I am reminded of how Chrome likes to re-render every tab that's more than a minute old now. Slow, I have to scroll to where I was (usually) and maybe I lost any entry. Bad!
- Sensors, profiles and connectivity means we know a lot about the user, and can predict pretty well what they want to do. Don't make them tell you, but offer the most likely options immediately. As an example, if the first thing the user sees is just a list or grid of options, you are doing it wrong. You can offer information and functionality right there, first thing.
- Provide 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.
- This often just means using the OS standards. Users should never guess how to use the interface.
- De facto standards are different from official standards. What are your customers actually used to on their devices?
- Machine-era standards are just as important to consider. How do people solve their problem now? There is very often something to be learned from how printed or hardware versions of this were made for decades or centuries before.
- Sometimes, machine-era standards are required. Methods of storing and displaying information are often rooted in very old technologies. Look them up.