When we, as members of a project team, focus on usability (and we should always focus on usability), we’re concerned with supporting people in accomplishing their tasks. This shouldn’t be confused with “functionality,” however, as the mere presence of good features and functions has little bearing on whether people are able to use them.
When we overload products or services with too many features, or when we provide them in ways that don’t match people’s expectations or needs, it’s difficult for people to access what’s needed when they need it, let alone use it once they do find it. When that happens, people end up fumbling with the product or service rather than achieving their goals. They are very likely to abandon what they’re doing, or find another way to achieve that goal.
Think of it this way: People don’t use ATMs for the sake of interacting with a machine on a wall. They use them (predominantly) because they want some cash. To design an ATM — or any product — that’s as usable as possible, we need to consider a number of factors:
- Who are the users? They’re people who are not going to be “trained” in using an ATM. They don’t need to have special knowledge of financial systems. They may not speak the local language.
- What are their goals? We can assume that it’s mostly about getting money, so we need to optimize our design for that. However, users may want to make a deposit, check their balance, or perhaps other things. Therefore, the process must be flexible.
- What is the context? ATMs are typically out in the open. Particularly in busy thoroughfares, there is often a queue to use them. Privacy is important for people in order for them to feel that it’s secure. There may be glare on the screen during the day, or not enough light in the evening.
These considerations are just scratching the surface, but start to shed light on what this might mean for the solution.