Documentation Insights: My Derivation of a Design Thinking Technique

While I can never understate the importance of documentation standards, its inspiration or source is often overlooked. Today, organizations have their own sets of guidelines. So, when my manager asked me to create a set of guidelines for my team, I took to it with the utmost consideration. I realized later that the care I bestowed upon creating the standards itself underpins the very core of our everyday tasks. Thus began this little journey of experimentations and revelations.

The Problem(s) at Hand

Creating or having documentation standards isn’t the challenge; ensuring their adherence and relevance is. So, yes, we had a relatively bigger problem at hand. However, the real problems lay much deeper into the layers of our existing processes, legacy documentation, and upcoming challenges. First, we had multiple sources of truth. That is, if it was even the truth — or if it was still relevant. And, second, none of us knew how we could align our tasks with the other teams. Our team was to document the stuff just as it was ready to be pushed out of the door. So, documentation was to be found on the priority list only AFTER the other things were ready.

I am a LUMA Practitioner. It is a design-thinking approach that lends you 36 insightful human-centered design methods. My first introduction to the technique happened briefly during one of our quarterly meetups. As our instructor lead us through his story, I realized how even in this case, the problems weren’t the ones at hand but the ones buried within the layers of their processes, tools, and challenges. Back then, he and his team followed British Design Council’s Double-Diamond — another human-centered design approach. Even though this method wasn’t a part of LUMA, I could immediately see its effectiveness in helping me resolve the problem(s) I had at hand.

The Technique and the Insights

For those who might not know, Double Diamond is primarily a team-driven activity that breaks down the thought process in waves of divergence and convergence. Each of the four stages, viz., Discover, Define, Develop, and Deliver, follows a pattern where the team members are required to either diverge or converge their thoughts. The idea is to discover the root of the problems and then brainstorm to derive a solution. Discovering the core issue, therefore, requires your team to diverge. But, Defining, which is the second step, requires your team to converge their thoughts and come up with the definition of just one of those core issues.

Those who want to read more about British Design Council’s Double Diamond, click here:

https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond

As I skimmed the Internet and continued to refine my ideas, a few things became clearer:

  • I was already past the Discover stage.
  • I, on my own, could continue to refine my ideas using this technique, even though it is a team-based activity.

I assumed that my understanding was at par — until that mental checkpoint, at least. So, now I had the right approach, intentions, and need.

The Derivation

To further align my thoughts with this approach, I revamped Double Diamond to create a version of my own. The new four stages, for me, were: Define, Design, Develop, Deliver. I categorized the first two and last two in pairs. And for each of the pairs, I came up with role-specific guidelines for both writers and editors. But before I talk about the actual guidelines, I’d want you to remember that the guidelines are specific to my team and might not necessarily apply in your case.

In the ‘Define and Design’ phase, I recommended that writers come up with the following questions for clarity:

  • What is your business proposition? Or, what problem do you solve with this product offering, tool, or solution?
  • Do you have time constraints? Or is this a project with a shifting deadline (an ongoing project), something that you might build on the go?
  • Where will we keep the content?
  • Who will remain the owner of the content?

For the same phase, the editors would ask questions like:

  • How is the product placed in the overall ecosystem? How does it interact with the other tools? Or, typically, how does the data travel from Point A to Point B?
  • How much ownership does the writing team have?
  • Who else is involved in the content finalization process?

In the ‘Development and Delivery’ phase, I recommended that writers lay stress on the relevance of content. To help writers build their understanding of the term ‘relevance,’ I broke it further into four points, each of which adds significantly to the content:

  • Critical relevance: The content should help readers survive through, or triumph over, the uncertainty, lack of information, or misinformation.
  • Contextual relevance: The content should be what the reader was looking for when they chose (yes, looking for information must be their conscious decision) to get to your content.
  • Emotional relevance: The content should help readers make decisions on their own, rather than we deciding on their behalf (unless we are recommending something).
  • Strategic relevance: The content should help them see the previous and the next steps. Or, it should help them see how what they are working on fits within the bigger picture.

For the same phase, the editors had to do relatively smaller yet more critical work. They were required to preserve originality.

The Conclusion

My version of the documentation standards is a five-pager Wiki that highlights time-critical information in a time-efficient way. It may not be perfect. Still, it does what it is supposed to do. Did we become better writers? No. But we most certainly became better readers (of the user’s thoughts, that is). We developed an empathy for the readers. We now understand their pain in a much better way. None of the stages diverge or converge, yet the phases make you think. And that’s enough for a better start. So long as we ask meaningful questions, we can hope to derive equally meaningful answers and insights.

The derived version of the Double Diamond approach aligns better with what I had on my mind. Three months down the line, I see that we can take care of a lot more work than we used to. In addition to ensuring consistency and reducing the efforts in edit iterations — which were some of the primary objectives — improving work efficiency turns out to be a bonus. I’d be curious to know if there is any such approach that you found helpful. Or if you, too, have a derivation for your reference?