Consistency when things are poor

Call it a pattern, a heuristic or a rule of thumb. A fundamental one of those to ensuring usability is consistency. This may be external consistency – for something behaves in the software in a similar way elsewhere. A good example might be the ‘x’ button in the top right hand side of an open window. It is universally a call to action to close the window. If the designer created a button labelled “C”, and placed it on the left hand side this would result in confusion. It is not consistent with the users’ expectations from using other applications. The second type of consistency is internal – do things behave in a consistent manner throughout the application? This may be both in behaviours (e.g. buttons with the same titles perform the same action), and in look and feel – a website has a visual identity and coherence, assuring a continuity of experience.

There may be examples of where internal consistency is not possible. For example a brochureware site that uses a third party for fulfilment or payment. Paypal is a good example of this – the user is taken out of the shopping experience and into a paypal experience. This can be successful if there is clear signposting and use of the paypal imagery on the shopping site to assure the user.

So what happens when you have a large, legacy website that you acknowledge to be pretty poor in the usability front and want to introduce new functionality, or want to rebuild it. If you play the consistency card too strongly you may continue to be consistent with the old design and behaviours. This begs the question, is it better to introduce something that is internally inconsistent, but fundamentally better? This becomes even more an issue when you look to rebuilding your site in an incremental fashion.

As an information architect I can help you design your site architecture – the look and feel, navigation structure, user journeys etc., but this will probably be in its entirety. To build this new site will take time, and assumes a “big bang” whereby a completely new site will be (re)launched. Yet there are probably business imperatives to fix specific areas. If we build in an incremental fashion, and take the agile approach of focussing upon delivering business value, we are not going to have a fully redesigned site to go live with. We are probably going to have (for a short while at least), some parts of the site that are new and some that are old.

Going back to my original question, we can either build this to be consistent with the old site, or do something tangentially better. If we do the later it will probably be significantly inconsistent from other parts of the site, or the original parts of the site. It is in this scenario that I am inclined to throw away the consistency pattern. You may have internal inconsistency if you have a clear roadmap to throwing the old and the new functionality / design is proven to be usable, accessible and intuitive. With this the case, the interaction behaviour and visual identity of the new functionality must become the benchmark to which future functionality is consistent with. And you must clearly signpost to the user what is going on; customers will generally be forgiving if they understand that the changes are in their interests.

Missing planes

Reminder to get to the airport on the the right date.  flight is post-midnight

After a month living out of a suitcase, circumnavigating the globe I’m homeward bound. I’m flying with Oasis… going to be interesting how the words “budget” and “longhaul” reconcile with each other. So far the experience is promising, a nice touch with their e-ticket (the date which I have subsequently changed). The plane flies at 00:50. BA fly back from Hong Kong a little earlier; on their e-ticket they don’t make it clear that the flight is a post-midnight one. Last time I did this trip I arrived at the airport on the Sunday night beleiving my flight was late on Sunday. Only it was a few minutes after midnight… on the Monday morning. I’d missed my flight by 24 hours. An easy, and expensive mistake to make. Oasis have gone out of their way to help me not make this mistake.

“Let’s pretend” user testing

How do you test the usability of the software you’ve built?  At one end of the scale you could run full usability tests with a sample of users, given them a scenario and let them loose, trying to realise pre-set goals.  On the other you could do guerrilla usability testing, just grabbing people and informally doing a usability test at your desk.  You could get the experts in to do a usability review.  They’ll typically use a bunch of usability heuristics and provide you with a report critiquing the application against the heuristics.  But what if you don’t have the budget for usability testing, can’t get hold of any representative users, don’t want to wait for some experts report?  How about playing “let’s pretend”?  Remember playing doctors and nurses as a child?  Well do it again, only this time be Users and Computers.  And you’ve got the role of the user.

Create a persona, a pen portrait of your customer.  Think in your mind how they act, behave.  Maybe you know someone like them, seen someone like them in the supermarket.  Now ask yourself some quetions:

How do they behave in their daily interactions with others?
What does their life look like?
What experience do they have with using computers, with using products like yours? How much time have they got? How are they feeling?
Why are they using your product?

Spend a few minutes internalising the persona.

