Usability 101: Satisfaction

Today, we con­tinue the Usabil­ity 101 series by explor­ing the con­cept of satisfaction.

I can’t get no… satisfaction

As much as we’d like it to, users are not using our soft­ware because of love for devel­op­ers. They are using it to accom­plish a task. How sat­is­fied they are with usabil­ity of the soft­ware pack­age they use is an impor­tant con­sid­er­a­tion that can take them from using your sys­tem to using a competitor’s.

The basic con­cept of user sat­is­fac­tion rests in the fact that users want sys­tems to be intu­itive. They want a pro­gram to work in the way they think. How­ever, as we learned ear­lier, users come in dif­fer­ent shapes. What sat­is­fies one user may not be what sat­is­fies another one. What is intu­itive to a pro­gram­mer is not nec­es­sar­ily intu­itive to an aver­age user.

As a result, it is impos­si­ble to sat­isfy all users all the time but it is pos­si­ble to sat­isfy most user most of the time. In a way, the sat­is­fac­tion of a user is directly cor­re­lated to the other con­cepts we have explored through­out this series so far (learn­abil­ity, effi­ciency, mem­o­ra­bil­ity, and error han­dling): if a sys­tem is easy to learn, can be used effi­ciently, has fea­tures the user can remem­ber, and pro­vides easy error mes­sages, a user will be sat­is­fied with the over­all experience.

Looks

How­ever, going beyond those crit­i­cal fac­tors is also a level of graph­i­cal design. You can design the best appli­ca­tion in the world in terms of usabil­ity but, if the inter­face looks ugly, the user will shriek every time he or she uses the system.

This is gen­er­ally an issue in the open source com­mu­nity as most pro­gram­mers are not design­ers (and the inverse is true) so most open source projects have fully func­tional UIs that are spar­tan in their appear­ance. This is not a bad thing in and of itself but leaves non-programmers with the feel­ing that those appli­ca­tion are less pol­ished. As a result, this low­ers the user sat­is­fac­tion in those sys­tem and also low­ers the accep­tance of open source software.

A way to solve this is for pro­gram­mers to enter into a part­ner­ship with design­ers and usabil­ity peo­ple. The usabil­ity per­son comes in and helps on the other fac­tors we cov­ered in the series. The designer pro­vides that last coat of paint that make the appli­ca­tion look bet­ter. The chal­lenge in work­ing with those peo­ple, how­ever, is that a lot of the dis­cus­sion should hap­pen early in the project so that the under­ly­ing struc­ture is in place to allow for look revisions.

Another item to watch out for is design­ers that get car­ried away. One must ensure that the appli­ca­tion is not so heav­enly laden with a heavy set of eye candy that it calls more atten­tion to the look than to the rest of the appli­ca­tion. 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 inter­face does not call atten­tion to itself but makes the user feel that it has that polish.

Feel

Another issue with heavy UI is that it some­times hob­ble per­for­mance. How­ever, it is pos­si­ble to increase the sat­is­fac­tion of a user by divert­ing his or her atten­tion when using the appli­ca­tion. Such diver­sion must be trans­par­ent so that users do not catch on, sim­i­lar to the sleight of hand pulled by magi­cians, get­ting you to focus on one thing while they are doing some­thing com­pletely dif­fer­ent. For exam­ple, much has been made about how speedy Apple’s web browser, Safari, is. But truth be told, it is only mar­gin­ally so. The way the Apple pro­gram­mers made it feel faster was by paint­ing the first win­dow more quickly, which give the impres­sion that the appli­ca­tion is more respon­sive. By com­par­i­son, the Mozilla browser feels like it’s tak­ing longer to load because it first shows a logo, before dis­play­ing the appli­ca­tion. The dif­fer­ence between the two is that, in the case of Mozilla, the user has to wait an extra few sec­onds to see the browser win­dow. As a result, it “feels” slower. Granted, other improve­ment to the Safari browser make it run faster but, for the large part, most of the speed improve­ments on the Mac OSX plat­form have been in mak­ing appli­ca­tions look and feel like they are mov­ing faster.

Who’s my user

Before con­cen­trat­ing on those issues, how­ever, one must fig­ure out who are the users of the sys­tem: are they tech­ni­cally pro­fi­cient or not? What age group do they fall in? How do they use the soft­ware? What other soft­ware do they use? This is where the con­cept of per­sonas, which I will cover in more details later, comes in. Before design­ing your pro­gram, fig­ure out what types of users are going to use it.