Finding a Starting Point: Answering Questions or Addressing Purpose?
Since I wrote my post about how help needs to be more engaging/appealing to users, I've been mulling over a better approach to help. I'm convinced that one key to creating good help is producing the right information.
In my last post, I wrote about the need to answer the user's question as the foundation for creating good help. But then I was reading something Mark Baker wrote about addressing purpose instead of answering questions, and I think that's maybe a better approach -- purpose is more foundational than answers.
Of course, the two are related: questions usually reveal a purpose. A user has a purpose he or she follows, and typically asks questions along the way. By identifying questions, you can usually guess the user's purpose.
But addressing purpose is a better model to embrace because purpose fits in with the archetype of a story, and I like stories. Centering on purpose instead of questions suggests that the user is on a journey toward some desired end. All protagonists in a story need a purpose or goal. In contrast, a question could mean the user is merely curious, or stuck, or confused. A question doesn't suggest a yearning for a desired end (which drives story).
Another problem with answering questions is the product you end up creating. In answering questions, you produce more of a knowledge base of disconnected topics. In contrast, when you address purpose, you produce a coherent map about how to get from point A to point B.
Since I think story is the underlying fabric of our actions, I can embrace purpose more than questions as the starting point to creating good help material.
As a technical writer, when you think about purpose more than answers, you become the unseen hand that helps the protagonist (aka the user) find his or her way through the dark forest (aka the interface). To identify the purpose, start with the user's goals (desired end), not the application interface (dark forest). Begin learning (observing) the desires the user (protagonist) has, not the need to document this or that widget (tree). Peel back the protagonist's questions (conflicts) to unveil the purpose (desire) that is driving the questions (action).
For example, if the protagonist asks, "Which way is Main street?" you might be tempted to respond, "Go two blocks to the right and then you'll see it." That answers the user's question but doesn't address the user's purpose.
A more astute response would be, "Where do you want to go?" The user might respond, "To the park." Your response: "Ahh, the best way to get to the park is along First street, since you can't park anywhere on Main."
Or since I'm referring to stories, think of Alice in Wonderland asking the Cheshire cat:
"Would you tell me, please, which way I ought to go from here?" Alice speaks to Cheshire Cat.
"That depends a good deal on where you want to get to,' said the Cat.
"I don't much care where--" said Alice.
"Then it doesn't matter which way you go," said the Cat.
Like the Cheshire Cat, we should turn questions back on themselves. Rather than merely answer, ask or consider where the user is trying to get to. What end is the user trying to achieve?
Questions that come in through support centers and other channels reveal where the user is getting stuck, but they don't necessarily reveal the purpose. The purpose is one layer deeper.
By addressing the purpose instead of the question, you also find a natural place to hang all of those answers to questions. By contextualizing the question inside a purpose, you can add notes and links inside of purpose-driven articles that answer the conflicts that users encounters along the way. And you won't end up with a series of sloppy "FAQ" articles all over the place.
I realize that starting with user purpose is not fundamentally different from any other approach to help. It's the user-centered approach. But beginning with purpose helps contextualize the problem in the perspective of story. And beginning with story never fails to engage.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.