This week, Cameron Moll gave a design presentation to a small group, including our team. He discussed some principles of good versus great design. One of the concepts he brought forward was problem-centered design. As I understand it, a solution-centered design says, “I’ve got this product, so how do I make it do what I want or solve my problem?” Problem-centered design involves focusing on a problem statement to help identify the objective and see the way to design a solution.

I wondered how to implement problem-centered design myself. Applied to documentation, a problem-centered approach seems given to forms like troubleshooting guides and FAQs. The user has a question or problem, so here’s the answer. Simple as that.

I made myself think about it more, though, because if I dismiss it as meaning just troubleshooting or answering questions, I miss a chance to broaden the way I look at what I do and thereby improve it.

When it comes to documentation, what’s the first problem users face? (Assuming that they’re using it.)

“It doesn’t tell me what I want to know.” Stated in another way: “I can’t find what I need.”

These are pretty general statements and could point to any number of problems, such as incomplete information, loose or illogical organization, or limited linking and cross-referencing. By digging a little deeper with users, we can find out what the real problem is and then fix it.

Something that’s left to technical communicators many times is solving product problems, which is where the troubleshooting guides and FAQs come back in. The designer may not be thinking of solving certain problems or addressing user stumblingblocks within an interface, or maybe the interface doesn’t allow for it (perhaps this is solution-centered design?), which means the documentation has to make up for the deficiency.

Other problems with documentation (or related processes) that we could encounter include:

  • I can’t update my help on the fly.
  • My tutorial files are too large for some types of users to easily download.
  • I don’t get any user feedback on my materials, so I don’t know what they think.
  • Half of the time, my reviewers don’t get back to me before the documentation needs to be released.
  • My content chunks are too long.
  • I’m documenting a lot of third-party software in my procedures.

As I’m coming up with these, my brain starts telling me the problems with some of these problems, which is to say that it suggest to me the reason I may have some of these problems. That gives me a place to start. The earlier on that I state and confront problems, the less costly and painful they’ll be to fix.

Related entries (auto-generated):

Technical Communication: The QA of Product Design

Team Documentation Design Reviews

Results of a Team Design Review: A Different Context-Sensitive Help Structure

A Writer’s Exercise for Critiquing Design

Try a Quick Reference Guide for Short-Term Documentation Needs