By John C. Baker
Some time ago, when working on a video script I asked, “Who uses this feature and when?” To my surprise, the developer who created the feature didn’t know. In fact, no one who regularly attended our agile stand-up knew! I finally found the answer in Support, who knew that customers use the feature all the time for both troubleshooting and creating network domain names. I finished the video, noting the now dual-purpose for the feature, but I was struck by that initial discovery. I simply could not understand how a developer could code a feature and not understand who was going to use it, what their need was, and when they might need it. As it turns out, this is distressingly common in enterprise software development.
“What problem are you trying to solve?” is a central question for anyone creating technical content. It may well be THE central question. I consider the UI and the interactions that it offers to be technical content as well. When I write that it’s the one, central question, I mean for all of us in software development.
It’s important to draw a clear distinction as to whose problem we are solving, before deciding on an answer. You may state the problem as, “Our customers don’t know that we have such-and-such a feature.” Though I hear it often, that is not the real problem. That is your company‘s problem! Whether you are authoring a technical information, scripting a video, or designing the UI/UX for a product, you need to find out what the customer’s problem is and solve that. Customers don’t care if you have a product you want them to know about. They care about getting their daily business problems solved so they can get their own work done!
Here’s a recent dialog to illustrate this point. When researching a different video script, I was having trouble determining what problem we were solving. Everyone in the room had a different idea and approach. I had asked the central question several times and continued getting wide variations as an answer. It was beginning to look as though we didn’t really need a video!
So, I asked another question that’s closely related to “What customer problem are we trying to solve?” It’s the question I usually use to delve deeper into something someone thinks they’ve explained with a Universal Truth. The question is, “So what?” It carries both the inference of “I’m not getting it” and the implicit question, “Why should anyone care?”
The answer was the inspiration I needed. Why? Because we stopped talking about why we as a software company want customers to know about Product X (which was, of course, increased sales). Instead, we started talking about how the customer works and what they need to do. “Customers manage their workloads by exceptions,” the Product Manager told me. “They couldn’t care less about jobs that end properly and on-time. That’s the expected norm. But when the jobs are late in completing, or fail altogether, that means that other jobs and processes that depend on that job will also fail.” The light bulb went on for me!
“So… our customers don’t know that we offer a product that will predict those late endings and failures, and alert them before it happens!?”, I asked. And that was absolutely correct. Instantly, I began to hear in my mind how the script would sound. I started composing the opening of the script aloud and that resulted in lots of nods and smiles. The opening was focused on what customers need to do – maintain their service level agreements within their companies!
In three decades of technical writing, I’ve seen this so many times. Figuring out what the customer’s problem is takes time. Faced with more work than we have time for, we often take the path of least resistance, or allow others to decide for us whether content is needed. We document the UI and hope that the customer will infer the workflow based on the “intuitive design.”
When you at last begin to explore “What customer problem are we trying to solve?”, you uncover more than just the What and the How. After all, most mediocre documentation contains that much. Your explorations also have to uncover Why?, When?, Where?, In what order?, and To what customer benefit?, if you want to go stellar with your content. The time this kind of research takes is often the reason we don’t, or can’t, do it.
Further, when you do this kind of research, not all of what you learn goes into the doc. You may need to learn some aspects of a domain that’s new to you, but not to your readers/viewers. But the things you learn inform what you decide to include, and if done well, in ways that truly benefit your customers. I believe that video scripting distills this writing process in some very useful ways.
Videos have to be short and to the point. They also have to be much more conversational in tone. You have to decide rather narrowly which problem you are going to solve. (That rarely involves a single dialog box or screen view, by the way.) More often, the solution to the customer’s problem is in a workflow or process they’re not using, not using correctly, or of which they are completely unaware. That workflow may involve more than one new “feature”.
The question is the same, and the process of finding its answer is the same. But, the video format gives those answers a different voice – literally and figuratively. Try it out sometime – take the topic you are writing about and see if you can turn it into an interesting video script. Such scripts are interesting only if other people find them interesting, so test and re-test your script with others to see how it reads. You may find yourself crossing out many lines of what you believe to be a
About the Author
John Baker is currently working in CA Technologies, Inc. as a Principal Information Engineer – Media Development.
In his work for companies such as InterVoice, Tandem Computers, Texas Instruments, Sterling Software, and CA Technologies, John has written just about every kind of doc you can imagine. He has also recorded videos and voiced tutorials and demonstrations. He’s delivered classes and presentations from Pre-Sales to technical conferences for various products on three continents.
After nearly 30 years in Content Development, Technical Writing, and Instructional Design & Delivery, John is now delivering content using video and voice to connect with viewers, listeners, and the technically curious. As a Voice Actor and Storyteller, John brings a warm and empathetic collaboration to industrials (training) and explainer videos, and a wacky and fun personality to lots of other kinds of audio projects like commercials, animation, audiobooks, and video games.
Recent Comments