HCI Blog

As the HCI course comes to an end, I’m still not sure why usability isn’t generally far more widely discussed.  Why aren’t developers taking it more seriously (or perhaps they are, but then why aren’t they more effective in implementing usability improvements?)

Perhaps by way of partially answering this, some other questions need to be posed.  Why are products with poor usability like Microsoft Office and Facebook so successful?  And if market dominance plays a part in their continued success, then how have they been able to keep this?  Why hasn’t a competitor been able to eat into their share with a far more usable product?

Our clients, in the field of public transport, are trying to make their sites more usable.  This despite a difficult structure.  And transport planners generally have not been good at making things easy for their users (thetrainline.com, National Rail and others have made some recent improvements, but are still inefficient compared to, say Easyjet).  I believe this has much to do with the difficulty of establishing a model that is easy for users to understand.  Easyjet do have an advantage – they fly to and from, with no stops.  Trains stopping at stations add complexity, being able to take multiple modes of transport to complete a single journey (as with our clients’ sites) add more complexity still.

Passengers are familiar with the simple model of timetables, but this takes no advantage of the technology, and is too complicated to be adapted for journeys that use more than a single train or bus route.

However, passengers are becoming familiar with departure signs on stations and bus stops.  This is a simple model, easy to grasp, and has been effectively deployed in software products: for example the Brighton Bus Widget or the Trains app for iPhone (not currently available).  These products are intuitive, in essence simply replicating a departure board, and valuable when personalised so you can see the stops or stations that you use. 

The data available is vast and the possible applications are almost infinite.  So while a great many small changes can be made to significantly improve the usability of the sites (the “low hanging fruit”) perhaps what is really needed is to look at small solutions – simple models – that are easily understood.  Perhaps it is by building up and using a range of these in combination that users will be able to accomplish more efficiently and effectively (with less learning and remembering) the full range of more complex goals that are currently possible (if somewhat difficult) to achieve on a typical public transport journey planner.

A user trying to plan a journey with one particular site is entering the time as 14.30.  She is getting an error – the time is in the wrong format, use H:MM.  So, she puts in 2.30.  Then 14.30 again, then 2.30 again.  You see, the single H suggests a 12 hour clock.  And the difference between “:” and “.” has not been registered – and why should it be?

The user does not succeed to get beyond this point.  She is determined to use the site to plan her journey and goes to consult the timetables (effectively reducing the whole thing to its paper equivalent).  Why?  Because the designer did not anticipate that some users would enter the time with a dot in it (ironically, the possibility that other formats would be used is accounted for – 1430 for example would have been accepted).

And this is surely evidence that no user testing has taken place at all, or it would have come to light very quickly.

It is an omission that is very difficult to excuse.  And how do you phrase a redesign proposal for the client that they do something as basic as handle a *@X*!X@ dot?

One aspect of user testing that has surprised me is the propensity of users to blame themselves. Although I mentioned previously how easy it is for a user to fall into thinking that any difficulty they have in using software is down to their own ignorance or lack of understanding, in our tests we were quite explicit that it is the website we are testing.  (User testing may be a phrase that we have to be careful of… it can be interpreted in the wrong way, and we are now using “usability test”.)  All the same, the kinds of comment that we have heard have often been far more self-critical than critical of the design.

Multiple users became engaged with the task as if it were a test of their critical faculties.  ”I’m sure I could do this if I tried it again” or “Let me have another go” were among the responses.  One user felt she must work it out ”If I came back and had another go next week, I’m sure I’d get it”. They understood they were engaging with a computer, and that that if they could crack the logic they would be able to unlock the information they were after; they seemed unaware (or were not focussed on) the fact that the site could have been constructed with less obscure syntax or simply clearer instructions.

An older user commented “I’m sure this site would be good for younger users.”  Interestingly, so far it has been younger users who were more critical of the site design.  They have not, however, tended to enjoy using it. 

Despite the fact that some users were engaging with the task as a challenge, any possibility of “failing” must make the site less enjoyable which, as discussed previously, may decrease its usability.

One of the difficulties in designing a task scenario is that, even when the higher level goals for the site are agreed on, it can be hard to design a task that will effectively net every possible problem with the site.

Without user results, there are an almost infinite number of possible problems a user will encounter.  Decided on the path or paths the user should endeavor to navigate through the site will perhaps limit some of these possibilities (though it will, at least, eliminate others and give information as to the severity of the problems encountered).

