Customer Experience Archives - Page 11 of 15 - dancingmango

Working software that doesn’t work

Monday, 11 December, 2006
By: marc

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: marc

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?

Pictures and narative

Thursday, 23 November, 2006
By: marc

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!

The product is irrelevent. It’s the customer experience that pays the bills

Friday, 17 November, 2006
By: marc

Why do organisations exist? To make money. In corporateSpeak “to add shareholder value”.
Where does money come from to deliver shareholder value? Customers.

Many organisations seem to forget this slight detail. It gets lost in the internal machinations and politics.
Why do individual funcitons exisit within an organisation? Marketing, product development, IT, sales, operations… None of these ~~add shareholder value~~ make money in themselves. Yet in all too many organisations these different functions behave as if they exist for themselves, they are entities unto themselves. Each entity may pay lip service to the “customer” but how joined up is the reality?

How familiar is this.

The product team identify the need for something, based on anecdotes from the sales guys, or something they perceive to be wrong with the existing product or a hunch about a potential niche in the market. A niche in the market but is there a market for that niche? A bunch of requirements are written up and an optomistic benefits case is written up. There are x million widget users in the market place. Y% of these would benefit from NewGizmo. We project 10% of these will buy at a price point of £z. The requirements are thrown over the wall to IT to put some development costs on the project. The project has yet to start and a launch date is set in stone. And a project manager has yet to be assigned. Marketing are brought into the picture and tasked with how are we going to sell the product. Development starts (the new project manager is aghast at the scope and timescales he is inheriting). Operations enter the project and throw water on the fire. There a whole bunch of compliance and business as usual considerations that only now come to light. Relationships become tense as the project manager tells the product team that they can’t have what they want by the date they wanted it. The date has been set in stone, so the product team throw out some of the initial requirements, based upon an argumentative workshop on Thursday afternoon (noone bothers to refer back to the initial benefits case, even less any thought of how their decisions impact the overall customer experience). And inevitably a cut down NewGizmo is launched to the market a month late and sales are nowhere near what was projected. What we need is NewGizmo 2.0 and so the cycle starts again…

What if we put the customer at the heart of the organisation. What if everything we do is motivated by serving the customer? What if we forget all about our products and focussed upon what our customers’ need and how we can delight them. What if the products become an enabler to a compelling customer experience, rather than an end in themselves?

Isn’t shareholder value all about generating revenue? Isn’t revenue driven from customers? Aren’t customers driven by compelling experiences rather than mediocre hassle?

Clarity in objectives

Thursday, 16 November, 2006
By: marc

Too many IT projects have vague buzz-word objectives.

“Single sign-on”
“Legacy refresh”
“Migration”
“Porting”
“Global Tick database”
“Unified platform”
“Cross channel integration”
“Content mashup”
“Real-time la-la”
“Streamlined processing”

These aren’t objectives. They are recipee for confusion, lack of clarity and focus. Better to think in terms of customer journeys, what is it that an end user want’s to achieve, end to end, and focus on delivering real value to customers, rather than trying to deliver some amorphous, mamouth “implementation” that does a lot of something mediocre, and little of anything great.

If you were a bank, which bank would you be?

Wednesday, 8 November, 2006
By: marc

In the last year, Barclays have rebranded themselves. This is not just a change in the logo (as apparent with NatWest) but a focus on the customer experience. Go into a branch and there’s a calculator on the desk to add up those cheques you are paying in. And a pen to fill out your paying-in book. A free pen. A nice touch – they don’t assume their customers to be thieves and chain the pen to the desk – how much does a pen cost? And put a logo on the pen and you have free advertising.

On the counter there’s some technology to enable customers to rate the experience they’ve just had. Capturing customer feedback at the time of engagement, better than a focus group at a later date in a stale market research suite.

Outside the branch they don’t call the hole in the wall an ATM. They call it what their customers call it. A Hole in the Wall. All these things make me feel warm towards the brand. Brand Warmth is something that marketeers measure. Customers who feel warm towards a brand a more likely to consume that brand. In marketing research, perceptions of the brand can be tested further using word association. “If AcmeBrand was a car, what car would it be?” “If AcmeBrand was a tablet and you took it, what would happen to you?”

