interaction design

The customer is not always right

  • Monday, 23 April, 2007
  • By:

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.

OK.

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.

Match the context, not the pattern

  • Tuesday, 17 April, 2007
  • By:
Example of website requesting credit card details in a textual format

To my knowledge, all credit cards present their “valid from” and “expiry dates” as numerical dates, e.g. 02/06 – 02/09. So why do many transactional websites request the credit card validity in text date format, e.g. Feb 06? Most people will not know their credit card details – they arrive at the credit card details form, reach into their wallet, select the relevent card and work through the form referring to the card that they have placed near the keyboard. When they reach the date fields, additional cognitive processing is required, translating the number on the card to a month on the form. This interupts the process (do not assume that everybody can make the immediate leap from 02 to February. Spend time observing consumers on the task and it will not be long before you see fingers coming out to help with the counting).

So whilst using textual dates may be considered to be more “user friendly” and understandable, in the context of completing the credit card form, it adds complexity. UI guidelines, patterns, heuristics are all well and good, but ultimately you must consider the context of usage and design accordingly, even if it does at first glance result in something that is not immediately user friendly.

It is not enough just to deliver software…

  • Tuesday, 3 April, 2007
  • By:

A ward clerk who organised admissions and discharges went sick for a few weeks. In her absence, the nursing staff who took over selected the first options that popped up on the computer screen.  The result was that most patients were entered on the system as both deceased and discharged. [source]

This is inexcusable.  How hard can it be to design an interface for frequently used tasks such as discharging patients or recording them as dead?  Some informal usability testing with novice users would have demonstrated that the UI could not be used by novices.  The mistake is dressed up as a lack of training-  “Patients sent home from a hospital were wrongly recorded as dead when a group of nurses was asked to use a new IT system without receiving appropriate training”.  Training?!  Rubbish.  You shouldn’t need training on a UI designed to check patients in and out.  How difficult can that be?  If they’d invested a little time in usability testing, and designing a usable UI, training, and costly mistakes would be all but eliminated.  But the rush was probably just to get the software out of the door – to meet the functional requirements rather than the contextual and operational needs of the end users and the realities in which software will be used in.

Reflections on QCon

  • Friday, 16 March, 2007
  • By:

Qcon is a “Conference for the Enterprise Software Development Community;” a pretty hardcore techie bunch then. So it was really refreshing to see a whole days track given over to usability and a keynote by Larry Constantine on “Meeting the Usability Challenge”. Last night Martin Fowler and Dan North gave an excellent keynote titled “The Yawning Crevasse of Doom”. Their central theme was around communication between the customer / end user / consumer / business and the developers / IT. Martin drew a great analogy; do you want your communication between the two “sides” to be like a ferry boat or a bridge. Part of the bridge that Martin and Dan talked about was the use of ethnographic research – observing users in their natural environments and storyboards / wireframes / lo-fi prototypes to visually articulate requirements in a way that written requirements can never do. i.e. championing the stuff that I am passionate about, and what we at ThoughtWorks do deliver successful projects.

A couple of other nuggets that are worth sharing; Jeff Sutherland talked about how at Google they don’t have performance appraisals. Instead everyone has personal “three month objectives” that are posted on their blogs (the first thing that a new recruit at Google does apparently is creates a personal web page). In this way people can share with the broader organisation what they are doing. With google search experts and their knowledge can easily be found. Advertising to the organisation what your goals drives performance far more effectively than a sterile quarterly form distributed by HR…

Jim Webber gave an excellent and entertaining presentation on Geurilla SOA. If you get a chance to see him in full opinionated flow, you should seize it. (And I don’t just say that because of his kind words about my presentation, that I’ll upload soon).

At the conference one of the vendors was JavaBlackBelt. They had a multiple choice test on your knowledge of Java. Some of my esteemed colleagues did not fair so well on it; my programming knowledge goes little beyond

10 print “hello world”
20 goto 10

So I am very proud to announce that I came top of the JavaBlackBelt class and won a t-shirt, scoring 3/5 in a little over 40 seconds, a cool 2 minutes faster than the second placed geek. Don’t you just love multiple choice.

Top of class java black belt programmer