Having results from a previous user testing is very helpful in designing the next one, because it allows you to prioritise certain aspects.  For example, where a couple of users have stumbled over something, it may be desirable to set a task that will allow the problem to be dissected more closely.  However, the problems that will be encountered are still limited by the constraints of the previous test.

Asking a user to “just use” a website (without a goal) is unlikely to provide anything useful at all.  Observing a user who has gone to the site could be more informative, but I cannot see how to overcome the technical and ethical issues that would be involved in doing this, unless it were a very commonly used site such as Amazon or BBCi (and from the picture that is emerging it would certainly seem our client’s is not). 

Trying to think of every possibility oneself provides as starting point, but is also limited, though working at the boundaries (as in debugging) of what the site can do would seem a good way test.

Ultimately, of course, a 100% exhaustive catalogue of every usability problem is not going to be achievable, and addressing them all is unlikely to be feasible either, so by using a combination of approaches the best we will achieve through designing the best tasks we can is the identification of the larger and more common issues.  Happily, these will (by their nature) be the first to present themselves.

Earlier in the week we obtained our first feedback from actual users.

This was highly informative.  Data from real users is more credible and compelling than anything we have discussed over several hours prior to this. If we were doing this again, one thing I would definitely make sure of would be getting real user data in early.

The dilemma in setting the first tasks for user testing is that in order to have a really clear idea of what needs testing, user input would be useful. But until you have your task, you cannot test any users.

Repeating this exercise, I would have gone for an early test, even just with one user for each of the four regions we are looking at.  If the data were used purely for designing subsequent tests it would be of great value.  Having established at a higher, more abstract level what the usability goals are, the output from a test is clearly so densely packed with information that perhaps it is better to consider carefully one test and contemplate all the questions and possibilities it raises than to try to do more. The danger would be that one atypical user could set you on a wrong course.  The benefit would be that a course based on real user-derived data is easier to engage with and grounds the detail and planning for subsequent tests.

There’s quite a contrast in styles between these; no doubt reflecting the needs of the client and the quality of the research.

Here’s a report on the iPhone.  It’s not clear from the report who it is for (which I think is a bit of a failing), and despite some interesting tests it seems very superficial.  Perhaps it’s publicity for the company doing the test?

By contrast, here’s a report on Wordpress.  It’s certainly more technical, though given the client this is not surprising, and it remains very readable.  There’s plenty of information supported by screenshots and direct quotes from users.  There are two rounds, testing version 2.5 and prototyping.

Incidentally, there were 5 users in the latter test to 6 in the former, but they are testing two products (the .com and .org versions of Wordpress).  In the former, users are said to have “different usage patterns”, in the latter much fuller details of the screening process are given.  

In the Wordpress report there is some skew, however, since the participants were in the first instance self-selecting.  They used talk aloud, eye tracking and video from Morae.  The report is illustrated with screen captures, many of which include eye-tracking data.

Previously I touched on the fact that some software if not hides then does not draw attention to some features so as to maintain the focus on core functionality.

This should only be done so that it does not impair the user experience for those not using the “hidden” features, and so that they are easy to find when sought.

This would address the fact that any successful piece of software is going to have users who, within a given range, will have some diversity in their usage.  It maintains learnability and memorability whilst allowing sufficient complexity to provide extra features and fine tuning to those who want it.

Another option would be to allow users to customise their interface.  They would be able to give prominence to icons, buttons or menu items relating to functions they needed to access at the expense of those that they never used.  In theory it should then be possible to get closer to the ideal of the software specifically addressing an individual users needs.

In practice, this may be a problem. Do users always make the best choices in constructing an interface?  They may choose which features to place on a panel but not give attention to considerations such as grouping or how productive (or otherwise) it may be to have two functions adjacent to one another, potentially diminishing the efficiency and hence usability of the software. And any such problems will be exacerbated by the fact that another of the essential aspects of a usable interface is learnability, but any customisation choices made whilst learning are by definition made without a full understanding of the software. So these choices may impact on the effectiveness of the software and there can of course be no benefit to learnability from customisation since, for any given widget, you have to work out what it does before you can change it.

Having taught statistics, my natural inclination is towards a quantitative approach to gathering data. However, in finding usability issues it is the qualitative data that will give us the issues that need addressing.  As such, the question of how many users is beyond simply determining a sample size, and with business costs and benefits resting on employing the optimal number, there is plenty of literature on this.  In How Many Users Is Enough Turner, Nielsen and Lewis defend the radical proposition that most problems are detected with just five users.  Two potential flaws in this are the assumptions that (a) there is a relatively high probability of a user detecting a problem and (b) that the probability will be the same for all users.