I think that we can borrow some of this thinking when we build software. I’ve written previously about emotional requirements – how do we want users to feel when using what we design and build. Before we start on something new, ask the question “how warm do we want our users to feel when using this product?” It’s a useful level to pull; warmth is probably going to cost more.” “If this product was a car, what car would it be?” If the customer says “Ferrari” and we are thinking Ford Mondeo we need to focus on managing expectations. A Ferrari is going to cost a lot more than the Ford. I’d like to know what I’m going to get before I start bragging about the new sports car I expect to soon be parked in my drive.

Customers are not your enemy

Tuesday, 7 November, 2006
By: marc

Paired programming can be daunting to developers who have not done it before. The thought of some someone else looking over your shoulder whilst you work can be met with resistance. And yet the benefits of the transparency that paired programming brings are well documented.

B2B organisations display similar traits to the developer who is resistant to paired programming. They don’t want anyone looking over their shoulders until they are comfortable with what they are doing. And that includes customers. In my experience, the bigger the “B” and the smaller the “2B” the harder it is to gain access to the people we are developing the product for.

It’s not like this in the B2C world, where organisations understand the need to talk to their customers, to do market research, to test propositions. In the B2B world, organisations become far more protective. There is a fear that if we talk to our customers we will be making promises that we cannot keep. We will be building expectations that will inevitably be broken. In the B2C world you can show what you like to customers, if the final product bears no resemblance to the ideas we’ve tested in focus groups it doesn’t matter. The conversation with the customer is part of the process. We do not assume any “customer memory,” indeed the fact that we have explored different ideas and propositions with customers is seen as a positive; it can feature in the PR associated with the product release. If you release a product to market that looks nothing like what you’d explored in early focus groups it really doesn’t matter. You are selling to a segment that is bigger than a focus group of 12. But what if you customer base is small. What if there is a customer memory, that the people you test propositions with are the people we depend on selling to. The people who will keep us in business. In such a scenario it is understandable why you become protective of your ideas and fear saying anything to your customers until you are confident that you can deliver it. Trouble is, by that stage it may be too late. You are committed to a path of action that can be costly to change. What is required is some transparency and honesty; creating a dialogue as early as possible.

So here is the challenge for B2B organisations with a small, high value customer base. Open yourselves up. Be honest, open and transparent. Web 2.0 is all about collaboration and social networking. That shouldn’t just be about me sharing my photos on flickr, my videos on YouTube, my bookmarks on delicious. Product managers should be blogging about what is happening on the product they are developing for their customers. Customers should be commenting on the progress that is being made; they should have a direct channel to the development team, not via layers of corporate Chinese whispers. Here’s a challenge to the business in B2B organisations; get blogging. Stop fearing your customers and worrying about failing to meet what you perceive them to expect. Once you are transparent to your customers and proactively manage their expectations you can venture on a more successful and profitable journey as partners, not as adversaries.

What time does it land?

Saturday, 4 November, 2006
By: marc

Gone are the days of checking teletxt. FlightStats provides live details of flights, including expected times and historical performance of the flight – based on past records what is the chance of the flight being delayed, and by how long. And a nice little touch- it uses Ajax for searching flights, airports, carriers, etc. For a domain that is acronymn driven, a nice touch.

Speed and convenience

Thursday, 2 November, 2006
By: marc

I recently picked up an old BT phone at a car boot sale. Using it made me realise how using the phone has radically changed since my youth.

Then: In those days you remembered all your phone numbers- the frequently used ones at least. Others would be in a notepad that was close to the phone.

Now: Phones have memories, the notepad is in the phone. And frequently used numbers can be set as speed dial. (It’s an interesting question whether the move to from analogue to digital phones has had an impact on memory…)

Then: To make a phone call with x digits would take y seconds. Oooooh how slow and painful! The pleasure of the retro experience using the old phone soon turned to frustration. How long to dial a number? And if the number was engaged there was no such thing as a rapid redial.

Now: the fingers fly accross the keypad. Engaged? wait a few minutes and press redial.

Two words articulate the new experience; speed and convenience. The old BT phone sits in the lounge. It sounds cool when it rings. I may pick it up. But use it to dial numbers? I’ll stick with the modern experience of speed and convenience.

Parsimony and the golden plate

Wednesday, 1 November, 2006
By: marc

