Design thinking, the methodology to solve complex problems to find desirable solutions, can be scaled to solve seemingly simple problems for technical writers.
Case in point. How many times have you had someone come to you, as the author of a document, and say “hey, my customer missed this step in the procedure and it didn’t work. Can you apply yellowing highlighting to the sentence they missed?”
Problem-focused solution: Apply yellow highlighting to text.
But not so fast. Regular thinking can be problem focused, but design thinking is solution focused and oriented toward creating a preferable future.
Reframe the problem
The first thing you need to do is frame or re-frame the situation to define your scope. Question your assumptions! Question the assumptions of the person who relayed the message to you (in your head, preferrably).
- Reframe 1: The customer wasn’t reading the documentation and, instead (as many others do), tried the process first. Then, turned to the documentation when he or she ran into a problem (and it was too late).
- Reframe 2: The customer was following the documentation, but wasn’t properly prepared early enough in the overall process.
While you contemplate possible solutions, it’s very helpful to switch gears and do something else for a while. Some people need to sleep on it, others just need to spend some time on social media. Either way, creating some distance from the problem is key to finding a fantastic solution.
Experiment and explore possible solutions
Reframe 1 is, well, something you can’t do much about from a documentation point of view. Definitely look for trends to develop. Does this keep happening? The worst thing you can do is react without thinking it through. That is, don’t update the documentation for one person at the expense of everyone else. And by that “one person,” I mean the one person who didn’t read the documentation. That problem might suggest that the software code needs fine-tuning, anyway.
Reframe 2 puts the responsibility solely on you, the writer. And this is something you can do something about. After thinking about where your audience may have gone wrong, write up a possible solution and test it by asking someone new to review it. You may even want to quiz the reviewer to see if what you did will work (without giving away what problem you were trying to solve because your writing will need to do that on its own).
After you are satisfied, you can release your update.
Although problem-focused solutions seem quick, they are rarely useful and ultimately consume more time by more people over the long term. Not to mention, spoils the user experience and, well, that’s the worst thing you can do. With the scaled design-thinking framework, you can reframe the problem, create some distance from it to clear your head, then experiment and explore possible solutions. In the end, you might come up with the most innovative solution yet.