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.
I haven’t listened to this particular talk but will do so as I like her stuff a lot. The one real-life example that approaches this was my work some years ago in developing a consultation strategy on behalf of a local government organisation. As an outsider I was able to identify that their existing call centre was over staffed and entirely passive – by utilising it to collate customer feedback and to undertake frequent phone surveys (with opted-in citizens), it was transformed into an interactive data collection resource and the staff were enthused and more involved with their employer. As you say, not rocket science – just a case of joining the dots.
user performance is and should be part of the equation