Posts Tagged ‘Usability’

Guerrilla UCD – Usability, User Experience and Agile Webinars

Friday, May 18th, 2012

We’re launching our series of usability, user experience and Agile webinars with a free one-hour overview next Wednesday (23 May) at 16:30 London time. The focus of the series is to engage the whole team in user experience so they are designed for a broad audience. See for more details and to book the free overview (add it to your basket and checkout – there will be nothing to pay).

Are your abstractions too abstract?

Thursday, June 10th, 2010

A recurring theme in user-centred design is making sure that your technology is speaking the same language as its users. In web design failure to do this can make navigation difficult at best or frustrate users into leaving your site altogether. However, it is an extremely common problem – partly because the process of generalization (grouping related things under more abstract headings) is a powerful tool in building systems. Take Microsoft Outlook for example. Outlook manages email, appointments, contacts and tasks. This works fine for users when they are looking at the separate user interface elements with these names, but what on earth is an ‘item’? An item, it turns out, is any one of these things that Outlook manages. So when you are creating an email in Outlook and want to attach another email or a calendar entry, what do you do? By far the easiest thing is to drag and drop the attachment needed, because most people do not realize that the menu equivalent needed is called ‘attach item’ (more recent version of Outlook have a ribbon icon that helps a little, but not enough to get over the terminological issue).

So, when we start trying to get computers to do the things they are good at, we invent abstractions of related concepts and make up names for them (a C++ programmer can wax lyrical on this topic – just mention polymorphic collections and inheritance!). The step that frequently gets omitted is that if any of these names find their way into the user interface or web navigation, do users actually understand them? One very effective way of finding out (particularly if you have a lot terms or concepts to test) is to use card sorting. We are running our one-day card sorting course in London next month where you will get first-hand experience of both paper-based and online sorting. For more details and online booking, see (early booking finishes on 11 June).

If you can’t make it to London, you will find that we have lots of free card sorting information and tools (including analysis software) at

Facial Avoidance in Page Design

Monday, April 20th, 2009

I am a great admirer of Tom Tullis’s work. He’s made important contributions to our understanding of screen design over the years (plus he is even older than me, which gives me great cause for hope!). In a recent poster at CHI 2009, in collaboration with Fidelity Investment colleagues Marisa Siegel and Emily Sun, Tom has done it again. He explained to me their important findings on the use of face images to attract attention on web or intranet pages. The results certainly run contrary to the perceived wisdom in this area (that humans are naturally attracted to facial images).

The Fidelity studies show that not only were users disinclined to look at facial images of the type shown in Figure 1, but that a significant number of users were unable to find the text immediately adjacent when given a task requiring that information.

Box containing facial image next to link text

Figure 1: Link panels with and without facial image (Study II)

In fact, overall performance was negatively affected by the presence of the face: accuracy dropped from 93% to 78%, mean time on task increased from 37 to 54 seconds and perceived task ease dropped from 4.2 to 3.4 (on a 5-point scale).

In a separate study, Tullis and colleagues not only found that facial images reduced performance; they also had the completely unexpected effect of reducing user confidence. Figure 2 shows the quite common approach that was tested (with and without the images). Again accuracy dropped, but this time by a smaller margin, from 94% to 87%. However, trust also dropped, from 6.3 to 6.0 on a 7-point scale. This result may seem small but there is only a 5% probability of it being due only to chance, which is taken by statisticians to mean that it was significant.

 Box show author images next to link text

Figure 2: Authors’ images reduced trust in content (Study III)

