interaction design

Would you humanise a hammer?

  • Monday, 29 January, 2007
  • By:

User. Male. 57. Bank customer. Usability test of bank website. “I hate computers. Why are they so damned difficult. They’re supposed to be so clever, and yet half the time I’m left clueless what to do next”.

Interaction designer: Humanise the interface. Speak the users language; be intentional not instructional. “I want to move money to another account” not “Transfer funds”.

Developer: “Bah humbug”. (Well he didn’t really say that. What he did say was…) “Would you humanise a hammer?” “I want to tell the computer what to do”. (I suppose you’d like a command line prompt then). “I don’t what the computer to tell me what I already know what to do”.

Moral of the story: you are not the user. What you want, how you do it and the way you (and also the person who is commisioning you to write your code) do it is almost certainly not the way the end user wants to do it. And unless you speak to them and watch them you will never know.

Are you being told the truth?

  • Thursday, 25 January, 2007
  • By:

I’ve spent the last two weeks listening to users, understanding their requirements, drawing boxes and arrows, swim lanes and all that good stuff to show process flows. But is what they say the whole truth?

When we are doing analysis we are building our own mental model of the work, and potential solutions to problems we are hearing. But unless we can see what is going on, how grounded in reality will our solutions be? Anyone who has sat in on focus groups and observed consumer reality will know that what people say and what they do are often at odds with each other.

Finally this morning I had access to the users in their “real” environment. The user sat at his desk in front of his monitors and I sat slightly behind and aside him, watching over his shoulder what he did. Half an hour’s observation brought the boxes and arrows to life. More importantly, it highlighted how long he spent on each task, and the need for efficiency in the interface we are developing.

In a workshop he can ask for stuff, but when you see him working it is clear that that stuff would just clutter and get in the way of him accomplishing his goals.

Most striking is what is left out of the process discussions. Sometimes we forget about those things that are so obvious, so mundane. We assume that they just happen. Only by observing can you get a real feel for the requirements (and also how they should be prioritised).

So go on, take a half an hour break from your development activities and go and watch the users working “in the field”. You never know, you might just learn something.

What is your UI debt?

  • Monday, 15 January, 2007
  • By:

When developers are up against tight deadlines they introduce the concept of “technical debt”. It is a short cut to delivery; quick and dirty code that will have to be refactored (or fixed) at a later date. Inevitably they will pay the price in the future if this is not done.

So why does no one talk about “UI debt?” When projects are up against tight deadlines and scissors are applied to scope, the first thing that the team will look to cutting are any UI “bells and whistles”. They don’t talk about UI debt – we’ll have to refactor (or fix) the UI at a later date. Yet the price to be paid for UI debt will inevitably be far greater than any technical debt. If the UI is hard to use, and satisfies the technical functionality, not user goals, the users are more likely to shun the software. And isn’t the object of software for people to use it?

Consumer driven development

  • Wednesday, 10 January, 2007
  • By:

One of the things that makes me passionate about agile is the way that it places the customer at the heart of everything we do. The trouble is “the customer” is often wrong. For me, the customer is the person whose life is transformed by the software they use. This is not the person who is writing the cheque, nor is it the person who is defining the requirement. In consultancy speak, they are the client. The “users” are the customer. I don’t like the use of the word “user” because it implies a choice to use the software has already been made. I’m probably going to have to accept that “customer” is never going to change, so why don’t we call our users (my customers) “consumers”.

So enough about semantics. The team are building an on-line banking product. The team ask the customer (client) what she wants. She bases her requirement around what she knows. Often this will be swayed by the development team talking about implementation detail. (Few things make me as uncomfortable as a customer (client) from the business (product owner) talking about APIs).

So the requirement is to log-in. The customer is comfortable with customers (consumers) having system IDs; a unique n digit number that identifies the customer on the legacy database. It has, after all, always been this way. She asks whether the customer’s credit card number could be used, but the developers tell her (via the BA) that these often change (customers loose their cards) and it would be hard to do. She nods her head in agreement (she’s put on the spot by the BA – the iteration is due to start next week…) And the requirement is manifest on the login screen (“please enter your 16 digit customer number”).

In reality, the “customer” bases the requirement on her experience with the organisation and what she knows about it. The consumer (if they were to be invited into the conversation) wouldn’t come to the problem with any of that baggage. She needs a simple login. She needs a user name that is accessible or memorable. She does not want a 16 digit number.

It may take a little longer to listen to the consumers’ need (we need to find consumers to talk to them). It may mean a little up front analysis (I’d suggest pre-project analysis, doing due-diligence if you like). But it will pay dividends downstream. In the login example above, the developers have swayed a simple and cost-effective solution in the short term, but have failed to consider the down-stream costs. How will the customer find their 16 digit number? Do we have to post it out (cost) on a card (cost) and have a support team (cost) and process (cost) for letting customers know their number if they’ve forgotten it?

As agile grows up, I’d ask for us to spend more time thinking about the real customer, the consumer, the person whose life will be changed by what we build. The inconvenience we may incur during development may be nothing compared to the pain we will experience after we have “delivered”.

Storyboarding with comics

  • Monday, 8 January, 2007
  • By:

Storyboarding is a really powerful way of communicating how a tool will work. The Sun design team have put together some cartoons that can be used for presenting storyboards; for example taking a bunch of wireframes and using the cartoons to tell the story through them. The cartoons are in powerpoint here. I’m looking forward to using these, to ditching the dry persona description and annotations and replacing them with a more compelling cartoon journey…

