What usability means in a software system, and how to design your system to be intuitive.
There is a lot of talk these days about the “science” of usability. But usability is no more a science than graphic design is a science. There is a lot of technique to learn, there is a lot of psychology at work, and cultural familiarity plays a significant role. So it’s not for nothing that design requires training and experience. The “science” of usability can make use of interviews and user-testing to validate a design and suggest improvements, but the real work of usability lies in the thinking behind the design.
In my first startup, I had to figure out what it was that made an interface “intuitive”. I came up with three rules:
The first is the most important. If an operation on structure uses the ALT key, then other operations on structure should use the same key. If ALT+Shift has a meaning in one context, it should have the same meaning in a different context. (So if you use Shift to delete something in one area, you use the same thing to delete things in another area.) Similarly with graphics — buttons that do the same things should have the same names and be in the same locations.
The second principle is efficiency. It is also important, but it gives way to the first. (I optimized the other way around at one point, and regretted it ever after.) To be efficient, the most frequently performed operations should have the fewest number of steps. It’s okay if something you do only rarely requires several steps. It’s not okay for something you do all the time. (Many an interface fails, on this score. The system may be “usable”, in the sense that a user doesn’t have any trouble figuring out what to do, but when it fails on the efficiency scale, it will eventually lose to its competition.)
Finally (a distant third), comes the subject of familiarity. This is the “cultural familiarity” part of design work. In America, the good guys are in the white hats. In Asia, they’re the ones wearing the black clothing. That’s something you need to know when you’re producing a movie. Similarly, you want your interface to be as familiar as possible to people who have experience in competing products, or who use other apps that are used in conjunction with yours.
So when it comes to the rules, the first is the most important. The second is also important, but gives way to the first. All things being equal, the last is significant, as well. But unless there is a really good reason not to, it makes sense to optimize in favor of #1 and #2. (You can do that, when you’re pioneering the application space. When you’re building something that will work in conjunction with some other program that is in widespread use, you may be better off to swallow your pride and follow their lead.)
The reason for prioritizing those considerations is that there are frequently conflicts between them. There are, therefore, choices to be made! That is where the design approach becomes important.
Copyright © 2017, TreeLight PenWorks