With four regional websites to test, realistically numbers are going to need to be relatively modest. It is tempting therefore, to rely on the findings of the likes of Virzi and Nielsen that we will have sufficient.  However, we are also keen to test with a representative demographic, across both genders and three age ranges, since the target audience (public transport users) covers most of the general population. Perhaps this diversity could mean there is more likely to be variation in the probability of any given user detecting a problem?

Usability and games is a bit of a special case.  A satisfying game is not easy to master – you want challenge.  You want to be able to “discover” tricks for yourself, so they can’t be handed over to the user on a plate (this is not, of course, the same as making it difficult by providing a bad interface). On the other hand, it must be possible to find these “tricks” or there’s no point in their being there!

Productivity software is very different surely?  You use it to achieve something.  You want to know exactly how to do what you need to achieve your goal right away – the faster you can learn it, the better?  Perhaps… except for the problem of features.

Imagine a piece of software designed for one user.  It has exactly the features needed – no more, no less – and (after extensive user testing during the design process) it is intuitive, easy to learn, memorable – usable.

It’s a great piece of software, and a few other potential clients contact the developer.  ”We’d love to buy this” they say, “but it doesn’t quite do what we need.”  They tell her they must have feature x and feature y.  So these are added in.  Now keeping it as easy to use become harder, because (a) there are more users to satisfy and (b) because the additional features add more complexity.

I’m going to leave aside the first point (which I may return to), and focus the second on making the functionality deeper and more powerful (as opposed to adding features that broaden the scope of the software at the expense of cohesion).   Thus the first user has more limited needs, at least at first (perhaps later they will want a product with more advanced functionality).  The developer does not want their software to be simply a “beginner’s tool” with users moving on to a more advanced product.  Yet they wish to maintain the simplicity that supports the ease of use for unfamiliar or infrequent users.

One possible solution is hiding features.  Google appealed to a lot of users by being simple and cohesive, but later they added extras to satisfy power users and those wishing to customise their search portal.  Everytime there is even a small change on the Google front page it excites comment across the web; a testament to the fact that such changes are kept minimal.  There’s an option to sign in and register in the top right corner that gives access to iGoogle and other functions that I didn’t even notice was there for ages.  It certainly never distracted me from being able to use the simple, essential search functionality.

This approach is related to the way Apple provide functionality.  There a few instructions with their products (essentially how to get started).  But by holding your finger down on your iPhone, you discover the magnifying glass, or the means to reposition your icons.  You can manage without them, you do not need to know them to get started, but with them you can do more.  Because they are intuitive, it’s often possible to discover them when you most need them (”if only there was a way to do this” you think, “perhaps by doing…” and you discover this is it!)

But: it does not always work.

I spent a good few minutes trying to stop the icons wobbling on my iPhone after holding my finger down to rearrange them (you stop the wobble by hitting the home button, but that wasn’t the first or second thing I tried).

Worse, I spent a day in Regent Street hunting for replacement earphones because I wanted a remote control.  Luckily I couldn’t find any I liked, because when I got home I discovered that the tiny blob on the headphone cable could be squeezed to remote control the iPhone’s playback (once to play pause, twice for forward, three times for back) and also to take calls (it doubles as a microphone).

It’s a bit like games.  You hide advanced features (the “tricks”) for those who will want them and will look for them, so that essential functionality remains simple, quick to learn, usable.  Just don’t hide them too well!

Our clients for our group project assignment are an organisation who provide information on public transport via a telephone line and a website.  The website has some usability issues and they would like to know what they are and how to make the most urgent improvements on a tight budget.

In fact, it’s not quite as simple as that.  There is a UK wide organisation that runs the front page linking to twelve regional sites.  Each is run by a regional organisation which gathers timetable information from local authorities and transport operators within its area.  Each presents the data and searches in a distinctive way.  There are three different back-ends powering the site, but even sites which share an engine will appear different.

The rationale for doing this makes sense to some extent.  Buses companies are structured regionally, and government is perhaps most directly involved at local government level.  Each regional organisation must liaise with providers within their area to gather data.  Although economies of scale cannot be made (designing and maintaining one system nationally) regional organisations could (theoretically) be more responsive to local needs.  For example, within the London region one can travel by tube; in the South West, say, one cannot.

