dancingmango

I’m in Hong Kong in a workshop and we are asking the group to think beyond what they do today. To come up with a “blue sky” vision of what they want from an application.

“Urrrr, excuse me” says one of the team, “what is a blue sky?”

Earlier on, one of the team had talked about “motherhood and apple pie”. Urrrrr. What is that?

Another workshop, “We are interested in how you do things, soup to nuts”. Uurrrr, nuts? Who ends their meal with nuts. If that is what you are trying to say…

On agile projects we talk to customers and soon start talking about “stories”. Urrrr, aren’t stories something I read my daughter at bedtime
We assume that people will understand what “stories” are. They nod their heads in agreement, but do they really understand what we are talking about.?They’re requirements right? If calling them requirements makes communicating with your customers easier, then isn’t it better to use the words they are comfortable with?

When you do a retrospective (urrrr, what’s that? you mean review of how we got on?) how about spending a couple of minutes reviewing the language you have talked to your customers in. Have you spoken their language, or talked at them in your own? Have you communicated in plain English or have you been wallowing in bullshit bingo land.

Oh, and if I’m on a language theme, when you go into Starbucks it is “can I please have a cup of coffee”, not “Can I get a coffee”…

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.

Seen on the New York subway.  Is the “won’t you” really necessary?  The tone of the notice is trying to be friendly, but surely when you are writing signs or labels it is better to be concise and to the point. Afterall, it’s a sign, not conversation.

Heard on a suburban comuter train going into London, a pre-recorded generated message.  “London Underground inform me that there are currently no delays on the system”.

“Inform me?”

The “me” is a recording.  Again, the tone is trying to be friendly, but it is not real.

When communicating to customers use a style that is appropriate to the media.  If it is impersonal information you are providing, be concise and unless it is coming from the mouth of a human in real time, don’t try to fool me that it is otherwise.

Conventional approaches to building software applications start with a Big Idea. Someone needs (to define an application) “a program that gives a computer instructions that provide the user with tools to accomplish a task“.

Someone picks up the big idea and breaks it down into a smaller list of “requirements”, things that the application must do to fulfil the Big Idea. In conventional waterfall development Business Analysts will spend a while documenting the list of requirements in some detail - in agile approaches they will do it as they go in a far more “lightweight” manner. Maybe a technical architect will draw up a blueprint design of the solution. Regardless, soon the developers will start writing code. With either agile or waterfall the user interface usually only starts to emerge at this stage. Until then, everything is coded in words (and maybe some boxes and arrows showing flow).  Only late in the process does the UI emerge.

Returning to that definition of an application, IT development seems to spend most of its time in the “a program that gives a computer instructions” world, and often looses sight of “provid[ing] the user with tools to accomplish a task”.

How about a different focus. Start with the user interface. Take the Big Idea and illustrate it. Draw pictures of what the tools will look like, how the user will interact with them. Sketch storyboards, wireframes, lo-fi prototypes, paper mock-ups, call them what you will. Use this as the primary requirements document, supported by explanatory text and detail where we required. These may be stories or use cases, but let the visual representation of the big idea drive the requirements rather than it being almost an afterthought.  Start with the UI and specify the functionality from that rather than the other way round.  After all, it will be the UI that the user uses to accomplish their task, not the computer instructions.

New York.  Went to the Apple store last night with the intention of buying a MacBook.  The Apple retail experience is pretty cool, lots of space, Macs and ipods to play with, sales people in the background - letting the Apple products sell themselves, being available to answer specific questions and take orders.

And then cold feet.  I’ve been taken in by the hype.  Do I really need a new MacBook?  It would be for work and work already provide me with a reasonably decent Dell laptop. Can I really justify the $1200 outlay (even though it is cheaper than in the UK?  And there’s a thing that bugs me about the retail experience in the UK.  Lack of pricing transparency.  The ticket says one thing, but then you’ve got to add the sales tax.  In the UK, unless you are buying in the B2B space the price you see is the price you pay).  And my final decision was no.  I can’t really justify it.  So instead I’m going to give Ubuntu another go and try and have the best of both worlds, a cool operating system on my old Dell machine.

Friday evening, the train is pulling into East Croydon railway station. There’s an announcement.

We are now approaching East Croydon, please mind the gap between the train and the platform. Don’t leave any of your belongings behind…

The usual scripted stuff. Then…

Hey! I’ve just realised its Friday! The Weekend is here.

People on the carriage look up. Did he really say something, that’s something that breaks the mundane monotony of the commute.

Remember folks, drink sensibly!

I looked around and people on the carriage were smiling. An unscripted, personal touch. It wasn’t a canned message from an anodyne voice. For a brief moment South Eastern Railways became really human. It made commuters smile. And commuters travelling into East Croydon rarely have anything to smile at.

There is more to Customer Experience than homogeneity and consistency in interactions. It is more than scripting customer contacts. It is more than sheepishly adhering to the corporate line. It is about empowering employees to have the confidence to be human. It is giving employees some degrees of freedom to do things differently if it is in the interest of the customer. To be spontaneous.

There’s the story of the Ritz-Carlton bell boys being given a budget to help customers. To be spontaneous without having to jump through hoops of approval. No “I’m not really sure, wait a minute and I’ll ask my supervisor (because even though I’m grown-up enough to want to help you the Rules by which I’m employed don’t let me)”.

Maybe I’m getting a bit carried away. But customers remember these human touches. And if they have the seed of a positive emotion planted in their memory, an emotion associated with your brand, you have the seed to grow lifetime value.

Anthony Bourdin in Kitchen Confidential writes “Good food is very often, even most often, simple food.  Some of the best cuisine in the world… is a matter of three or four ingredients.  Just make sure they’re good ingredients, and then garnish them.  How hard is that?”

How hard is that indeed.  There’s a lesson there for building out your product set.  Are you doing the simple stuff well?

Another meeting, another executive talks about the need for innovation and creative thinking and pushing the boat out and beating competitors with something new.  Meanwhile, doing the the simple “hygiene” things that will delight existing customers (reducing customer attition and churn) get lost with the innovation hyperbole foccused on “capturing market share”.