Designing and testing for customer experience

A few weeks ago, I wrote about how using opensource makes you responsible; one of the tragedies I’ve seen regularly in large institutions is the willingness of service departments to hand off blame to the “vendor”, and I’ve often wondered why people abdicate responsibility that willingly.

The customer does not care about your sourcing strategy. The customer cares about what he/she experiences. That’s what we have to design for, that’s what we have to test for, and that’s what our sourcing and partnering strategies need to underpin.

As we move towards realms where more and more things get commoditised, and more quickly at that, it is reasonable to assume that the only aspect of a service offer that differentiates one firm from another is the quality of the customer experience.  And one of the things that intrigues me about all this is how to get better at designing for customer experience, and its cater-cousin, testing for customer experience.

While researching this, I came across a transcript of Danah Boyd’s talk at the O’Reilly Emerging Technology Conference in San Diego earlier this year, via Kathy Sierra’s post on ultra-fast release cycles.

The entire talk is a must-read. Examples:
[Talking about MySpace, Flickr and Craigslist]

These three sites have many attributes in common. They all grew organically. They each have public personalities that early adopters feel connected to. The early adopters really felt as though they were participating in and creating an intimate community, even as the community grew to millions. Users are passionate. Designers are passionate. They feel a responsibility to it and are deeply invested in making users happy. Character was not boiled out of the site; the text on the system is natural and goofy, reflecting the personality quirks of the developers rather than the formal speech of a corporation. Each site has a unique culture that was born early on and evolved through years of use and growth. The culture evolves with the designers and users working in tandem.

Customer service is not a segregated group who simply answers questions of a finalized product. They are completely integrated into the design system and the senior people are the most deeply embedded in user culture. There is a strong commitment to the needs and desires of the users.

While the creators have visions of what they think would be cool, they do not construct unmovable roadmaps well into the future. They are constantly reacting to what’s going on, adding new features as needed. The code on these sites changes constantly, not just once a quarter. The designers try out features and watch how they get used. If no one is interested, that’s fine – they’ll just make something new. They are all deeply in touch with what people are actually doing, why and how it manifests itself on the site.

[Talking about how the creators of these sites use embedded observation]

The designers of these systems are engaged in embedded observation. They are living in the culture that they are helping to frame. They are aware of the others living in that culture and constantly engaging with them to really understand the emergent behaviors. They recognize their power as designers and try to use it to benefit the collective rather than their own personal goals. Their design process is stemming from this embedded observation, producing a state of “flow” to use Cziksentmihalyi’s term. The designers love what they are doing and infuse their passion into the systems. This is a very powerful way of doing design.

What they’re doing methodologically is very unique in software development and is not yet part of the standard practices for developing social software, although it should be. Embedded observation allows developers to understand culture. They are doing a form of ethnography, the method used by those seeking to understand culture. They understand culture by living amidst the cultural natives, trying to understand practices from the perspective of the people engaged in them. They are trying to make sense of how the symbols came to be and how the culture is maintained. They are doing so in order to understand culture and to help shape the architecture to support the culture.

Embedded observation takes into account the cultural forces that can not be systematically tested or modeled. As a result, the designers are aware of social problems when they materialize and can work immediately to try to influence change. Their efforts at understanding culture and evolving the design alongside it create a meaningful bond between the users and the designers.

[As part of a set of guidelines at the end of the talk]

Make sure designers and customer support are engaged with one another. Customer support should help designers know what is going on with users; designers should work to understand what customer support is seeing. This probably means they need to be seated near each other, have an opportunity to socialize together, etc. Oh, and for good measure, have your designers drop into the support queues every once in a while.

None of this is rocket science; as Danah so eloquently explains, many of the more recent successful companies live and breathe this stuff.

I think there’s something that’s really important, something fundamental, that Danah captures well. As IT professionals, we’ve been good at listening to a lot of people. We used to be good at listening to ourselves, to the detriment of evweryone else. But we learnt from that, and we got better at listening to the “customer”. And quite often that meant the person who paid the piper. The front office. The sales channel. The product marketer. Whatever.

But we never really listened to customer service reps. And if we want to improve the customer experience, it’s a good place to start.
We need to get better at involving our customer service staff in the design process; we need to get better at getting them to articulate the scenarios they would like to have improvements made to; we need to get better at understanding what it really feels like at the customer service coalface.

More later. I’m interested in comments from people who have done this, what they’ve learnt, what worked for them, what didn’t work.

The Revealed Intention Exchange

Anant’s written a post about Orkut Crush which makes fascinating reading. Maybe it’s been happening across many social networking sites, and I just haven’t seen it; possibly because I haven’t used the “looking for someone” facilities.

Orkut Crush allows person A to register a  “crush” on person B, and vice versa; the registered information is only provided to the matched pair when both sides signal.

So at a level of abstraction it allows a signalling of intention, done in secret, with the intention only revealed to the other party when matching conditions are met.

There are many things that need matching. There are many ways of indicating interest or signalling intention.

I wonder.

Varieties of Work-Changing IT

I had the opportunity to spend some time with Andrew McAfee in London last week, but for some reason I hadn’t yet seen his article in November’s Harvard Business Review. So we didn’t talk about it. Shame, but one that’s easily corrected.
It’s well worth a read; I’m working on my comments and will share them with you in a post later. In the meantime, I believe it’s available free-to-air for the rest of this month, so do try and take a look, you can find the article here.

