Learning from the “Lazy” Part 1
“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”
I am not lazy, I just don’t like doing more than I have to.
This is especially true for me at work.
Thankfully for my professional life, the qualities of a lazy person are ideal for the world of modern technical writing.
Why?
Because help systems can easily spiral into unmaintainable behemoths that are a total pain to update, and lazy people simply don’t want to be bothered with that kind of hard work. So we lazy writers are always on the lookout for was to avoid that drudgery.
My sloth naturally leaks into to my responsibilities as a Dungeon Master as well. As a player, you get to show up for a game and jump right in, yay! Not so for us poor Dungeon Masters, who spend hours upon hours preparing for a session, only to realize half of our content will never see the light of day.
Thankfully, there is a better way: the lazier way.
In this series, we will explore several tenets of lazy writers and dungeon masters that can make our lives easier.
Let Structure Do The Thinking For You
When tasked with explaining a complex feature to users, it is easy for your help article to become as lengthy and comprehensive as a Wikipedia article for the sake of ensuring you leave nothing out.
But that’s a waste of time.
For one, users aren’t looking for Wikipedia articles, they are looking for quick solutions to their questions and needs.
Additionally, you shouldn’t allow yourself (or team members) to approach documentation in such a freeform manner.
Instead, your help system should have a minimum number of clearly defined documentation types and each type should have an agreed upon function.
Clearly define your doc types, format and goals:
An excellent example of clearly defined types can be found in DIVIO’s docs, which break it down into four types:
Tutorials: learning focused documentation formatted as a lesson, allowing new users to get started.
How-to guides: goal-oriented documentation focused on solving a specific problem, formatted as a series of steps.
Reference: short and to the point, information-oriented descriptions that allow the users to understand terminology, key classes, functions, and API.
Explanation: understanding-oriented documents that take a wider view of the software and its features, real world uses, etc. The address the why, while how-to-guides handle the how.
Once defined, all documentation needs to be explicitly structured to fit the doc types, and they all must be kept separate and distinct from each other.
Trying to write why you should use a feature while also defining terms and explaining the steps for setup within a single doc is a recipe for a long, confusing doc, but this is all too common!
“Clear division makes it obvious to both author and reader what material, and what kind of material, goes where. It tells the author how to write, and what to write, and where to write it. It saves the author from wasting a great deal of time trying to wrestle the information they want to impart into a shape that makes sense, because each of these kinds of documentation has only one job.
The demands of each kind are different from those of the others, so any attempt at documentation that fails to maintain this structure suffers, as it’s pulled in different directions at once.”
Once your team has settled on doc types, templates should be created that speed up the writing process even more.
Using structure to write D&D campaigns
My quest to make DMing easier eventually lead me to a life changing book: The Lazy Dungeon Master by Michael E. Shae. Similar to the tenets of clear documentation types, Shae breaks the tasks of preparing sessions into easy to use worksheets. By using the structure of the worksheets, I can prevent myself from needlessly spinning my wheels creating unnecessary content.
An even more simplistic format comes from Guy Sclanders of How to Be a Great GM, simply answer the following statement for your own campaign: Someone wants something very badly and is having trouble getting it.
