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.

Madcap Flare Adobe Robohelp

This entry was posted in findability on by .

By Tom Johnson

I'm a technical writer working for The 41st Parameter in San Jose, California. I'm primarily interested in topics related to technical writing, such as visual communication (video tutorials, illustrations), findability (organization, information architecture), API documentation (code examples, programming), and web publishing (web platforms, interactivity) -- pretty much everything related to technical writing. If you're trying to keep up to date about the field of technical communication, subscribe to my blog either by RSS or by email. To learn more about me, see my About page. You can also contact me if you have questions.

3 thoughts on “Finding a Starting Point: Answering Questions or Addressing Purpose?

  1. Larry Kunz

    Tom, thank you. You’ve summed up in a few words some principles that should resonate with every technical communicator. The reader’s experience is a story. Questions and answers make sense only within the context of purpose. (Many times the reader doesn’t even know what the right questions are.)

    I especially like the unseen hand metaphor. I’ll remember it next time I’m tempted to think that my work is dull or without purpose.

  2. craig wright

    Surely the ‘user journey’ always defines your structure? Whenever I’m writing tech docs or help, the very first things I try to establish are: who is the end user?, what is their level of understanding?, what are they trying to achieve or learn? I’ve found that starting point to be foolproof so far and I’ve worked in some pretty diverse businesses.

  3. Marcia Riefer Johnston

    Tom,
    Your distinction between users’ questions and their purposes reminds me of the distinction that technical communicators often make between tasks and goals. Your phrase “contextualizing the question inside a purpose” works there, too: we help users best when we “contextualize the task inside a goal.”

Comments are closed.