When do you need to design a UI?

  • Friday, 23 February, 2007
  • By:

Via Ian Cartwright  an interview with “Lean software gurus” Mary and Tom Poppendieck.  All is going well until  Mary says this:

When do you really need to design a user interface? Oftentimes it drives the whole design, but in fact you don’t really need it until you’re about to do your first alpha test. Before that you can be designing the business layer and you can actually put testing in below the user interface and you can be designing all of the other business logic; you can get that done with any kind of interface and in fact you ca drive testing with a automated interface, and then just before you go to alpha testing you decide what you want for your user interface. Then you take it off and at that point in time you figure it out. But up until that point in time you don’t need that.

This jars with my experience of building compelling customer experiences. There is a good reason why the user interface should drive the whole design because that is how the software is manifest.  To the people whose lives are to be touched by the software, the users, the consumers, the interface is the software.  To leave the UI till last presents a  huge risk of building software that is functionally rich but has a UI modelled around the features; the underlying data and logic rather than how the user wants to work.

Starting with the UI is an excellent way of capturing and communicating requirements.  And bakes in usability into the design.  You want this feature and that feature?  Great.  But will they be coherent and usable to the user?  Drawing out a UI  on paper – paper prototyping- is far more efficient that making assumptions about requirements on a list.  Afterall, isn’t this what the manufacturing industry that the Poppendiecks take thier inspiration from?  Don’t the car manufacturers start with CAD and move onto clay models?  Ergonomists have a hand in the design of car interiors, using anthropometrics to build in comfort and work out lines of sight.  The engineers don’t build the engine and the bodywork and then make decisions about how the car will look.  These things are designed from the start.  And so should it be with software.

When do you really need to design a user interface? It should be the first thing that you do.

Have you considered the consumer mind?

  • Thursday, 22 February, 2007
  • By:

Some things that the development community take for granted as “bleedin’ obvious” are often far from it for the end consumer.

Cue a story.

I’ll protect his identity and call him Jack. Jack is 60 and has been using the internet for a while; He’s got broadband; he banks on line, buys books on Amazon, books cheap flights with easyjet and sold his car on eBay. He considers himself internet savvy.

Not so long ago a friend castigated Jack for using Internet Explorer as his browser, and downloaded Firefox for him. Jack loved the tabbed browsing. Jack was a happy chappy.

When I was in Hong Kong, Jack thought it would be good opportunity to try out the web camera he had never used. He had Instant Messenger, and pinged me asking me if we could have a video chat. We tried to connect but couldn’t. Messenger told me he had an old version of IM and should upgrade. Jack said he thought he’d already done this – I sent him the URL and left him to it. Five minutes later he pinged me that he’d installed the new version of IM. Great I thought. I tried to connect and got the same error message – Jack was still using an old version of IM. Maybe he needed to shut down his machine… Jack disappeared for a couple of minutes and came back on line. Still the old version. Hmmm. I asked Jack to try installing it again. He came back proud of definitely having definitely installed it. We tried to start a video call:

The Video Call failed because jack is using a version of Messenger that does not support this feature.

Hmmmmm.

So we went through all the steps that Jack was going through. It transpired that Jack was saving the file, but there was no call to action to actually launch it.

Firefox save dialog box

And there on Jacks desktop were eight saved versions of msgr8.exe.

Jack often wondered what these files on his desktop were, but assumed they were important (he hadn’t put them there, the system had) and didn’t want to open them, let alone delete them.

Was Jack’s mistake such a big one; to assume that “saving” a downloaded application was the same as installing it? In developer mind, probably. But in consumer mind? Clearly not.

We talk a lot about beginner mind / expert mind, shu ha ri… But thinking about Jack, there is another mind that needs to be considered. Consumer mind. Expert in the things I do everyday, clueless in anything beyond my immediate sphere of need or want.

The Total Experience

  • Thursday, 15 February, 2007
  • By:

