August 18, 2005

„There should be a comma“ – or: pros and cons of detailed prototypes

This post on “Signal vs. Noise” comments on the use of the infamous “lorem ipsum” dummy text for prototyping interfaces. Jason argues that using dummy text abstracts from the real user experience more than necessary. He states that by using real text (i.e. text, which really could appear on the interface in its use context) you get closer to understanding your users and get more of a “feel” for their experience with the interface (e.g. when filling in forms), even while building prototypes.
In a reader comment on the same page, Giovanni states that the risk of using “real” text is that “the client could (and will) fixate on the content and not on design or structure. This is the source of many designer ‘horror stories’“. I think that this is a good point. It’s true that detailing out prototypes bears the risk of putting a client (or whoever is supposed to give feedback on the interface) on the wrong track. And it can be quite hard getting someone off that track once they focused on texts or colours… This is in part due to the fact that a client also is a domain expert in most of the cases so it’s very easy to comment on texts and find errors there. And with colour, well, everyone has their favourite colour… So those comments can be made with much less effort than is required for commenting profoundly on layout or interaction design… Of course this is not always helpful.

I think there’s no golden rule for the exact time when you should detail out texts on your interfaces prototypes. Of course, prototypes should become more detailed as a project progresses and Jason is right that on screen texts are often not part of this detailing-out process, but should be. It’s part of the usability engineer’s / interface designer’s job to set the right focus when discussing interface proposals and to make sure everyone stays on track and discussion not centres on different shades of blue for a button all of a sudden.
Regardless of this issue, Jason is right in saying that using real texts is a good exercise for designers themselves to get a “feel” for the interface. When using real texts one gets an impression of the amount users have to read or enter on an interface, e.g. And you can always take the texts out later and replace them by “lorem ipsum” before discussing the interface with a client who tends to focus on spelling issues instead of fundamental site architecture…

August 17, 2005

Don’t click?

During some late night browsing I came across A website that wants to be navigated without clicking any mouse button. (So I guess you can get rid of your new Mighty Mouse again.)

If you find out where on the site the different methods for navigating without mouse clicks are explained (and manage to navigate there), this will also give you an impression of the kind of problems eye tracking people run into when they are experimenting with gaze enabled interfaces. The basic problem is the “Midas Touch” phenomenon: if the simple approach is chosen, in which looking at a control activates it, the user will cause a lot of unintended “activity” on the interface. So the selection of a control has to be separated from its activation.

You can find out about options for doing so on the website and the article linked above. In any case, thinking of it, it might be a good idea keeping your Mighty Mouse…

PS: Regarding today’s previous post, maybe a zero click interface would be the ultimate goal from a certain viewpoint...

"Make it faster...less clicks"

Usability engineers should be familiar with this request from clients. When gathering requirements and goals for an application / website redesign it is not too unusual for clients to come up with a request similar to the one stated in the headline. If the client is aware of the significance of such a request in the "big scheme" of things then there is nothing to say against it. If the client, however, thinks that "faster / less clicks" is the ultimate goal for a redesign, then the usability engineer should invest some time in educating the client if he does not want to get into trouble in later phases of the usability engineering project.

