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.
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.
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?
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.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.