Now turn to your application and imagine you are the persona, using it for the first time.  Give yourself a task to complete (make sure the task is something real that your persona would look to achieve, not a goal you think the application will help him achieve – there is a subtle difference).  Try and forget all you know about the application (easier said then done) and be the novice user.  Walk through the process, speaking aloud (in your head will do).   Focus upon I not “the user”.

I’m looking for this, I’m looking for that.  I do this, I do that”.  I can’t find this; I don’t think that makes sense”

I want to check my balance.  Hmmmm, there are three “balances” here; I’m not a banker, what’s the difference between Running balance and Cleared balance?

I owe my mate some money for the golf holiday, he’s given me his bank account details, I want to transfer some money into his account… huh?  I can’t do that.  What do I do?  Pay a bill?  He’s not really a Bill is he… Etc etc.

You don’t need heuristics for this – many of issues the heuristics would help uncover should come out using this method anyway (speed, ease of navigation, speak users language etc).  If your persona is having difficulty you can probably multiple the usability issues for a real user.

This approach works for a quick and dirty review of an application’s usability.  And if you document your experience make sure you preface it with a description of your approach.  Someone who is close to the development of the application, reading your first person critique, is rightly likely to think you are an arrogant so and so.  I speak from experience.

The customer is not always right

I was recently working with a financial services client, rationalising their systems to have a “single view of the customer”. This demanded a single user interface rather than the 13 or so current UIs that they use in their daily business. As we were coming up with ideas one of the consumers of the new system showed us an old system – “make it look like this” she said, “that’s what we want”.

Example of ugly user interface

My initial reaction to a screen like that is a nervous twitch. Eugchhhhhhhh!! Hold my breath. Count to ten. Repeat the mantra “RANA”. Relax, be Aware, be Non-judgemental, and Allow… RANA, RANA, RANA.


So when a customer asks you for something that in your gut feels wrong; if it feels wrong, it might just be wrong. The challenge is to get the customer to feel your feeling. Do not to just do as the customer says but probe and question and ask why.

This UI was built by developers to manifest data from the database. Not something we wanted to repeat. So we started by asking what is it about that UI that she likes? Some gentle probing uncovers that she likes the ability to have everything in one place. She can rapidly perform searches and see the results in the same place. Taking this as our cue, we probed what information on the screen was important to her and what was not – in the context of her usage. If we took each individual field one by one and asked “is this important”, she would answer “yes”. By asking about frequency of use, criticality and importance we were able to discount most of the fields. At the same time we were able to identify a number of fields that were critical and frequently used, but not displayed on this screen. We soon had a framework for a new search / results screen. Then we broached implementation.

Talk of a browser based solution filled her with fear and loathing. She perceived this to mean having to enter a search criterion, and then wait for the page to refresh / results to return. She’d experienced this with other applications and did not want to go there again. She was pointing at the Fugly screen again. “Build me that” she says, pointing at the screen shot. Yes but….

In an enterprise solution, performance, speed and accuracy are the most important criteria. Yet the Web 1.0 paradigm of query – response via a refreshed page is just not fit for purpose. AJAX overcomes this. She could have her cake an eat it.

The result was nothing like what the customer had asked for. We’d listened to her (and others like her) and probed her on her goals. We used scenarios to talk through the context of usage and came up with something that was fit for purpose and IMHO delighted her. The take away is this. Don’t always believe what the customer says, often they are constrained by their narrow view of the world and their current reality. If we are doing our jobs properly we are opening them up to the art of the possible. To a new reality a world apart.

Off is on in Motorola world

I recently borrowed a motorola flip phone. The first non-Nokia I’ve ever used. I really liked it, once I’d worked out how to switch it on. How intuitive is it to switch the phone on using the red off button? How hard would it to have built the green button to have a call to action for on?

motorola red off / on button

Lotus notes sucks

February 17, 2006, 5:13 pm

The Guardian ran a good article about Lotus notes.

“Imagine a program used by 120 million people, of whom about 119m hate it. Sound unlikely? Yet that’s the perception one garners in trying to discover whether Lotus Notes, IBM’s “groupware” application, is – as readers of Technology blog suggested – the “world’s worst application”.” Good news! They are redesigning it and asking for feedback. So I dutifully went to the IBM feedback form and filled it out. “question 3: blah blah blah. If not skip to question 5. So I skipped to question 5. And when I submitted the form it wouldn’t let me progress until I completed quesiton 4. Doh! There were other blunders in the form. If they can’t get a simple form right…..

4 of 4