Microsoft built test tools in Visual Studio 2005 to address a virgin test market worth about USD 3 billion at the time. However, the product met with little success and did not create much excitement in the test community. A later in depth observational research of testers to see how they work—what’s their workflow, what tools did they use, what’s their contextual environment, revealed that more than 70% of the testers did manual testing. Most of the time they worked on one test case at a time. Their tools were manual – Microsoft word, excel, white board, paper. For many of these testers, Visual Studio became sort of a four letter word. They would complain- why are you making me do this? You are making me think like a developer!
In contrast, the test tools in VS2005 were automation based API testing tools designed for specialist testers like Microsoft SDETs. They were optimized for complex testing that required setting up a suite, a plan, a configuration, and all these things that were super-flexible and powerful. Test tools were like the Swiss army knife that could solve many problems many different ways. But to the average tester, it was impossible to get started and if one ever did, hard to use.
In short, majority of testers worked very different than the programmer testers within the company and elsewhere. It was really a case of lack of customer empathy. The team initially failed to recognize that testers outside could be entirely different beings from a Microsoft tester. After an expensive lapse, they identified a new tester persona named Ellen and released a test management environment for them in the form of Camano with VS 2010.
The cause of this lack of empathy is the curse of knowledge that software developer suffer from. They just know so much more about technology that they can’t see from an average real life users’ point of view. Microsoft software engineers did not understand majority of software testers. Possibilities of software engineers not understanding lay users are far higher.
It is important that the people behind technology products, as Tim brown, author of Change by Design, puts it, could see the world through the eyes of their customers, understand the world through their experiences and feel the world through their emotions. That is the essence of empathy.
Empathy is about knowing your customers deeply, in fact better than they know themselves. Product managers I meet recount how they are trying to do this through surveys, focus groups, usability studies, customer visits and conjoint analyses. But they are missing the point. All this data are meaningless without empathy.
So how can software developers factor in customer empathy in the software products?
One, change focus from feature driven, technology driven or competition driven product development to customer focused product development. Features often creep into products because management wants it or competition has it or because it is technologically cool. Shun these practices totally and make all your product processes customer-centric.
Two, develop strong understanding of your customer and make them center-piece in all your engineering and product decisions. Give face to those single word descriptions of customer segments. Develop personas. Put them across your office to remind developers who the customer is.
Develop customer insights beyond the obvious. Only then you have a chance to differentiate and be a winner. Use open questions and empathic listening when talking to customers. Do not stop at asking customers what they want. Customers often can’t articulate what their needs and wants are. They often learn to live with current reality thus killing all useful feedback they could give you. We have all seen people writing passwords on their palms, chaining their bicycles to the park bench, using all kinds of objects as door stoppers and so on. Such consumer needs become latent and never get surfaced in any questionnaire or interview. Customers are too occupied with their current business to be able to paint great future scenarios. They are no experts to tell you what will be a successful product in the future. Go live with them (ethnography), observe them going about their tasks in their natural habitat. Use empathy map to capture what the people in observation said and did, your interpretation of what they thought and felt and inferences of what their pain points are and what they desire to gain.
Three, stop developing features. Start developing scenarios. Scenarios are short stories told from the customer’s point of view that explains their situation and what they want to achieve. Scenarios describe the journey to a happy ending. Scenarios help shift focus from technology and mere use cases to customer. Remember, human brains are hardwired to understand stories. If you can’t tell a story out loud and have it make sense, you’re probably missing something. Make scenarios the heart of your product. Don’t ship a product with a broken heart!
Four, develop and live by a set of clear user experience (UX) principles. These principles help you make decisions that deliver a product with a clear point of view. An example of experience principles from Windows 8 (details available on the web) includes – pride in craftsmanship, change is bad unless it is great, be fast and fluid, solve distractions not discoverability, reduce concepts to increase confidence, win or lose as one.
Five, develop clear scenario success metrics. Test your scenario to this metric. For example a metric could be –
1) UX performance – did users successfully complete this scenario? How long did it take?
2) User perception – were users excited, frustrated, satisfied or annoyed while completing the scenario?
3) Functional test – does the scenario function as per specs?
Empathy approach to designing winning products has an underlying belief – it’s better to build a product that delights a small segment of users than to build one that targets everybody but doesn’t really nail it for any of them. There are countless examples of products like iPhone and OXO kitchen tools that are a roaring success with customer segments beyond what they were originally designed for.
Steve Jobs once said, “It is not the customer’s job to know what they want.” That’s absolutely right. It is yours.