Are you being told the truth?

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.

Is yours a free coffee organisation?

coffee machine on free vend

What kind of employee experience do you have? A good customer experience is going to be an extension of a good employee experience. If I feel good about my employer, I am more likely to be a brand ambassador for them. So how do you improve my employee experience? Well there’s all the usual stuff, benefits and bonusses, but the little things are just important. Like the coffee machine.

There seem to be six different approaches to enterprise coffee:

1. Vending machine that serves [quality] coffee on free vend.

2. Kettle and filter coffee / Cafetiere to make my own.

These two make me feel good about the organisation

3. Kettle. I buy my own instant coffee. Usually associated with SMEs rather than corporates.

Not so good. but better than…

4. Vending machine that serves [quality] coffee that I have to pay for.

I have never seen this. Organisations who know coffee don’t charge their people for it.  These vending machines are always on free vend.  As in above photo.

5. Vending machine that serves [tasteless] cofee that I insert coins into.

6. Vending machine that serves [tasteless] coffee that I insert a vending card into.

This final one insults me as an employee. I’ve got to “charge” my card up. I’ve got to get a card. My coffee consumption can be tracked. More often than not the same machine serves water (because these organisations don’t have water coolers). And the water tastes like tea that tastes like soup that tastes like hot chocolate that tastes like every other concetrated liquid that is squirted into a brown plastic cup.
How much more can it cost to offer free coffee? How much are you saving by doing so? Because tasteless vending machine coffee is a sure way to send your staff out of the office on regular errands to Starbucks.

Is your IT department like the NHS?

Can Gerry Robinson Fix The NHS? has been compelling TV viewing the last few nights. The thing that really comes across is the lethargy and the inablility to take responsibility to get things done. The two messages that resonate with me are listen to people on the ground and “just do it”. CEOs may chuckle at such incompetence in the public sector but how often are these issues manifest in the corporate world, and in IT organisations in particular. IT is full of reasons why not:

“You may be able to do xyz in Ruby on Rails, and it may only take you two weeks to complete (compared to the six month project we’d take to do it) but we just don’t (and won’t) support anything that’s not on our architecture roadmap…”

“You can’t do abc until we’ve completed our infrastructure refresh project.”

And how often is interviewing / listening to end users on an IT project plan?

Success is more than just features

All too often there is an assumption that we can deliver a bunch of features and they will provide a benefit to the customer. A simple model and it underlies much of what agile is perceived to be about. Deliver those features that provide greatest (business) benefit at the earliest opportunity.

Features leads to benefits

It is worth looking at the updated DeLone and McLean model for Information Systems (IS) success [pdf]. This is a causal model; if you want to accrue benefits with a system it is not sufficient just to deliver “features”. There are qualities that must be realised; these will drive an intention to use and actually use the application. This is tightly correlated with satisfaction, use will precede satisfaction, but if the outcome is satisfaction then use will increase and this is the ultimate test of how beneficial a system is.

DeLone and McLean model for IS success.  Slightly modified.

So taking the “qualities” one by one:

System quality: e.g. reliability, usability, performance, availability, accessibility
Information quality: e.g. usefulness, personalisation, speaking the user’s language, keywords, search terms
Service quality: the overall experience, interface design, emotional impact, trust, security, support

Typically development teams may consider some system quality attributes as “non-functional requirements” but these are generally from a technical perspective (e.g. availability) rather than a human perspective (e.g. usability). Probably this is because this is the language that development teams understand.

Information quality is usually left to someone else, someone from the business, from marketing, to write the copy for example. On the web, where most customer experiences start with search so getting copy right is essential to ensure search engine optimisation. On pages that are not content managed, pages that the developers are coding have meta-tags been identified? Has copy been written with targeted keywords in mind, keywords at the beginning of the page, with repeated use of the keywords etc?

Service quality is something that everybody assumes will be manifest but is rarely explicitly stated as a measurable component. I recently worked with a client that wanted to offer “world class” services. What did this mean? Asking them resulted in different things to different parties. The DeLone and McLean is a little light on “service quality”. Depending upon the application, it is something that looks and feels good, and makes me feel good using it. It is something that delivers a complete and holistic experience from the first point of contact (e.g. hitting the home page) through to realising my goal (e.g. correct products ordered arrive at promised time).

These qualities have a causal impact on use and user satisfaction. These can be measured (e.g. usage patterns/ repeat usage/ surveys) and should be incorporated into the non-functional requirements at the outset of the development.

Get all this right and you will realise net benefits from the project.

Going pre-technical

Developers who no longer code refer to themselves as going “post-technical”.  I’m never sure if this is a badge of honour or not.  For someone who is pretty non-technical, I am delighted to announce that I’ve gone “pre-technical”.  I’ve got an apache web server running on my local machine with a mySQL server all courtesy of the delightfully simple Apache Friends XAMPP.  In only a few minutes I had it up and running (and after an internet basics 101 with Dan North) and a couple of clicks I’d installed WordPress on my laptop.   I can now play around with different designs and start making this website exhibit the sort of production values that I strive for with clients. 

What’s the value in changing colour?

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

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.

Human Computer Experience

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?

Cack-handed speed boat

A colleague did Luke Hohnann’ s speedboat exercise last night.  The way she drew it looked a little different to the way I draw it.

Picture a speed boat.  Now attach some anchors that are holding it back.  Which direction is the boat heading?

The boat is on the left, (travelling from right to left) and the anchor is on the right?

You are right handed.  For us special people, the left handed amoungst us, we draw the boat on the right and the anchort on the left.  That’s because we think quicker and better at performing complicated jobs.

Pictures and narative

Every night I try to get home in time to read my daughter a bed time story. Currently her favourite is Cinderella. The story is short, it could easily be fit onto one sheet of A4 paper (the plot in Wikipedia is just under 800 words). I could even decompose it down to a number of bullet points to fit into a couple pf PowerPoint slides. Somehow I doubt this would engage my daughter. I read Cinderella from a picture book. There are only a few words on each page, I read those whilst she looks at the illustrations. It is from these pictures that her imagination is fired. They bring my words of princesses and castles and fairy godmothers and balls to life.

Similarly when building new propositions, I’m much more interested in drawing pictures that articulate the user journey story. But this blog entry is not so much about pictures to articulate the process of building products. It’s about PowerPoint.

I have a bit of reputation as a PowerPoint monkey. Whilst our developers build code, I spend a lot of time building presentations on how they will do it. All to often I see slides that have been crammed full of words. There is often an unwritten rule that considers 20 slides to be a maximum number in a presentation. The rationale? An hour long presentation, say three minutes per slide and pow! Time up!

First slide title “Background”. A dozen bullet points on the history of the project.

This is like telling Cinderella from an A4 sheet.

I’ve been inspired by the Lessing method; tearing up the 20 slide convention. A PowerPoint presentation should be like telling a story. Just like the picture book of Cinderella engages my daughter and her imagination with pictures, the words being a cue for the narrative, so a successful presentation should have a narrative, supported by images and carefully chosen points. And if that means a slide deck with 100 slides so be it. Take a look at Dick Hardt doing this for real. Awesome!

8 of 13