From the Director
Learning from Customers—Even if it’s Difficult
I’ve just returned from teaching a Minimalism workshop in Heidelberg, Germany. Great group—quite representative of those who are willing to think about minimalism as a new way of working.
Attendees at the Minimalism workshop are often surprised that we’re not going to talk about writing shorter sentences or using simplified language techniques. They often assume that Minimalism is all about writing and editing. But it’s not.
Minimalism is about thinking and planning differently:
- focusing on customers instead of product features and functions,
- knowing that “How-to’s” need more attention and emphasis than “What-is’s”,
- helping customers solve problems and get out of trouble, and
- ensuring they can find (quickly that is) the information they need.
Unfortunately, this focus frequently meets with resistance from attendees. They argue that they are not permitted to understand their customers, certainly not meet them or even talk to them. Their work is under control by product developers who want someone to document what they’ve developed, otherwise known as the product specification, rarely written down in our agile age.
Perhaps the most frequent response is from those who argue that they are simply too busy turning out documentation on product features and functions to spend time learning what customers really need.
Or, if they do talk to customers, it is to ask them what they want rather than investigate what they need.
Remembering Steve Jobs
Steve Jobs was an inspiration at Apple from the first and continues to be an icon of innovative design. But he seems to have had minimal influence on technical communicators and information architects. Just yesterday, the DITA Yahoo User Group focused on a discussion of turning badly designed legacy documentation into a “sort-of” DITA disaster. Unfortunately, an earnest information architect finds herself battling an author community that refuses to consider rethinking or redesigning anything.
When I started Comtech in the late 70s, Apple Computer was one of my first customers. As an Apple devotee, having purchased one of the first Apple II computers in 1978, I was delighted to become part of their process. That first assignment was to conduct early usability investigations of their HyperCard online help development system. The first usability investigations were held with internal Apple employees, and we demonstrated that HyperCard was not ready for prime time. The concept was fabulous, but the execution and the user interface were lacking.
Of course, end of story, they fixed it, and HyperCard became a great tool for getting information, hopefully useful information, into computer customers’ hands. In fact, a colleague presented a new employee evaluation process for her agency entirely in HyperCard. It was a gem, making otherwise boring process information into a delightful game show.
I’m a little behind on my reading, so it wasn’t until yesterday, when I picked up the June 2011 copy of the Harvard Business Review (HBR), an issue shining a spotlight on product innovation, that I was reminded of the Apple connection and its affect on Intuit.
Another of my earliest work in usability testing was at Intuit. They were just developing the new Windows version of Quicken. We conducted the first ever usability tests on the prototype product at the request of the product manager and with the encouragement of the documentation team. The usability testing led to major improvements in the User Interface of what was ostensibly a new product. Meeting the CEO, Scott Cook, I learned that he had done informal usability testing in the family kitchen, involving neighbors in the development of the Quicken check register product. Our usability testing led to his support for a full-blown usability lab at the company.
The June 2011 HBR article, “The Innovation Catalysts” by Roger L. Martin, explains that in 2007, “Scott Cook realized that he wasn’t another Steve Jobs. At first it was a bitter disappointment … success always seemed to need a powerful visionary at the top” (page 83). Apparently, Intuit’s Net Promoter Score (NPS)1 had stalled. It wasn’t creating new and innovative products that would delight customers. Those NPS results led to the development of a new initiative called Design for Delight, inaugurated by a participatory exercise in which managers “worked through a design challenge, creating prototypes, getting feedback, iterating, and refining.”
The Design for Delight initiative, led by a team called innovation catalysts, focuses on direct user engagement to
- identify customer pain points
- generate new product ideas
- develop prototypes as quickly as possible, including the Wizard of Oz2 technique that I described years ago
- get the prototypes in front of customers
- schedule feedback opportunities
- make quick design changes
- deliver in record time
If this sounds like the recommendations in Minimalism and User and Task Analysis workshops, it’s because these are classic ingredients of user-centered design with a bit of real agile development thrown in (as opposed to pseudo agile development which excludes customer study and customer feedback).
The Design for Delight process has clearly been successful for Intuit. The number of customer engagements in the various product lines has increased dramatically. The initiative produced a new product for Millennial customers, called SnapTax, which has had a successful start. NPSs are up, and growth in revenue and income has increased.
Why Not Information Development?
So why does information development lag behind? Have information developers convinced themselves that documentation is a “necessary evil”? Do information developers secretly adhere to the argument that “nobody reads the manuals anyway”? Why do our survey results still show that groups throw hundred- or thousand-page PDFs over the transom to the company website?
Those of us who believe in the Minimalism Agenda have communicated for 30 years that information adds value when it makes real customers successful in meeting their goals. They continue to tell us that they must
- learn to use our products quickly
- find “How-to” information that leads to immediate results
- read conceptual and background information only when it helps them do their jobs and complete tasks more successfully
- use Google and other search tools to find answers to questions, which means individual topics that are linked to other products, not 3,000-page PDF downloads
- find solutions that lead directly to achieving their goals
- get out of trouble on their own, even before asking for help
However, achieving these results, which positively influence NPSs, means that you have to get out of the cubicle, away from the computer, and into a conversation with customers. And, you cannot just ask them to tell you how to write. You must learn what they need from information to be successful.
Increasing, we find that customers of technology have little time to read and less time to solve problems. They’re looking for quick answers and instant accessibility. No wonder we find that SMS on a smartphone is considered an invaluable tool for problem solving, along with other social media.
Knowing the customers is the most difficult knowledgebase and skill set to outsource. The more you engage and change what you write, how you write it, and how you deliver customer-focused information, the more valuable you become.
I strongly recommend getting a copy of the June 2011 issue of HBR and reading all the Spotlight on Product Innovation articles. There is much to learn and think about. Then get your own Design for Delight initiative going, if only to make sure you still have a job next year.