The customer experience doesn’t start on the home page and finish on the payment confirmation page. A compelling customer experience comprises of a number of factors with the different factors residing in, and owned by different parts of the business. This can result in parts of the experience being excellent, others being shocking, such as at the Early Learning Centre. Projects that are driven forward by “IT” rarely see the bigger picture; the project manager’s primary concern is with delivery. And this means producing a product that covers all the use cases or stories that were specified in the plan. Agile development practices often reinforce this; an agile team is (rightly) focussed upon delivering technical excellence according to the “customer’s” requirements. The trouble with this is that project success in the on-line world goes beyond just delivering working software. Success is all about the total experience.

I’m sure there are a hundred and one different frameworks for “e” success. The following works pretty well for me.

The Total Experience Model. Copyright Marc McNeill!

Compelling proposition
Any on-line offering starts with its proposition; what it is offering to the market place. Do we know who the consumers are (segment), how many of them are (market size) and their propensity to buy? What is going to attract them to the site, and what is the glue that will draw them back.

Findability
Well if no one can find your compelling proposition it’s never going to make you money. Do you have a strategy in place for ensuring consumers can find your proposition? This starts with search engine optimisation, but will extend to affiliate programs and making a noise about you (Product team blogging?). And then when they are at your site is navigation intuitive? Is relevant and wanted content findable?
Personality
What is the product aesthetic, what does it look like? Is it branded? Does it exhibit production values that reinforce the brand? How does the overall experience make me feel – how does it emotionally engage me?

Content
Content is king. But all too often it is a bit of an afterthought. It’s not just syndicated content, or articles that subject matter experts might write, it is all the copy, the words that appear on the site. Do they support the proposition, or are they just placeholders that the developers wrote and never got updated? Related to content, and maybe it should have a bubble unto itself is community. I think that increasingly, successful eCommerce offerings will include an element of community. Fulfilling the promise of the ClueTrain manifesto from several years back?

Technical Excellence
Working for a company that undoubtedly employs some of the finest developers in the market place, this is something I see a lot of. But it means nothing if the other elements are not realised. Technical excellence includes those “non functional requirements” that development projects talk about; reliability, performance, scalability etc etc.

Usability
Learnable, speaks the user language, memorable, all those old chestnuts. Probably the maxim is “don’t make me think”. Aligned to usability is accessibility; we don’t want to exclude potential consumers through sloppy implementation.

Operational excellence
So the on-line experience may be compelling, but what happens then. Is the fulfilment channel fulfilling? Is there a promise to deliver goods and is the promised delivered upon? What about support channels? Do they support or do they just pay lip service to the concept? Does the web experience go beyond the web and cross other channels? Can consumers start a journey on the website and seamlessly conclude the experience in store? My blogs on Early Learning Centre, Norwich Union and a seamless experience all touch on operational excellence.

Test – measure – refine
Underpinning these factors is the need to constantly test what we do. We can all learn from Test Driven Development (TDD); write the test first and only have the confidence to proceed when it passes. How do we know it has passed? Well we need to measure it; we can only know success if we can quantify it. Based upon the feedback we refine; test – measure – refine, a concept core to agile software development practices.

A lot of words and a picture that belie a simple concept. When working in the web world, always think about the total experience. Break out of your silo (be it technical development or marketing strategy) and think holistically. What will the end to end experience be for your consumers? A technically excellent website is not success. A polished, well branded look and feel is not success. Success is compelling total experience.

What if it began with UAT? (Agile and interaction design are compatible!)

  • Thursday, 1 February, 2007
  • By:

There’s an argument brewing that pitches the agile community against the interaction design community. (You get a feel for this here via here ). Personally I don’t get it. The two approaches are a natural fit. You just need a bit of pragmatism and an ability to say “it depends”.

The interaction designers argue for ethnographic research, lots of user research, and only when we have a thorough understanding of the users, their goals and the context of their usage should we start thinking about writing code. The agile developers will say the only thing that is worthwhile is “working software”. Get something out there, quickly, and see what the users think. The agile approach mean that the direction of the software can be changed at the drop of a hat… If you are working in an investment bank, with a small user base who want this approach may be valid. But if you are building a large public facing web site, diving straight into code with little consideration of the users (e.g. their demographics, itentions, motivations etc.) would seem to be somewhat misguided. It need not be like this. At ThoughtWorks we start many engagements with a “QuickStart”. We’ll work with the client to produce a vision of where they want to get to. We’ll listen to end users, sit with them, watch them. Then use models; financial, process and visual to gain concensus and understanding of what the project is aiming to achieve. We do this quickly, focussing upon the outcomes the client are looking for the project deliver.

