Principles of Mobile Design
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.
This resource is an evolution of an introductory section for the book Designing Mobile Interfaces. Each section and chapter in the book began with a discussion of the core principles for their sections, as well as other helpful guidelines that apply to those patterns.
As I conceive of projects, sketch, and especially move from information gathering exercises to task mapping and interface sketching, I actually use these every day. Yours may well be different:
Divorce data from opinion
“The first principle is that you must not fool yourself – and you are the easiest person to fool.” - Richard Feynman
Also good words to live by as a professional “If you are working hard to convince yourself that something is right, then it is probably wrong.“
In both cases the upshot is that you need to rely on data, and question all assumptions, especially your own.
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.