So, contrary to what I remember being told in design seminars years ago, and even contrary to advice that I would have given up until I saw these studies (typified by my article on using images as links – it looks like we need to be careful about how we use facial images in particular.

(You can see the full work-in-progress paper in the CHI 2009 proceedings, which will eventually be available from the ACM Digital Library –

The joy of Plesk

Monday, February 9th, 2009

I was as surprised as anyone to discover last week that my blog, admittedly underused, had disappeared from our website. We have our own WordPress installation and like an increasing number of organisations, this is hosted on a Virtual Private Server (VPS) where we share the resources of a UNIX/Apache server with about 50 others.

To try to make the VPS idea workable for mere mortals, our hosting provider uses a product called Plesk. This is a graphical interface for setting up clients, websites and domains for each VPS. At first sight it appears very pretty and fairly well organised. Unfortunately, its attractiveness is literally skin deep – it is a “thin” interface on top of a set of fairly complex underlying technologies.

And therein lies the problem with the disappearing blog. I was foolish enough, when trying to resolve an unrelated problem, to click on the Updates icon. After some wrestling and heart-stopping moments where I was informed that the update on my remote virtual server had failed and it may therefore be inoperable (they were only kidding) I finally managed to get the latest version of Plesk installed (9.0.1). Unfortunately, this didn’t actually solve my problem and left me with missing icons in the graphical interface (wherein lies another story). However everything else seemed to be working.

Then the panic set in. A week later, clicking on a link to my blog produced only a message that the MySQL interface had not been installed. This is an essential component for WordPress and had certainly been present earlier. Not only that, on examining the status of the MySQL database for the blog in Plesk, I was informed that no databases existed. Indeed, even as you read this blog Plesk insists that it does not exist. (Perhaps carrying virtualisation a little too far!)

The problem is not a new one for user interface designers. In this case, the relatively lightweight Plesk GUI had its own ideas about the state of the system, and was not robust enough to carry these forward through a major upgrade. On using the PHP tools for managing MySQL, I discovered that the blog database was indeed present and fully functional. The problem turned out to be that in the process of upgrading PHP, Plesk had defaulted the configuration to exclude MySQL functionality. A one line change to the PHP configurations file fixed this, but as you can imagine, the overall user experience was not a happy one.

If nothing else, this does serve as an excellent example of the perils in oversimplification. There were many aspects of the underlying system that Plesk was trying very hard to hide, but at the expense of considerable confusion when problems occurred. Maybe Parallels (the developers of Plesk) will eventually put in the effort required to make the interface work for the intended semi-technical audience. But until they do, it is not for the faint of heart.

Paying tax the fun way!

Wednesday, July 2nd, 2008

Well, not exactly. While the UK’s beloved HMRC (Her Majesty’s Revenue and Customs) has come a long way with its online services, they seemed to have stopped short of providing a good user experience.

The problem appears to be that us technologists are very enthusiastic about deciding exactly what constitutes a user error, and punishing transgressors appropriately for them. So, for example, let’s consider the following example: 

Error message repremanding user for failing to make a choice when only one option is displayed

Users do this all the time. There is no choice to be made and the empty radio button does not provide an adequate visual cue that something needs to be done. The Next button was enabled, so being as bad a user as the next when it isn’t my own design I clicked on it and received the ticking-off you see above. I find it very hard to believe that it is really necessary to force the user to make a selection, but disabling the Next button would be an obvious alternative to dealing with a user error. That would require client-side scripting but an equally acceptable alternative would be to select the first item listed by default. But the biggest failing is the lack of empathy that designer of this interaction is suffering from. How does he or she think the customer (taxpayers are customers, right?) is going to react to receiving an error message that appears to deliberately intended to cause frustration?

But there’s more. On the same site, but in a different form, users are required to enter the cash equivalent for tax purposes of a company-supplied car. For this purpose, they are invited to visit a web page that does the calcuation and then to enter the result into the form. It’s a bit clunky, but that is not the only problem. Here is the calculator result:

Page showing cash equivalent of car with a comma as the thousands separator

Notice the comma pound sign and the comma? Trying to copy and paste these figures – from the tool that HMRC recommends – causes a message like this:

Error message stating that the input field must be numeric (it contains a comma output by the calulator)

The really galling thing here is that it is very much easier to write code to ignore unwanted commas than it is to complain about it and force users to put it right. And that really is the smoking gun in most of the empathy-deficient cases I see: the designer has become fixated on handling the error rather than working around it in the interests of good user experience. Sigh.