WRITE THE USER MANUAL

Start with the Customer and Work Backward

Simplicity is the ultimate sophistication.

—Leonardo da Vinci

If you build product, the ultimate power play is not having to include user instructions. The capability or product is so obvious and well designed to the needs of the user that instructions are superfluous. I think about the unboxing experience of an Apple product. The ultimate in sophistication. Elon Musk has said, “Any product that needs a manual to work is broken.” The product should be so intuitive it doesn’t need a user manual. That is power.

We should all strive to deliver products and services so obvious, ergonomic, and intuitive that no user manual is needed. Ironically, a great way to achieve this is to write the user manual at the outset of the product’s design and understand the user journey before you begin development.

PERSONAS AND JOURNEY MAPS

User-focused design is a mentality and approach that puts the user smack dab at the center of requirements and product development. “Well, how else would you do it?” you might ask. The common approach is making the concept or specific technology the driving force and then attaching a market and user definition later. I’m not an expert on any of these, and the goal is not to argue for one over the other, but if “easy” is a goal, starting with the user is likely the best path to get there.

Part of the user-focused design tool kit is the development of personas and journey maps. A persona is a deep articulation, as rich and as broad as possible, of the target customer of your potential product or service or business. You want to know this person inside and out when you are done. The journey map uses the persona to develop insights into the events, questions, and activities going on in the person’s life before, during, and after the involvement of your service.

Developing customer personas and mapping those customers’ current journeys are terrific ways to document specific unmet needs and identify key friction points your future customers are experiencing right now. Following the path from start to your desired outcome can help you identify details and priorities that might otherwise be dealt with at too high a level or skipped over entirely.

It’s hard work to craft strong customer personas and journeys. It’s likely you’ll need a few iterations before you really nail them. (I often need to start over more than once before I gain any real insights.) The biggest mistake you can make on these is to build them for show rather than for function. Don’t worry about the beauty of these deliverables at this point. Do worry about getting insights, talking to customers, and validating your findings with others who can bring ideas and challenges to your work.

USER MANUALS

Developing a preliminary user manual for your service can be a powerful tool early on in a project. We used this at Amazon when developing products or APIs.

Your user manual should address at least two key customer segments: the end user of the device or service, and if you are developing a technical product or service, the programmer developing on your platform:

•   The end user of the device or service: Who is the customer who will be installing, using, adjusting, and getting feedback from your product? Outline what the unpacking directions will be, what the installation process will be, how updates will happen, what the data privacy terms will be, how to use and read the device, and how to connect it. Think through all the major steps the users of the product will need to take, and include them in a close-to-real-life user manual. Forcing you or your team to keep these steps simple will lead to great product ideas, user experiences, and technology designs.

•   The programmer developing on your platform: If you are developing a technical product or service that developers will be using, perhaps an IoT product, it includes an API allowing developers to access, deploy, integrate, and extend your product. You will also want to build a user manual for the developer. Write the interface for the API, what events will be supported, and the data to be sent and received. Give sample code snippets, and outline key operational topics such as how testing occurs and how operational status and updates are facilitated. You’ll also want to use this exercise to outline key business and use terms. Are there charges involved?

Obviously, this can be extended to other key roles—for example, the salesperson or agent who represents your company or the service person who conducts maintenance and repair.

ALL HAT, NO CATTLE

It’s easy to announce, “We are focused on the customer” or even, “We want to be the most customer-centric company of all time!” That’s all well and good, but unless you’re willing to put in the hard work, spend crazy amounts of what may feel like “unproductive time” writing narratives, future press releases, FAQs, and user manuals for products that don’t exist, you’re just another cowboy moseying around the digital prairie who’s all hat, no cattle. It’s becoming increasingly apparent that people can say anything they want, regardless of the truth, in America these days. However, eventually, you have to produce.

John Wooden, the legendary UCLA basketball coach, is credited with saying, “The true test of a man’s character is what he does when no one is watching.” You need to ask yourself these questions: “Am I truly willing to start with the customer and work backward? Am I willing to be customer obsessed? Am I willing to do the hard work when no one else is watching?” The only person who can answer these questions is you. However, the answer will be crystal clear to everyone, especially your customers, down the road. Don’t forget that.