Work

Blue sky apple pie

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”… 🙂

“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.

Apple in the Big Apple

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.

Humanising the corporate voice

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.

Are you doing the simple things well?

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”.

Is a Singapore Sling at Raffles a cliché?

Singapore Sling at Raffles

I used to consider myself a travel snob. Certainly not a tourist and even back-backing was beneath me. I went for the authentic experience; small holdall with only the bare necessities, travelling and staying with the locals, keeping off the beaten track. So when I was in Singapore recently the question of whether to go to Raffles for a Singapore Sling agonised me. My old self would have shuddered at the idea. What a tourist cliché! I’d find a smoky café in the Arab area and drink thick coffee and puff on a hookah. What is worse, I’d preach against any way but my way- if you’d been to Singapore and stayed at Raffles you hadn’t really been to Singapore. Unless you’d eaten from street stalls and slept under a fan you were just a (spit) tourist.

But I’m in Singapore on business and I’m older and wiser and I hit the Long Bar in Raffles and like almost everyone else, I do the tourist thing and order the Sling. And the experience was appropriate to my circumstances.

Sometimes I wonder if this snobbery rears its head in my professional world. We choose Firefox over IE, Ubuntu over Vista, agile over waterfall. Ruby on Rails is our passion, anything else is just beneath us. Commercial success is to be looked down upon; “selling out.” Bob Dylan sold out when he went electric, right! There’s a thin line between passion, pragmatism and snobbery. The thing is to know the set, setting and circumstances. Who are you working with, what’s the context and why are you there. Keep those questions in mind and the appropriate level of snobbery you may revel in should become clear.

Software Dams and recipient participation

There once was a time that international development was all about big capital projects, building dams and the likes. Times change, now the focus is on eliminating poverty; DFID “focus [their] aid on the poorest countries and those most in need”. There is a realisation that those big projects did very little to address poverty, indeed they kept countries poor forcing them into debt (read Confessions of an Economic Hit Man for a cynical view of this). And besides, dam projects are rarely successful and before you know it they silt up.

A focus on reducing poverty requires a new approach. It requires an understanding of the root problems, it means spending time with the poor to understand their circumstances to be able to create appropriate and sustainable solutions rather than prescribed programmes that develop and maintain a dependency culture.

There are parallels here with the IT industry. Much of the IT game remains focussed upon those big projects. Software dams that can be launched with great fanfare but do little sustainable good to those most in need. The customer.

Before I wound up in IT I worked in international development. My PhD. “Ergonomics tool and methods for use in Industrially Developing Countries” was based on working with farmers in Sub Saharan Africa, looking at how technology is transferred and how it can be made more appropriate, sustainable and usable. Many of the tools and techniques I used in the bush I apply with the corporations I work with today. These came under the umbrella of “Participatory Technology Development” and “Participatory Rural Appraisal”.

Rather than the delivering the white elephants of expensive machinery that you see littered around Africa, Participatory Technology Development is an approach for developing simple low cost innovative solutions that have the ownership of the community who work with researchers to build them. The PTD framework starts with gaining a shared understanding problems and opportunities. This is followed by defining priority problems then experimentation. Experimentation is collaborative with options derived from indigenous knowledge and support from the researchers experience and expertise. The farmers own the experiments and the results. This leads to the next step of the framework; sharing the results with farmer led extension. (Traditionally dissemination of agricultural advice is done by agricultural extension officers – government employees who despite their best intentions preach too the farmers, sharing centrally defined agricultural advice rather than the more appropriate, locally developed technologies that the farming community have developed themselves). The final step to the process is the researchers withdrawing, leaving the community with the capacity to continue the process of change.

(Sounding like agile?)

If PTD is a framework, then PRA is a basket of tools and techniques that can be used to support it. These can be broken down into nine categories:

  • Secondary data reviews – reviewing existing sources of information
  • Workshops – getting key stakeholders round the table (or more appropriately under the banyan tree)
  • Semi-structured interviewing – talking to people with a loose conversation direction
  • Ranking and classification techniques – identifying “things” and ordering them according to different criteria. (Often this will involve moving pebbles around boxes drawn in the sand).
  • Diagramming, illustrations and graphics – pictures to convey ideas and concepts, through “boxes and arrows”, Venn diagrams and charting to cartoons and imagery
  • Mapping – drawings or models that represent the local environment
  • Structured observation – watching people doing
  • Timelines – What happens when, for example seasonal calendars, a line in the sand and people put pebbles down against the time to show when crops are sown, harvested, how the price fluctuates, labour migration etc.
  • Community meetings – meeting the whole community rather than just the immediate stakeholders who participate in stakeholders. Showcases?

Are you building a Software Dam? Or are you focussing your aid on those most in need? PTD and PRA are approaches that have developed to help introduce appropriate, sustainable improvements to the life and wellbeing of subsistence farmers. Much of their content can be transferred to IT projects, helping introduce appropriate, sustainable improvements to the life and wellbeing of customers / users.

Reflections on QCon

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

Architect your solution around the customer experience

I was at QCon yesterday, ostensibly to give a presentation on usability, but I attended a few sessions as well.  Not being a techie, I didn’t understand much of what Werner Vogels, the CTO of Amazon was talking about during his presentation on Availability and Consistency, but one thing has stuck in my mind.  “Never, never refuse the customer from putting stuff in the shopping cart”.  The context of this was around how your architectural design; do you go for consistency or availability (or something else which I can’t remember).

I’ve blogged before about siloed organisations, but Werner touched on how even internal IT organisations can be siloed.  Something about how your database team may be soley focussed upon consistency; they are willing to sacrifice availability for valid technical reasons.  But the database needs to be seen in the bigger picture, outside the confines of the IT organisation.  It needs to support the customer experience.  And that means the customer must always be able to put items in the shopping cart.  Period.  The takeaway I suppose is to build your architecture around the customer experience; decompose the experience to do this.  The technical requirements for your shopping cart will be different from your fulfilment mechanism from your “see what others are buying” from your “my details”.  Make technical decisions accordingly, rather than a one-size fits all.

6 of 13
2345678910