These task-orientated usability report samples are chosen at random. No graphs, screenshots or tables are shown. "xxxxxx" is used in place of identifiable names or concepts.

---

Radio buttons

The radio buttons worked only for two of the user testers, the other two were frustrated by the fact that nothing happened, and the testers resorted to double clicking in a single click environment. This caused large time delays of 2 to 3 seconds. They did work out that simply clicking on the text link instead of the radio button got results. However, it was interesting to note that these two user testers kept clicking inside the radio buttons, repeating the same frustrations.

The rules for radio buttons state that they are used to select one among a set of options but that the choice of options does not take effect until the user has confirmed the choice by clicking an OK button. On your site, radio buttons are used as action buttons that have an immediate result when clicked. This deviation from accepted interface standards makes those parts on your product difficult to use.

 

Part of an introduction

One user tester was unable to think aloud in such a way as to make voice recording possible. In general, "thinking aloud" slows the thought process, and I do not force user testers to comply if they find it too unnatural or distracting. User testers were given the tasks one by one on a card, so as not to overwhelm them with a list. A task was declared complete if either the user tester said so, or too much time was taken, in which case I stopped the task. My time benchmark was around six minutes per task. I allowed more time if my observations indicated that the user tester was really getting there, or if I found I could collect interesting observational data.

 

Success scores

Table 1: shows 34 successful (S) tasks out of 44, giving the site a 77% success score. In some usability studies I have awarded partial success scores for tasks that were almost completed. In this particular study we could argue that as all user testers found at least the editorial e-mail link in question 4, they should be awarded a half point for partial success.

Table 2: If we award a partial success rate (P) as in task 2,4 and 5 - and give a half point, we arrive at a 84% score. In this case I prefer the result from table 1, and a 77% score is a good one. In fact, most web sites score less than 50%. When users try to do something on the Web for the first time, they typically fail. However, not too much should be read into these numbers as they can change dramatically if for instance we introduced a time limit per task. Never the less, it gives some indication, some benchmark, and can give a way to measure progress towards a better product.

 

Radio buttons 2

All radio buttons should be removed from the site. Users should be able to just use the hypertext links that would remain after the removal of the radio buttons. Contrary to the recommendation on this point in my preliminary report, I would now like to include one exception: If there are clear multi choice combinations, then there should be radio buttons followed by a "Go" button. The "Go" button would execute the choice or combination selected by the user. This would mean that the text next to any radio button should be black, so as to clearly differentiate it from the other hyperlinks and indicating that the user must select a combination. Users would now perceive the use and behaviour of any radio buttons as more orthodox.

 

"Next" buttons

It would be good if you removed all "Next" buttons on the site. Next buttons are always problematic as they rarely explain what is next, and if you have a "next" option you should also have a "previous" option. The numbered (12345) options displayed in the left column are clear, and are repeated in the main page. By introducing a third element in the form of a "next" button you have become overly helpful (known as redundant navigation) and counter productive. From my observations during the one-on-one testing sessions, I noticed that a user tester would just click on the "next" option without being clear of what was next. The danger of "next" buttons in any interface, is that users just start cycling through all the "next" options in the hope of finding something he or she is looking for. This is of course an inefficient way of finding information. In some cases the amount of text is such that the user must scroll down the page and thereby losing the 12345 option from sight. In that case it is much better to show the 12345 option again at the bottom of the page.

 

Inconsistent navigational design

The user testers often wasted considerable time at the Management Overview section of the site. This was caused by a serious inconsistency in the navigational design in the left hand column. If a user clicks on "xxxxxxx" (see left) nothing happens, this is in direct contrast with point 8, where something does happen in the main part of the page after clicking on "xxxxxxx". The fact that nothing happened after clicking on "xxxxxxx" in the Management Overview section was not noticed by any of the user testers. The user tester would merrily sit and wait (between 2 and 5 seconds) for an action to take place in response to the click he or she made. A permanent "reveal all" with the word "xxxxxxx" not linked to an action (mouse pointer does not change) would solve the time delays. Again, this is what I recommend for the entire site (see point 8). A reasonable alternative would be a "rollover" were the options directly below "xxxxxxx" are revealed as the mouse pointer rolls over the link "xxxxxxx". However, this in itself brings with it other undesirable effects such as the sudden disappearing and reappearing of any links further down the screen. In either case you should make sure that all elements within the site work and behave in the same way, as this will speed up the learning process and prevent time wasting.

 

Platform and browser issues

The only noticeable difference between the PC and Macintosh platform is that the Content map can not be displayed on a Macintosh computer. I tried this on two high-end Macintosh systems running OS 9.1 and OS 10.2, using both, Netscape and Explorer on each. I recommend you look into this.

The site performed well within the narrow range of browsers specified - Explorer 4.01 to 5.5 and Netscape 4.5 to 4.76. In Explorer 5 and 5.5 the user is able to increase the font size by simply using the keyboard combination Cntr » +. This is not possible in other Explorer versions and not possible in any of the Netscape versions. I tested the site on a machine with low specifications and Explorer 5. The site performed noticeably slower, more sluggish. It is important to remember that the type and version of browser is only one part in the equation.

 

Location within navigation space

(Question inserted by client: where do you think you are [location] within the website?)

The question of whether a user knows where he or she is within the navigation space (web site) is a difficult one. I am not surprised that none of the user testers were able to verbalise an answer to this question in a sensible way, other then using vague terms like 'four levels up' or 'two down' (see audio transcripts).

Users don't much care "where they are" in a web site. So-called "breadcrumb links", which show the user the exact hierarchy of the web site, are a nice but mostly irrelevant technology. It's not that users don't understand the links; it's that they don't care.

One of the problems with web sites is that they exist within a 2D space, as opposed to a book, a 3D space. Human beings have a lot of difficulty orientating themselves within a 2D space like a web site. In my opinion it is more important that a user is able to solve a problem (find particular information) from anywhere within the site, without understanding the exact location of the starting point.