A general principle in science is that if there are two feasible explanations for a phenomenon then you will take the most parsimonious, the simplest and most elegant solution. Agile software development takes a similar principle, do just enough focussing upon what is truly needed. Practitioners of the methodology will recount with pride how they have worked on projects were the “customer” required A,B and C. They’d planned for eight iterations, but by the sixth iteration they’d delivered A,B and half of C and the customer was happy; the software met the customers requirements and was delivering business value. There’d be diminishing returns by carrying on any further; any more work would be “gold plating”

“Gold plating” in software development is a concept that is frowned upon. Doing more than is strictly necessary breaks the theory of parsimony; if it is not going to demonstrably deliver value then it is gold plating and is to be given a low priority. More often than not gold plating is seen to be “scope creep”. This is often manifest in agile projects when requirements are deliberately vague at the outset of the project. Why invest time in specifying requirements that will undoubtedly change as the project progresses? The problem is that the developers’ idea of how a solution will be implemented will be the most parsimonious solution whilst the customer has a more complex idea of how a feature will be manifest. The requirement is the same, yet what the customer actually wants is gold plating and scope creep. Let’s explore this with an example outside the software industry.

Imagine a product in development. It’s hi-fi comprising of separate amplifier, CD player and speakers. It is to be sold as a package (yeah, development is iterative and each component could be a release, but that is not the point here…) We are going to need to connect the CD player to the amp. We can express that as a story:

As a customer
I want to connect the CD player to the amplifier
So that I can amplify my music and listen to it through speakers

OK, so we need some interconnect cables. Using our experience of connecting amps to CD players we picture this:

We know what it takes to make one of those cables because we’ve made them before so we can accordingly put an estimate to this requirement. Trouble is, for this scenario it will be wrong.

Return to the opening statement, “imagine a product in development”. There is a whole wealth of information missing in this statement. There is more to the product than it’s physical construct. We need to consider the context in which the product is to exist. In the world of interaction design this is contextual analysis.

Numerous factors may have an influence on the development of features. Start with the competitive landscape it will play in. When placed against competitor products, what is it aiming to do, is it going to meet a need (the CD player just plays CDs); are we looking to achieve competitive parity (we will match other features that are standard on our competitors products) or is the product goal to exceed expectations and become the market leader (it will offer superior sound quality and the ability to play MP3 files).

Who is the target market? In our story we stated “as a customer”, but who is the customer? Is it mass market or niche audiophile?

In addition to the business objectives which are critical to drive forward the project, (i.e. launch the new product to increase market share) the product objectives should also be considered. For our hi-fi this is “great sound for the budget audiophile”. Once we have this we can attribute emotional requirements to the product. How will our target customers expect to feel when they use the product. What emotions should it elicit? For this product let’s assume “high quality” and “simplicity,” rank highest.

With this background, when we return to the interconnect requirement, it is clear that the original assumptions are invalid. Our assumptions were based upon a mass market solution achieving competitor parity. In fact we need to aim a little higher, our customers are more discerning, the product is to be marketed as high quality audio and we are looking for the product to be an award winning design. So those interconnects? We need to gold plate them. The story will actually manifest itself as this:

Mmmm. Gold plated interconnects. Gonna sound good!

Now the real world

Let’s take a requirement from the banking world. It’s a system that allows users to trade equities; to buy and sell shares.

As a user
I want to select a UK equity
So that I can see its current bid / ask price.

At its most parsimonious our acceptance criteria (i.e. how we will know this requirement is complete) are as follows:

Given the user enters the stock RIC code
When the chosen stock is valid and tradable
Then display the bid/ask price of the stock

Given the user enters a stock RIC code
When the RIC code is not recognised, the chosen stock is invalid or untradable
Then display an error message saying “RIC not valid”

But is the most parsimonious solution the right one? We can only answer that once we have carried out some contextual analysis. For professional equity traders, who know RIC codes and speed is of the esscence then the implementation implied in the acceptance criteria is correct. But if the stock look-up is a new feature on a retail banking “portal”, extending the banking offering beyond balance and transaction reporting and making payments, to include share trading for a “mass market” audience then the implementation falls short of what is truly required. In this scenario the feature requires gold plating. This may include

Searching on company name in addition to RIC code
Meaningful error messages
Help text, content managed.

If the requirement is to have a “world class” share trading system we may need even more gold plating:

Narrow search results as the user types in letters
And so on.

If we turn to business value, it is hard to ascribe business value to the gold plating of individual features. Instead we should explicitly state up-front the emotional requirements that will “bloat” features beyond the most parsimonious implementation and inflate our initial estimates accordingly.