Search results

The Art of Asking Questions

by Tom Johnson on Feb 17, 2010
categories: technical-writing

The other week Shannon and I met with our daughter's teacher for a regular parent-teacher conference. Sally is in third grade but reads books beyond her level. She's read the entire Harry Potter series. She raced through the Percy Jackson books, and will read about anything with a horse in it. The last Jazz game I took Sally to, we stopped off at Barnes and Noble to buy her a book (Diary of a Wimpy Kid) for her birthday. By halftime she had already finished it.

So when she received a B+ in reading, it threw me off guard. In our parent-teacher conference, I asked the teacher, "How are you measuring her reading ability?"

It turns out one of Sally's weak points is in reflection and analysis. She reads like a whirlwind, but she doesn't reflect enough about what she reads.

The teacher showed us one-line, terse responses from Sally. Hmmm, she seemed to answer the question, but not in a critical or reflective way. It occurred to me that we never really practiced reflection at home. We read Sally plenty of books as a child, but did we ask enough questions of the books we read?

To practice, I've started a new routine. After we read scriptures (the only thing we read together as a family), I invite the kids to ask three questions about what we read.

Asking questions is one of the most powerful ways to open up a text and begin a discussion. It's not a new technique, of course, but it's one a philosophy professor in college taught me years ago. The professor asks questions about everything. He hardly stops to answer the questions he raises. It seems he's more interested in asking questions than finding answers to them. Coming up with the interesting questions seems to be his point.

I'll give you an example. Take a familiar story -- Snow White. If the philosophy professor were reading Snow White, his questions might go like this: Why did the Queen want to be fairest of them all? What does it mean to be fair? If the wicked queen was a sorcerer, could she not make herself the fairest? Did Snow White have any magic powers of her own? Why did the author choose coal-mining dwarfs as her rescuers? Who is truly being rescued? What's the relationship between the dwarfs and the queen? And so on.

I admit my hypothetical questions aren't very good ones. For an actual sample, see his post analyzing Abraham.

Questioning an Interface

Asking questions is not only a good way to raise insight about a text, it's also a good way to investigate an interface. As technical writers, we should be asking a lot more questions than we often do. It seems that after we learn the main functions and purpose of an application, we document the core tasks and continue on.

But if we were to apply a  more in-depth questioning rhetoric, we would uncover a lot more. For example, I recently documented how to use a new calendar application. I covered all the main tasks and roles. But did I cover all the gaps where questions might be hiding?

Running through a sample screen, for example, the home page, with my questioning rhetoric, I might ask, Why is the calendar blank? How do I create a new calendar? What is the definition of a calendar? How does this calendar compare to Google's? How does it compare to Outlook? Why not simply use another existing calendar? If I'm using another calendar, can I import my existing content? What does it mean to "subscribe" to a calendar?

I could also put myself in the shoes of another individual in a specific scenario and generate questions. Now I'm my ward activities coordinator looking at the calendar. I have a paper calendar for the entire year already printed out. Here are my questions now: If I'm comfortable using my existing calendar software, can I keep using it? Why is this system better than the previous one? Does this calendar send notifications to the subscribers? Does it reserve room locations? Does it warn you about conflicts? How do I know if a calendar day is free?

Now let's pretend I'm the ward bishop. Here are my questions: Can I keep confidential appointments in the calendar? How do I know it's secure? How do I give viewing rights to my secretaries? Will the older members of my ward use the online calendar? How should I train the group leaders? Can I print this out and insert it into binders?

I could keep asking questions from different perspectives and problem scenarios until I saturated all the information users might want to know.

Too Much Information?

At some point, if I answer every question I ask, I begin to generate too much information. The application is a simple calendar, much like Google calendar. Should the help file be 150 pages? No one will read that much.

Mike Hughes says help should be a mile wide and thirty seconds deep. While I like to err on the side of too much information, having hundreds of topics to anticipate and answer every possible user question is a little extreme.

On the other hand, if you begin eliminating questions, reducing the help content to a bare minimum, don't you do a disservice to those who might need the information? This is where Mike's 30-seconds rule might come in. Perhaps keeping the topics short allows you to write and maintain more topics?

Ending Thoughts

Regardless of how many topics you decide to include in your help, asking questions is a tool that can serve you well in all areas of life. Learning to ask questions is the secret to having endless fodder for your blog. It helps you keep an open mind and converts a static reading experience into an engaging one. For my little third-grader, asking questions may help her develop a lifelong habit of reflection. She might even become a philosopher.

About Tom Johnson

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.