I just can’t resist one comment though. Take a look at the table below.

R0611J_A.gif

Andrew makes one very very important point. Not that the others aren’t important, but one of them really stands out for me.

In the table above, he defines Enterprise IT as “IT that specifies business processes“.

He does not say “IT that is specified by random and ever-changing and poorly articulated and inconsistent and sometimes even nonexistent business processes.”

IT that specifies business processes.

By this I don’t mean that the IT department has to specify all the business processes, that’s just plain stupid. What I mean is that enterprise systems work well only when there are rigorous standardised processes; they work well when these rigorous standardised processes are industrial strength, with external frames of reference; they work well when the number of processes is kept to an absolute minimum, and where process divergence and diversity is avoided. The “system” consists of people, processes and technology, working to common goals and held together by a common culture. Too often it’s the process piece that goes AWOL, aided and abetted by avaricious consultants, accepted and nourished by inertial inhouse staff.
IT that specifies business processes.

If only that were true. If only I had a dollar for every time “respectable” consultants plundered the heart of an organisation by mangling an enterprise resource planning system until it was as unfit for purpose as humanly possible. If only I had a dollar for every time “responsible” business users lapped up all this attention and “blamed” the internal IT department for rampant project failure, because they believed the lie. The lie that an ERP system was meant to mirror their existing processes. because they wanted to believe the lie. If only I had a dollar for every time the internal IT department quietly acquiesced and said it was all their fault, fired a few innocents, promoted a few bystanders, whatever. If only.

Of birds flying around unwalled gardens: There’s hope in them thar hills

For a while now, I’ve been tracking what’s happening with Songbird, and more recently I’ve started playing with it. It works. At least the parts of it that are meant to work, work.

cross_platform.png

Ross Karchner at Ross Notes puts it succinctly:

  • Songbird looks like it is shaping up to be the cross-platform, open-source iTunes replacement I’m looking for, with some really great integration with the larger music web– It’s like taking iTunes, ripping out the music store, and replacing it with the rest of the internet.
  • Browse to any web page with links to music, and it becomes a playlist. Songs play instantly, and saving them to your library becomes a single-click or drag-and-drop operation.

I love iPods, and will continue using them. Because they’re fantastic. In design and execution and usability and experience.

I’ve never bought anything from iTunes, though my children have. iTunes is nothing more than an elegant way for me to manage my music, music that I’ve paid for.

I love Macs. I still have fewer Macs than iPods, but the gap’s narrowing :-)

So why do I like what I see in Songbird? Because I don’t like lock-in. I want to be able to choose my device, choose my platform, choose my connection, choose my everything. I understand when that is technically impossible. I am less tolerant when it comes to creation of artificial scarcities and blocks. Just look at the garbage that is Region Coding on DVDs and you will see what I mean.

Songbird may not be the answer. We have to wait and see. But it has possibilities. And is “directionally” sound. [Pun intended].

On filmmaking and software development: Part 2

Yesterday I ended my post with a quotation from Wikipedia on development hell, and that’s where I want to start today. There are many reasons why film (and software) projects go wrong, and they all have to do with the script.

The script is central.

When producers and directors are looking to attract talent into a project, they use the script. When producers and directors are trying to get funding for a project, they use the script.

The script is central.

It represents an embodiment of the idea that sparked it all off, the problem that needs to be solved, the market with a barn-door sized gap, the customer itch that needs to be scratched, the business plan that’s looking for funding.

And unlike the past, unlike the waterfall and cascade days that led to their development hells with inflexible scripts, the script now evolves. We iterate through scripts. We cut the script down into bite-size chunks so that everyone understands what is needed, what is happening, what each individual’s role is. This iteration process helps us visualise what is happening, what needs to happen.

It is only when the script is stable that funding can be obtained. It is only when the script is stable that the project is initiated. It is only when the script is stable that we can speak about going “into production”.

Development is about scripts. Production is about making those scripts leap off the pages and becoming alive. Post-production is about making the experience available to all.

What are sets? Nothing more than reusable infrastructures with temporary skins. The key thing is that set designers really worked on making the sets reusable.

What about stock shots? Nothing more than reusable commoditised components that add limited value, yet remain necessary. So it’s important to spend as little time and money on them as possible.

The concept of calling a “wrap” is nothing more than really understanding modular design. You’ve compartmentalised something so that it’s got high cohesion and loose coupling, you’ve iterated through that piece until everyone is cool with it, then you’ve said “Enough”. Not Perfect. But Enough. You have time in post-production to fiddle with it, this is not the time. Move on.

More in the 3rd but not final part, which I hope to write sometime later today or tomorrow. It will summarise what I consider the lessons that parallel the two sectors, in tabular form. So why will it not be final?
Because Stephen Smoliar kindly pointed out that Tom Davenport wrote some parallel thoughts down in Information Ecology in 1997, particularly in a chapter headed “As shown on TV: A new model for information staff”. I promise to find a copy, read the chapter and try and tie it all together in a fourth and final post. Can’t say when, it depends on how long it takes for me to receive the book. I could cheat and use Search Inside, but I’m not like that. I’d rather fight to change the law.

And because I want to read the book now that I’ve peeked inside :-)