I Fight for the User

Yes, that Is a Tron Quote

Even though it's just a bit silly quoting Tron to describe how I feel about my job, the more I think about the metaphor, the more right it feels. This means that I'm responsible for both designing a program that does what the user expects, and protects them from all of the sharp edges that come from interacting with machines that think in pure math. I've come up with my own mental model for what the important bits are:

1. Follow Platform Owner and Industry Best Practices

It's almost a cop out to put it on the list, but I do sit down and read the Apple HIG for major iOS revisions. Other platforms have similar documents and if I get serious about projects on a platform I'll sit down and read the relevant documents. This isn't the perfect guide for how to do everything, but it's a solid foundation to build on and it helps educate you on what users should be expecting, which is part of what makes your work easier for them to use.

2. Be Internally Consistent

At face value, this sounds easy.

It isn't.

Making an app consistent is a mix of having a well thought out big picture flow and having all of the details right. It means triple checking pretty much every user facing aspect of the app to make sure that new features mesh well with everything you've already built. The worst part is, it's something people largely only notice when you get it wrong, if it's right it's invisible.

3. Remove as Much Friction and Complexity as Possible

I measure the friction in most tasks based on the number of clicks or taps it takes to accomplish them, and the number of pages the user has to pass through to complete a certain task.

Complexity is murkier to measure, it's a mix of how many commands are available at any time, how intricate the flow of the application is, if there are invisible options like gestures or keyboard shortcuts to remember, and so forth.

Interestingly, when designing you often trade complexity for friction or vice versa. Adding complexity can often remove friction because the more things you can do from any point the fewer steps it takes to accomplish a task. On the other hand, reducing the number of options on screen can require more taps or more screens of information to process. Finding the right balance depends heavily on who the users are, how often they'll be using the app, and how many layers of requirements are there.

4. Fail Fast, Fail Gracefully

Even assuming that all of your code is spotless, there will be problems beyond your control. For all the dumb things that you can plan to go wrong, write good error handling code. Separate different but similar error handling cases where you can, for instance present different dialog boxes based on the website not responding and returning an unexpected response.

Also, think about if an action is destructive or non-destructive. For any destructive options plan for every way things can go wrong and try to make sure that when you recover from whatever went wrong it's in the most recoverable state possible.

5. Try Not to Overestimate or Underestimate Your Users

You have to find a the fine line between feeling like you've childproofed the app and having a learning curve like a brick wall. This is very dependent on how complex the app is and what the expected skill level is of the users when they start using your app. If you're lucky enough to ship multiple versions it even becomes a large problem balancing UI and UX refinements against the expectations of your existing users.