The visual models are straight out of the interaction designers tool kit: wireframes. Pen and ink sketches of screens, maybe on paper, maybe in PowerPoint or Visio. Alongside this we’ll watch the users, spend time with them and experience how the software will impact their lives. This doesn’t take much time. We don’t look to produce formal documentation – output is scribbled on cards or on flipchart paper stuck on the walls. In two to four weeks we’ve got a good understanding of the as-is situation, and produced a vision of where we want to get to. The benefits of this? The users get a feel for what might be in the application, we can write better stories (requirements) that are more explicit on what is needed and the developers have something more concrete to estimate against. Finally, when it comes to release planning we can visualise what a cut down version of the application might look like (and thus begin to manage expectations that they are not going to get everything in one big bang, and that things will probably change during the journey). This is not big up front design. It is quick and dirty. It is interaction design (e.g. personas, ethnography, low fidelity prototyping, user testing etc) and agile (e.g. rapid, iterative, incremental, tangible… hey! it’s test driven development without code).

Ah! Test driven development? So on my current project we showcased the wireframes and a comment came back from one of the users (someone who will actually use the application, not one of the “business representatives driving requirements).

“What you guys are doing is great,” he said. “UAT at the beginning”.

I rather like this, but with a caveat. All to often the first time the users see an application is when it comes to user acceptance testing- UAT. UAT has always struck me as a bit weird because it is rarely about “acceptance” (even weirder how it is so well embedded in the IT development lifecycle whilst usability testing rarely gets a look in). It is more about testing for bugs that the developers may have missed. It’s not whether I, as a user “accept” that the product is any good. It is probably the first time I’ve seen it. Maybe I’ve got a test script to run through, I can play with the application, but it is so late in the lifecycle that if I don’t “accept” that it is any good, nothing is going to change.

Agile proponents will argue that with small, regular drops, users are able to raise concerns earlier in the software lifecycle. Regular showcases at the end of each iteration will bring to light issues around “acceptability” and acceptance of the software. But these showcases are usually with the “super user”, the “customer” who is feeding the team requirements. Rarely is it the little person who will actually use their application. And then, even in agile, you’ll often have UAT. It will come at the end of a number of iterations, before the first “release”. But already the direction of the application is set. There is less to accept (and therefore it is easier for the direction of the development to change – one of the benefits of agile) but there is still scope for users to dislike and reject what is being released. And that is why doing UAT at the beginning, user acceptability testing, rapidly, user the interaction designers toolkit is such a good thing. You’re getting the users involved. Your testing and refining the vision. And probably getting usability in there by stealth.

Here’s a paper I wrote about this a while ago: Agile and Interaction design paper

  • Tuesday, 30 January, 2007
  • By:

When I was 16 I worked in a bank. Customers would ring up and ask for their account balance and I type on the green screen 809 for a simple balance. I can’t remember the code for a breakdown of transactions. I couldn’t use that system now. One of the benefits of command line prompts is that they are efficient. As a “power user” it would be difficult for a GUI to beat <809 account number>. Because the GUI can be cumbersome and requires mouse movement when only a few keystrokes would suffice. Power users love commands line prompts. But in the hands of a novice the command line is useless.

Cue Google.

google calendar

A pretty cool feature in Google calendar- the ability to “quick add” an event. Rather than the cumbersome use of date pickers and fields and boxes, the quick add function allows me to create a calendar entry using natural language. I type “meet Fred in the office at 9 tomorrow” (the language I use when describing my intention) and the meeting is set up. No need for fields and boxes and date pickers. So maybe it is time to rethink command line prompts using natural language with forgiving rules. Imagine being able to type “move £50 from my current account to my savings account” rather than the more usual current:

Page 1 – Step 1. Select from account. (Wait)
Page 2 – Step 2. Select to account. (Wait)
Page 3 – Step 3. Enter amount. (Wait)
Page 4 – Step 4. Confirm transaction. (Wait)

(Done).

5 of 8
12345678