Where does this kind of request come from? There are at least two reasons that "inspire" people to ask for their systems being faster and operated with a minimized number of clicks.
  • People come across usability guidelines like the "Three-Click Rule", stating that each piece of information on a site should not be more than three clicks away. The idea behind this rule is a sensible one: minimizing the effort it takes users to find information. The trouble begins when people take this guideline (and others) as a law of nature. There may be very strong reasons for structuring a site in a certain way, even if not each and every piece of information can be reached by clicking three times (and saying "there's no place like home"...) An inappropriately used Three-Click Rule can lead to sites with incredibly wide but shallow hierarchies. Some remarks on the Three-Click Rule and its implications can be found in this article on, which also contains a link to a report about testing the Three-Click rule. So in case the usability engineer suspects some misconceptions of that kind with a client, the time to educate them that usability engineering is more than "Three-Click Rule followed: good site / Three-Click Rule broken: bad site" is well invested.
  • The second factor that contributes to laws...err...guidelines of that kind appearing in usability engineering projects is a more profound one: people are interested in measuring usability. This applies to usability engineers and clients alike. Clients are interested in knowing exactly how much better their system is after a redesign and usability engineers would like to tell them to prove that they delivered good work. From that point of view, measures like clicks, time to complete a task or number of errors are very attractive, because they enable the usability engineer to come up with hard numbers to describe the "usability" of a system and they enable the customer to quantify requirements ("Make it 20% less clicks"). Now, there is nothing wrong with including quantitative measures in a usability engineering project. But quantitative measures don't necessarily tell the whole story. Just think of the whole Emotional Design issue. It is not so easy to come up with a single number to describe how pleasant an interface is (to use / to the eye), but that does not render the hedonistic aspect of an interface any less important. So the importance of quantitative measures for a project depends heavily on the interface under investigation and the purpose it is supposed to fulfil. When designing an interface for a nuclear power plant, time to complete a task (let's take "shutdown" as an example) is obviously quite important whereas for a game interface, the interaction may not necessarily be optimized for fast task completion but for making the way to task completion as pleasant as possible. (You wouldn't expect to finish an adventure game in three clicks, would you?)
To sum things up: quantitative measures are not all bad, but one should be aware of the fact, that they are only part of the overall usability of an interface. Numbers - as attractive as they may be as requirements or benchmarks - will not give you the whole picture. (No, not even 42.) If the usability engineer is aware of this fact he can tailor his approach to the concrete system under investigation. If the client is aware of this fact, that's good, if not, the client should be educated by the usability engineer to set the right expectations and to understand that usability is more than calculating numbers.

August 02, 2005

It’s in the Eye of the Beholder: On Doing Highlight Videos

Highlight videos are an essential part of the usability engineer’s toolbox. They are used to “get the message across” concerning usability issues discovered during an empirical test of an interactive system – and with every kind of message, the recipient should be considered when deciding on the exact way of doing so.

The “mechanics” of assembling a highlight video are not hard if you know how to handle software like Morae – or Premiere for the Steven Spielbergs who like to have more flexibility in editing their videos. But there is more to coming up with useful highlight videos than just being a power user of video editing software. (It helps, though).

An important part of the job is carefully considering the intended target group of the highlight video. A very basic distinction in this area can be made between developers and management. When assembling a highlight video for one of those two groups, its specific characteristics and needs should be taken into account. There is no “one fits all” approach to delivering highlight videos.

The aim of a highlight video from the usability engineer’s point of view is – not surprisingly – to prompt the audience to act in a way that will help in enhancing the usability of the system under investigation. Different target audiences have different ways of contributing to the usability of a system – managers can, e.g., contribute by allocating additional resources (in terms of money and time) to user interface design efforts whereas developers can heed the user’s perspective in their daily work and thus work towards improving usability. Because of their different characteristics, the highlight video should be “customized” to suit the intended target groups. The more a video is tailored to match the audience, the higher the probability of having the desired impact. This also means that a badly assembled video can send your usability project right down the drain…

Things to keep in mind when making a highlight video targeted at a management audience include:
  • Members of this audience tend to be interested in long-term perspectives of the project and also in (surprise) financial issues.
  • Very often they don’t have much knowledge about the technical implementation of the system or only a very high-level view. (That lack of knowledge may also go along with a lack of interest in technical details.)
What does that mean for the development of a “management’s highlight video”?
  • Don’t bother them (too much) with technical details. Don’t show them one error after another, without giving them some means to assess the severity in terms of system usability. Stringing together bugs may send them to sleep before the video is over. They may not even recognize a complete “killer” without the necessary background knowledge of the system. This means that showing user reactions (verbal and nonverbal) plays an essential part in helping the management audience in assessing the severity of an error.
  • An often seen characteristic of highlight videos is the repeated demonstration of certain critical issues happening to different users. Especially if the usability engineer has already established a good working relationship with the management audience (which should lead to them trusting his judgment) and if the video is presented by the usability engineer as part of a session, it may be enough showing one instance of a critical issue along with giving an estimate of the respective severity. By doing so, a greater diversity of issues can be included in the video and thus giving the audience more insight into the overall usability.
When presenting to developers, things may be different…
  • It is not unusual for developers to become emotionally attached to the system they are developing. (But then it is not unusual for anyone to become emotionally attached to work they invest a lot of effort in…at least if they don’t completely hate what they are doing.) And you wouldn’t feel completely comfortable with someone pointing out what’s bad about your “baby”, either.
  • Developers are interested in very concrete prompts for action. They don’t want some general assessment of usability that leaves them without a clue on what to do to improve the system. (If you go to see the doctor you wouldn’t expect him to just tell you that you’re sick and send you home afterwards.)
So when assembling the “developer’s cut” of a highlight video, some things may be helpful.
  • In contrast to the management audience, it may be necessary to repeatedly show an error happening with different users, even if a working relationship between usability engineer and developers has been established because they may require more proof of the severity of an issue than just the usability engineer stating it.
  • It is especially important to include positive aspects of the usability test. By doing so, the usability engineer demonstrates that the developers’ work is appreciated and that he is not trying to engage in “developer bashing” which some usability engineers may have a tendency to do. The second reason for including positive aspects is keeping the developers from removing those good elements when reworking the system. Don’t expect them to know what users especially like about the system if you don’t show them.
  • For demonstrating critical issues it should be made sure that the users shown in the video appear in equal proportion. The danger in showing every second example of a usability bug with the same user is that developers may get the impression that the usability engineer selected an especially…ehm...dumb user to demonstrate pseudo-flaws that a moderately intelligent user would not suffer from. So in the worst case problems are attributed to the user and not to the system design.

Did I simplify matters? Yes. Of course the world is not black and white and there’s more to it that the few points made above, but those things are issues that I think should be looked out for when engaging in a usability engineering project that includes assembling highlight videos. Acknowledging the fact that different audiences have different characteristics and needs is the first step to producing effective highlight videos.

Other issues to keep in mind when producing a highlight video are the context in which it is shown (e.g. during a presentation vs. “standalone” as part of a report that is delivered to the customer) and the impact of editing (transitions, captions etc.) on the reception of the video. But since this already has gotten way too long, you have to look up Mr. Spielberg’s blog to get advice on those matters…