Rule #3

We're temporal creatures. We slide through time like an arrow. And we're rather impatient, especially with tools we're using. What is fast enough? How do you define responsive? How do you measure discomfort?
There are a couple of numbers that I keep repeating to the teams:
1, If the SW does not react to your input within 100ms, you feel it's not responsive
2, If the SW does not react in 1 second, you feel it's broken
3, In 10 seconds you lose context.

Number 1, is simple and trivial. You press a button, you expect that button to visually change or a beep to be heard, etc. It's important because you have to know that whatever your intention was, is captured by the device. You have to make sure the total latency in capturing that event, processing, displaying an updated picture, making a sound heard - it all happens, all the time, in all the screens, in all the cases, within 100 ms. The key here is consistency. Because whenever you don't feed back in 100ms, the user will feel discomfort.

Number 2, it goes a bit deeper. Even if you made that button look 'pressed' in 100ms, you have to make sure that within 1 second the action is carried out. If it's a complex and time-taking action (such as downloading all the internets) the solution is to show a new screen with a progress bar. But unless it's something big, which the user understands as a big task, you have to finish the operation within 1 second.

Number 3, is the least trivial and applies especially to mobile devices. Whatever the user does, whatever the SW does, if the user is interrupted or delayed for more than 10 seconds, he'll not know what he was doing. Part of the reason for is that we're all stupid. But more likely, if something takes more than 10 seconds, you don't just stare at the screen waiting, but start doing something else, your attention gets diverted, etc. What it normally means, is that after 10 seconds you don't know what you started. In the case of a mobile device, it's also less immersive and you can be driving, on the go, talking to people, so even if the software is fully responsive, you can get diverted for 10+ seconds any time.
Okay, so your user gets diverted randomly and forgets what he wanted 10 seconds ago. How do you deal with that? Here are a couple of ideas:
- Make sure every screen is self-explanatory. The user should know what the screen is about and why it's displayed, etc. The easiest way of testing this is to take your software into any of its screens and just give it to someone, and ask him to continue from that point. If your screen layouts are sensible, every screen has some title explaining the task you're carrying out, etc, it will most likely pass this test.
- Make sure your UI workflow has no overlaps or loops in it. If you use the exact same screen in two different parts of your workflow, it's likely to cause problems here. If you have a full-screen virtual keyboard with a textbox above it, you have to have some indication (even if the user already started typing) about where you are in the workflow.
- Making too many screens look very similar is a nice way of reducing design and implementation cost. It can also be good for creating a cleaner, more consistent look and feel. However, if every screen in your product is different in color, layout, etc, it helps enourmously in orientation and learnability (is that even a word?)

So whenever you design an interface, think about these 3 numbers...