Blue is the colour. The website isn’t the game.

  • Thursday, 4 January, 2007
  • By:

So I may support Chelsea on the pitch, but on their website? Oh dear me. It’s as though they got someone who has just learnt flash to build it – to use as many flash animations as possible. And any website designer that incorporates a link on their splash page (why oh why a splash page) that says “check out the site demo” and a first message “learn how to navigate through ChelseaFC.com” needs to be questioned. Learn how to navigate a web site? Oh please!

The nature of football fans is their brand loyalty, but to give them something that visibly takes time to load (page loading status bar), requires instructions to learn how to use, and doesn’t make things easy – support me achieve my goals – is frankly insulting.

Oh, and they’ve got a text only version (the CFC Flash website isn’t going to win awards for accesibility so one can only presume this is the only reason it is provided) but the splashpage requires JavaScript to load up, so no JS and no website, regardless of any text-only goodness that may be there. So not an accesible website then.
Meanwhile the community stuff that supporters care about (beyond the news and match reports, it’s probably going to be the most sticky content) is a seperate site that looks like it was built in the early days of the web. I mean, who uses frames anymore.

Sorry Chels, poor show. Your league status doesn’t extend to your on-line prescence.

What’s the value in changing colour?

  • Thursday, 14 December, 2006
  • By:

As a registered user, I want to change the colour scheme on the web site so that…

Where’s the value in this story? Agile focuses upon business value, and in doing so it commoditise features. The sponsors of the development are invited to prioritise features based on their “business value”. This means that seemingly pointless gimmicks will slip out. And this may impact the overall experience that the sponsors strive for. Yet by commoditising features the sponsor sees how the costs break down. To have functionality that changes the colour of the site will require effort. It’s not going to come for free. And that means that either scope will increase resulting in either increased cost or increased time. The challenge is when you have a sponsor who knows just a little: “changing colour? Pah! That’s a bit of JavaScript and changes to the stylesheet. I could get the code on hotscripts and knock it up in front of the telly tonight…”

And of the requirement to change colour on a site, in fact that whole customisation thing? Until recently I’ve never seen the value of it. After all, how many people have you seen with a personalised theme on their windows desktop, or even just changing the desktop background? One reason people don’t do this is because they are lazy. The call to action to change it is hidden behind a right click, and it’s not exactly straight forward to do. But there’s a bunch of new sites that challenge the user’s laziness. These seemingly pointless customisation features are part of the overall experience. And they work. And by doing that, they add value to the site.

Don’t say UCD is incompatible with agile

  • Wednesday, 13 December, 2006
  • By:

Consultancy is great, you get to see lots of different problems that different organisations and people have. You get to apply the learning’s built up through experience to help solve problems, and sometimes help organisations realise opportunities that they may not have realised possible.

I was recently working with a new client and sat through a presentation by an agile coach from a different consultancy on what agile is. It was great to hear a different slant on the agile proposition and how it delivers business benefit early and regularly. The presenter really honed in on human behaviour. She was suggesting that despite our best efforts and beliefs otherwise, human behaviour is fundamentally unpredictable. The best plans in the world are held hostage by human behaviour…

At the end of her presentation there were a number of great questions from folk more happy in the waterfall space. People who have seen agile and it’s like before – RAD, DSDM etc etc, “yeah, yeah, heard it all before. Agile’s just another passing fad. Then one of the HCI guys asked the question: “in what you have said, it sounds like you would have little time for doing low-fidelity or paper prototypes; a fundamental tool in the interaction designers arsenal of techniques to ensure usability (and acceptability) in design”.

To give her credit, the presenter explained that agile practices are by nature pragmatic and there may be instances where such prototypes may be valid, but in principle she suggested that they should be eschewed.

Something bothers me here. We are quite happy to “spike” technical problems, but possibly the most important part of any software implementation, the user interface, we are happy to let emerge according to the developers’ preference? For it to be refined following feedback from each showcase? What if we call the lo-fi prototype, the wireframes a “spike”. Does that make it acceptable to the agile zealots? What if rather than writing code, testing and refining it, we draw storyboards, test and refine them? Get the UI right quickly and cheaply before a line of (costly) code needs to be developed. It helps you to have a shared vision of how the application will be manifest to the customer. It helps you to show what they will be getting in an iteration, what the goal is for a release.

To say that user-centred design is incompatible with agile (which was certainly the impression the presenter left the UI team I was working with) is nonsense. Which reminds me. I’m supposed to be writing a paper to this effect.

Working software that doesn’t work

  • Monday, 11 December, 2006
  • By:

Seen recently.  A developer at a broadband provider proudly showcasing functionality that enables customer to perform fault diagnosis on their connection.  Step one “do you have access to the internet?”  Functionally it might work, but did no-one stop to think about the value of this functionality.  You need an internet connection to get it to work…

The agile manifesto champions working software over comprehensive documentation.  Working software does not just mean that it functionally works, to work it must also provide business value and a compelling customer experience.

Human Computer Experience

  • Sunday, 10 December, 2006
  • By:

HCI.  Human Computer Interaction.  Whilst I’m an HCI practitioner, it’s an acronym I feel uncomfortable with.  It is a discipline grounded in task-based activities with its roots in organisational computing.  Now that computers are ‘ubiquitous,’ task based analyses of the way that people interact with technology are insufficient. HCI needs to borrow from anthropology, graphic design, sociology, visual arts, to more beyond the “task” to the “experience”.  Human Computer Experience (HCE) anyone?

6 of 8
12345678