So why have a national organisation at all?  I can conceive of two answers to this.  Firstly, the desire to have a framework that ensures that all of the UK (mainland) is covered and there is a minimum standard of information provided nationwide.  Secondly, however you cut the country up it will never be possible to do so in such a way that passengers do not wish to cross a border.  The usefulness of a national public transport information service would be limited if a passenger could not, via a single search, get full journey information traveling between any two places (regardless of whether they fall with in the same region).  So the sites must have a means to share data.

From a usability perspective, we now have a problem in terms of how the user is expected to understand this regional model of the site.  It makes sense to me that if I want to travel within Brighton I will go to one site, and if I want to travel within London I will go to another.  (In effect I assume each organisation owns and accesses its own data, in the same way I will go to the Easyjet site to look up Easyjet flights, and the Ryanair site to look up Ryanair flights).  If I want to travel from one to another, it becomes more complicated.  Do I go to the site for the region where I start, or where I finish?  Or does it not matter?

It turns out it doesn’t matter (though it remains an issue so long as the model does not make this apparent to the user). And does it matter if both start and finish lie outside the region of the site I’m using (apparently not).  And if the region of the site doesn’t correspond to the region I’m traveling in, what is it for?  Can I choose one by personal preference?

All this makes the front page of the site terribly confusing.  When you select a region, are you selecting a start point or end point? (No!)  Are you effectively just choosing an interface?  If so, what’s all this about regions then?  You can sense the user becoming more and more puzzled.

Meanwhile, by having distinctive sites, there’s good and bad usability in different places on each.  Diversity might provide choice (if users understand that is what is offered) or it could drive improvement if best practice is shared.  It’s on this last point that we come in, as this, essentially, is the assignment brief.

It keeps coming up. “I’m not a member of the cult of Apple” said the guest lecturer at a seminar today “but…” He waved his hand at the glowing Apple logo on the back of his laptop. The point was made in connection with mood affecting usability, citing Don Norman (Emotion & design: attractive things work better, 2002).

Later a lecturer (who got a new Macbook Pro yesterday) was doing a demo on a PC and pressing the wrong buttons. “The thing about Macs is the command key is in the same place as the alt key on PCs” he yelled “and it really drives me mad. But I love them because they’re so shiny.”

This chimes with me – perhaps not the shiny bit, but the enjoyment. I have a couple of Macs, a couple of iPods and an iPhone. I aspire to own more Apple devices, I enjoy having them and I enjoy interacting with them. I don’t pretend they are without flaws, but the major difference is enjoyment. For recreation I have used Windows 98, Fedora Core 4, OS X and Vista, and I’ve had to use Windows XP at work. There are things I’ve appreciated about each (except Windows 98 which I’ve just come to loathe!) but I always come back to OS X because I just enjoy doing the same tasks more when I’m using it.

There is certainly a cycle. If attractive things are more usable, it is certainly also true that we find usable things attractive. It’s a virtuous circle and its clearly desirable but how do you break into it? Is it purely aesthetics? What else could promote enjoyment and happiness in an interface that goes beyond good design? A sense of fun, humour?

I believe there may also be an element of cockiness too, where the design goes beyond the purely necessary and into “because I can” territory; Apple stuff has a sense of its own cleverness (usually without being smug) where by being one step ahead of you, you are reminded how important you, as the user, are. Rather than good design being invisible it should be apparent; it should remind you that it is responsive and attentive. The seminar today touched on the “media equation” with the example that humans enjoy being flattered by machines just as they do by other humans. So too, I think, do we enjoy being the centre of attention – even if that means our computers do show off to us from time to time…

Where’s the button? In amongst the features of the new MacBook was a new way of interacting with your computer, borrowing a little from the iPhone, the multi-touch trackpad – with no button.

This capture, from apcmag.com shows the default functions when you touch or swipe with two, three or four fingers.

Despite appearances there is a button – you press the whole thing down! – which will make dragging interesting. Engineered accurately, you can imagine that suddenly it will become even easier that using a mouse… when you reach the icon you want drag you simply depress your finger and keep it moving… but it would be easy to do badly (though I have some faith in Apple here!)

It’s also interesting to speculate how a totally buttonless interface device might work. Imagine the trackpad actually isn’t one giant button and you just have the multi-touch interface. How would you select something? (No tapping, I hate that!) Put more fingers down? Circle it? Pinch it?