A nice post about minimizing complexity:
http://ff.im/-9mSap
Lots of good rules and guidelines.
2009. október 7., szerda
2009. október 6., kedd
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...
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...
2009. szeptember 26., szombat
Rule #2
One thing that most designer forgets when it comes to mobile interfaces is how the complexity level should be different from a PC or Web application.
First of all, the screen is smaller. This is easily ignored when designing on a 22" pc monitor. Especially when it comes to very high resolution screens. I had way too many customer telling me how we should fit more on their device since it has much bigger resolution. Right... A 4" screen is a 4" inch screen, whatever resolution it has.
What's also different is how you interact with the mobile device in question. A PC experience is immersive. Your full and undivided attention is on the screen. Your desktop becomes a second home. You spend hours in front if it, IN your PC. On a mobile device it's very different. You focus on it for seconds or minutes at max. It's a small part of your field of view, and many times you're doing something else at the same time. Like driving a car. So the experience is by nature not immersive. You're not living in the screen. It's becoming a tool in your life. An indicator or a control panel of something.
So rule #2 is: no more than 7 things on a screen.
Things are defined as a button, a status, an icon indicating something, a map...
It's actually based on studies that people can recognize 7 things at a glance. If you put more on a screen, the user will have to scan through that screen multiple times to find what he's looking for.
Also based on studies, phones that have less button on them create an impression in potential buyers as being easier to use. Nokia used this finding and created a couple o phones where they joined up the buttons of the numeric pad into pairs. To make the device look like it has less buttons. (Well, it sure made those phones look STUPID and different, but not easier to handle. So trading buttons for confusion is not a great idea)
I actually beleive that 7 is a good median, but tge ideal number depends on country. Just take a look at consumer electronics in different countries. I've seen a DVR in Taiwan with over 50 buttons on the face of it. In Europe, you have typically around 7 buttons. In the US it's 1 or 2.
So this rule is not as strong and strict as rule #1 but it's just as important. A 4" screen with 20 clickable items shown on a screen is not a good idea.
-- Posted from my iPhone
First of all, the screen is smaller. This is easily ignored when designing on a 22" pc monitor. Especially when it comes to very high resolution screens. I had way too many customer telling me how we should fit more on their device since it has much bigger resolution. Right... A 4" screen is a 4" inch screen, whatever resolution it has.
What's also different is how you interact with the mobile device in question. A PC experience is immersive. Your full and undivided attention is on the screen. Your desktop becomes a second home. You spend hours in front if it, IN your PC. On a mobile device it's very different. You focus on it for seconds or minutes at max. It's a small part of your field of view, and many times you're doing something else at the same time. Like driving a car. So the experience is by nature not immersive. You're not living in the screen. It's becoming a tool in your life. An indicator or a control panel of something.
So rule #2 is: no more than 7 things on a screen.
Things are defined as a button, a status, an icon indicating something, a map...
It's actually based on studies that people can recognize 7 things at a glance. If you put more on a screen, the user will have to scan through that screen multiple times to find what he's looking for.
Also based on studies, phones that have less button on them create an impression in potential buyers as being easier to use. Nokia used this finding and created a couple o phones where they joined up the buttons of the numeric pad into pairs. To make the device look like it has less buttons. (Well, it sure made those phones look STUPID and different, but not easier to handle. So trading buttons for confusion is not a great idea)
I actually beleive that 7 is a good median, but tge ideal number depends on country. Just take a look at consumer electronics in different countries. I've seen a DVR in Taiwan with over 50 buttons on the face of it. In Europe, you have typically around 7 buttons. In the US it's 1 or 2.
So this rule is not as strong and strict as rule #1 but it's just as important. A 4" screen with 20 clickable items shown on a screen is not a good idea.
-- Posted from my iPhone
2009. szeptember 25., péntek
Touchscreen: Usability Guidelines
An interesting read, found on google:
I think they missed a couple of key issues and metrics, but summed up many of them.
And fi you like it, you should also check out the rest of their stuff:
Rule #1
I started making up rules a few years ago, just to formalize some of the ideas. And to force people into taking them seriously. Including myself.
Rule #1: a button should look like a button
Okay, so compared to how simple this rule is, I had to start calling it #1 for people to take it really seriously.
But just think about it. If you're designing a new interface for a touchscreen product, your interface is a lot less explorable than a PC. There's no tooltip to begin with. No cursor that could change to a hand or carret. The user explores your interface by looking at a screen. A small one. From a distance. He can either recognize buttons and tell them apart from non-buttons or he'll be frustrated like hell.
What IS a button? Anything that you can click on a screen that performs an action is a button, more or less. So anything that ACTs like a button should LOOK like a button.
It might be the simplest of the rules, but it's very hard to fulfill consistently.
In so many products you end up with exceptions, and they ALWAYS bite you in the ass. Even if you call them 'paradigm shifts'.
Rule #1: a button should look like a button
Okay, so compared to how simple this rule is, I had to start calling it #1 for people to take it really seriously.
But just think about it. If you're designing a new interface for a touchscreen product, your interface is a lot less explorable than a PC. There's no tooltip to begin with. No cursor that could change to a hand or carret. The user explores your interface by looking at a screen. A small one. From a distance. He can either recognize buttons and tell them apart from non-buttons or he'll be frustrated like hell.
What IS a button? Anything that you can click on a screen that performs an action is a button, more or less. So anything that ACTs like a button should LOOK like a button.
It might be the simplest of the rules, but it's very hard to fulfill consistently.
In so many products you end up with exceptions, and they ALWAYS bite you in the ass. Even if you call them 'paradigm shifts'.
Feliratkozás:
Bejegyzések (Atom)