So on Planet KDE there is a bit of discussion regarding usability, discussion brought on by an article on a programming weblog.
The topic of the article was a group that decided to make a copy of Pidgin, the most popular open-source instant messenger. The copy is called Funpidgin and was essentially created because the people making the copy feel the Pidgin development team are not listening to the needs of their users.
Celeste Lyn Paul, one of the KDE team’s usability designers (the group that tries to make the software we make actually usable by the end user) noted that the Funpidgin project needed to be careful with how much they allow the user crowd to drive the direction of the project.
Derek Kite made a comment about the amount of issues that people bring in the name of usability. He then later posted a followup where he says that usability is fine to get inexperienced users acting but tools for more advanced tasks are usable because they work, and that those tools with usability design are usually not useful at all because they are designed by those who don’t use them. i.e. the user would be the best designer.
I don’t disagree but I have an alternate viewpoint based on some of my experience operating two of the most advanced “tools” in the world, nuclear reactor plants:
I first qualified on the S5W nuclear reactor plant. This plant was very old by the time I qualified on it (MTS-626, used to be SSBN-626 U.S.S. Daniel Webster, commissioned April 1964). It was also very well understood, tried and true. The plant I’m currently qualified on, S8G was a quantum leap above. Many things I used to have to verify were done were either not required or performed automatically. The capabilities were more impressive, the plant design was easier to understand. It was better in most every respect, as it should have been, what with all the operational experience the designers were able to integrate from S5W and later plants. Neither of those two plants however, were designed by it users, the nuclear operators and supervisors.
Now, the users of these plants were certainly involved in the design of the follow-on plant. It would be foolish not to get the input and experience of the people who actually use the plant which you design. But the design is still left to the smart guys at Naval Reactors and their contractors. I’m not kidding about smart either. It seems like at least once a week either by looking around or digging in the books that I’ll notice something which had to be designed in to solve or prevent a problem. Even as much as the operators understand the plant, their knowledge is dwarfed by the designers and engineering who designed and maintain (but don’t actually operate) the plant.
Users have only their own experience, however great. By leaving the design to other engineers, who have access to many users and their own expertise, Naval Reactors is able to use that big picture view to develop better designs, which future generations of operators will be able to use. In much the same way, software designers need to use the input of the users of their programs to develop better programs. But completely user-driven design can be hazardous. Different users want different things, sometimes with conflicting demands.
For example, there is a performance issue in KDE (and now in Firefox) due to the fsync() and fdatasync() system calls. Those calls are there to prevent data corruption. Some users aware of the issue disable those system calls (and thereby risk data corruption in the event of a computer crash) in order to increase performance. You can’t make both users who demand performance and users who demand data integrity happy in instances like these. Well, you could perhaps add a checkbox… ;)
You can’t always just add an option though, and sometimes you can’t make everyone happy. That doesn’t mean you shouldn’t base your work off user feedback though! Just as the designer may have the overall big picture view, the users will see things in actual use that the designer would not have thought of, either actual bugs or better ways to do things. This, in my opinion, is the process of usability. The work and value of the actual usability experts shouldn’t be diminished just because of people who make bad suggestions in the name of usability. I’ve seen quite a few programs noticeably improve after a usability review with no loss in functionality. (Edited 18 May to fix spelling)