Usability model

I have been thinking about how we can get a handle on the usability problem in terms that engineer programmers who are not psychologists can make use of.


My critique of the usability engineering I have read about to date is that it is science, not engineering. Computing is an engineering profession as my college tutor said. Engineering should focus on the application of theories. The role of empirical tests should be confined to the development of design theories and confirming the soundness of designs that have already been shown to be correct with respect to design theories. 

Trial and error is not an engineering approach. Only the application of established design theories is properly engineering, the development of design theories is engineering science. While a small number of engineers do perform engineering science their role should be to deliver solid design rules that the rest of the field can apply.

Nielsen wrote something similar in one of his recent columns. The conclusion I drew was that Web designers should absorb the conclusions of empirical studies on Web site usability. Testing is expensive. If we are designing a web site we should only test designs that are theoretically sound. If we are researching design rules for Web sites it is acceptable to test designs that are not sound.


I believe that we do need to perform some engineering science here and we will have to take into account a certain quantity of data from the psychology literature. But the objective should be to provide engineers with design rules that can be applied without detailed knowledge of psychology. 

Consider the role of design rules in VSLI design. I know very little of modern VLSI fabrication techniques. It is over two decades since I did any VLSI design. But I don't need to know how the process works to use the VLSI design tools because the developers of the fabrication process have converted their empirical measurements of their process constraints and used them to develop a series of design rules that specify minimum feature sizes, minimum spacing between tracks, etc. etc. Provided my design fits within the design rules there is a very high probability that it will work.


So first let us divide the usability problem into two considerations:

   * What the user must know
   * What the user must do

Humans are not finite state machines. But step by step instructions that humans are expected to follow are finite state machines. Machines that have more states, machines that require humans to require more information, machines that require humans to handle information in a form that is further from their mental representation, all these features will almost certainly reduce the usability and acceptability of the final result.

As with formal methods I suspect that the most significant impact that a design methodology of this type would have on the field would be as a pedagogical tool. Once students are told that they have to provide a formal proof that their program is correct they quickly learn ways to simplify their program to the absolute essentials before they perform the tedious task of constructing proofs.


So for example lets consider a use case that is not directly related to our specific problem here, configuration of an email client. To configure an email client today I have to:

1) Choose or be assigned an email address:  username@example.com
2) Choose or be assigned a password

Assuming that we are using passwords as the authentication method I don't see that these steps can be eliminated, nor is there any value in attempting to eliminate them since the user has to be familiar with both pieces of information to use the system.

The problem comes with the other information the user has to enter in the next screen:

3) The address of the outgoing mail server
4) The address, protocol and security configuration of the incoming email server


There are two problems here. First the user is forced to become aware of the internals of how the mail system works, information that does not play a necessary part in the user's mental model of the system. As far as the user is concerned they send an email from their machine, it is received at the recipient's machine. Why bring incoming and outgoing servers into it at all?

The second problem is that telling me the information I need to find does not tell me how to obtain it. My ISP is Comcast, over the years they have changed my mail address three times. Each time their mail servers have also changed. OK so this may be unavoidable but each time the mail servers changed the notification telling me about the change has not given me the new information I need to configure the system. Instead I have been given instructions on how to configure a set of email clients I don't actually use.

It is easy to dispense with the need to involve this information entirely. If email client providers and ISPs both supported the SRV record the mail server configuration step could be made entirely transparent. A complex, mystifying process can be eliminated entirely.


Eliminating unnecessary steps that the user is required to perform is good. Eliminating information that the user requires to do their job well is not.


One of my chief frustrations with computer systems is the feeling of total powerlessness and confusion that generally accompanies attempting to get to grips with some new system. If you think UNIX, VMS or Windows are bad I suggest you try to learn Open Genera. 

Very few computer systems organize information in a way that makes immediate sense to the user. Large computer systems almost invariably have organization systems that are either incomplete or have evolved substantially over the years and have become inconsistent. The UNIX documentation is incomplete because the documents describing the system architecture in a coherent fashion were never written. In Windows there are multiple system architecture documents and they don't always agree. VMS was the exception here, there was a good system architecture manual and if you were fortunate to read it and understand that it was the master key to the entire system everything made sense. If you didn't happen to take that particular binder out of the grey wall you were no better off than with anything else.


What is important is not just the quantity of information that the person must know but the type of information. The further removed the information is from the terms in which the user thinks the harder the system is to use, the more time it takes and the greater the opportunity for error.

For my doctorate I worked on a programming scheme, Gödel were the idea was to write large systems using a series of code synthesizers that were each focused on very specific tasks. So instead of writing a user interface you used a simple tool that took an abstract description of the programming interface and converted it into the glue code required to realize the interface. If you were writing a browser you used a tool that converted a state machine representing a protocol into the code to implement that protocol and so on.

The reason declarative programming languages and synthetic programming approaches such as Gödel are more efficient than imperative code is that the programmer can write the code without switching from the problem perspective to think about implementation. 


Looking at the security shortcomings of the Internet some common themes emerge:

1) The user is never told what parts of the display are trustworthy and what parts are not.

2) The user is expected to verify their mental model 'I am dealing with Ebay' in the context of deep knowledge of Internet protocols, by relying on the URL encoded in the domain name.


I would like to extend the use case methodology to security, draw up some use case diagrams, map out the processes the user is expected to follow as state machines, look at the information the user is expected to manage and whether the connection of that information to their likely thought processes is acceptably direct.

Received on Friday, 8 September 2006 22:26:56 UTC