I can’t get no… satisfaction
As much as we’d like it to, users are not using our software because of love for developers. They are using it to accomplish a task. How satisfied they are with usability of the software package they use is an important consideration that can take them from using your system to using a competitor’s.
The basic concept of user satisfaction rests in the fact that users want systems to be intuitive. They want a program to work in the way they think. However, as we learned earlier, users come in different shapes. What satisfies one user may not be what satisfies another one. What is intuitive to a programmer is not necessarily intuitive to an average user.
As a result, it is impossible to satisfy all users all the time but it is possible to satisfy most user most of the time. In a way, the satisfaction of a user is directly correlated to the other concepts we have explored throughout this series so far (learnability, efficiency, memorability, and error handling): if a system is easy to learn, can be used efficiently, has features the user can remember, and provides easy error messages, a user will be satisfied with the overall experience.
Looks
However, going beyond those critical factors is also a level of graphical design. You can design the best application in the world in terms of usability but, if the interface looks ugly, the user will shriek every time he or she uses the system.
This is generally an issue in the open source community as most programmers are not designers (and the inverse is true) so most open source projects have fully functional UIs that are spartan in their appearance. This is not a bad thing in and of itself but leaves non-programmers with the feeling that those application are less polished. As a result, this lowers the user satisfaction in those system and also lowers the acceptance of open source software.
A way to solve this is for programmers to enter into a partnership with designers and usability people. The usability person comes in and helps on the other factors we covered in the series. The designer provides that last coat of paint that make the application look better. The challenge in working with those people, however, is that a lot of the discussion should happen early in the project so that the underlying structure is in place to allow for look revisions.
Another item to watch out for is designers that get carried away. One must ensure that the application is not so heavenly laden with a heavy set of eye candy that it calls more attention to the look than to the rest of the application. A UI expert once told me that his job was to make sure that no one ever saw what he was doing. A good user interface does not call attention to itself but makes the user feel that it has that polish.
Feel
Another issue with heavy UI is that it sometimes hobble performance. However, it is possible to increase the satisfaction of a user by diverting his or her attention when using the application. Such diversion must be transparent so that users do not catch on, similar to the sleight of hand pulled by magicians, getting you to focus on one thing while they are doing something completely different. For example, much has been made about how speedy Apple’s web browser, Safari, is. But truth be told, it is only marginally so. The way the Apple programmers made it feel faster was by painting the first window more quickly, which give the impression that the application is more responsive. By comparison, the Mozilla browser feels like it’s taking longer to load because it first shows a logo, before displaying the application. The difference between the two is that, in the case of Mozilla, the user has to wait an extra few seconds to see the browser window. As a result, it “feels” slower. Granted, other improvement to the Safari browser make it run faster but, for the large part, most of the speed improvements on the Mac OSX platform have been in making applications look and feel like they are moving faster.
Who’s my user
Before concentrating on those issues, however, one must figure out who are the users of the system: are they technically proficient or not? What age group do they fall in? How do they use the software? What other software do they use? This is where the concept of personas, which I will cover in more details later, comes in. Before designing your program, figure out what types of users are going to use it.