Writing Knowledge Base Articles from Reading Board Game Manuals

Almost everyone has played a game in their life. Maybe it's Candy Land or Chutes and Ladders as a kid, Spit or card games in grade school—or perhaps you're royalty of D&D. For me it was always Parcheesi with my parents on Friday nights and now you can find me roleplaying Pathfinder or some other game on Roll20 with my friends.

No matter what you've played board games are an almost universal language. Despite nearly everyone having played a game it’s not obvious how they’re connected to customer experience. Most people don't think about their day-to-day work helping customers when they're trying to relax. But reading board game manuals can be informative when you’re figuring out tactics for writing documentation and how-to guides.

Not so convinced? Read on to hear more about what I learned from reading board game manuals throughout my career as a gamer and how I applied them to documentation.

Make it Engaging

Have you ever started reading the guide for a game and felt your eyes glaze over immediately? Take for instance this beautiful but dense and uninformative guide on Kanagawa. You get started expecting to get an overview of how to play, only to realize you have almost 12 more pages to read before you can even begin. Imagine customers experiencing that same thing when they read your documentation. Yikes!

When conceptualizing documentation I try to keep it exciting and engaging rather than just getting all of the information out. So instead of writing:

This feature is built for understanding the engagement that your customers feel with your product. You will be able to understand what your customers are reading, how often they read it, and if they are sending it to anyone else.

I might write:

Understanding ROI is important! Luckily, we've built a feature to help. [X feature] is specifically designed to give you superpowers: you'll have deeper insights into what your customers are reading, how frequently they're reading it, and if they're sending it on to any of their friends!

The first is snooze-worthy but the second makes your customers feel compelled and excited about the product. Which would you rather read? Instead of dumping all the instructions on a customer at once empower them to get up and running and then move into more detail as needed.

Help Highlight Your Product

Without a guide your product is pretty shapeless—especially if you’re managing a SaaS product. If you don't give your customers any instructions on using the tools you're providing you can expect them to run into problems or use it completely differently from how you intended.

The same goes for board games: you can’t expect your customers to know exactly how to play something you created. Instructions give them a better understanding of how you want them to engage with your game.

Before I start writing any docs I try to understand the intention behind each piece of the product, know what the goals are behind its usage, and exactly how my product team envisions our customers using it. Then I write my docs comprehensively to guide our customers in the right direction towards maximal product effectiveness.

Here are some strategies I use to understand how our product fits into our customers' lives:

Dogfooding the product which means using our product in the same way that our customers do.
User testing
Analytics around product usage
Customer journey mapping or mapping out all of the various touch points that a customer goes through with our product
Reviewing NPS, CES, and other customer satisfaction survey metrics to understand how customers feel about our product.

Once I write and post the documentation our customers are ready to read it. So I have to be sure to get the intention and mission around the product clear before I start writing or publicly pushing it. I tend to view our documentation as one of the most critical features of a product's success. I try to keep it updated regularly and stay focused on the best practices when it comes to product features.

Play-testing is Key

When I get the opportunity to play-test a game I intend to find all of the weird, wonky bits before it goes live. The same thing goes for our product and documentation.

Before I get into writing your docs I make sure I’ve put our product through its paces. When going through our product and trying to use it in every different way, I tend to give my team a more in-depth perspective into all of the use cases that customers may bring to the product.

Different individuals on the team will have different perspectives. For instance our sales team may find things in the sales or billing process that they do differently from someone in support. On the flip side our support team can usually catch customer-facing processes differently than someone, say, on engineering.

As I start writing I try to remember all of these experiences and write with them in mind. The more departments I can encompass and address in our documentation, the better an experience we’ll provide.

No two people are going to use a product the same way automatically. I try to avoid writing documentation that assumes they will.

Give Potential Scenarios

When reading a guide for a game—especially one that encourages players to roleplay—there are usually playable scenarios and standard ways to approach the game.

For instance here's a demo scenario from a popular RPG Gloomhaven. These demos are usually a more approachable, easy-to-get-started version of the regular game that introduce the game's fundamental concepts before getting into too complicated a scenario.

Documentation, templates, and walkthroughs serve the same goal: they help users learn the basics and get started quickly. By considering which aspects of the product are most important for users to get up and running successfully it’s easier to give them the tools to do so. In-app messaging, videos, and documentation are great ways to teach users how to get started.

Get Them Hooked Quickly

There will occasionally be an "easy" version of how to play the game and then advanced mechanics that you can add as you get more familiar with the rules. Start slowly and let players level up at their own pace to prevent people from quitting at the very beginning. Layer on additional guidance as your players progress to ensure that the complexity of instruction matches their skillset.

The templates and walkthroughs mentioned above are a great way to get users interested and excited about using the product too. The most important thing about a game or a piece of support documentation is not to intimidate the user before getting started.

My advice is to start your docs off with easy instructions before diving into the difficult or challenging aspects. When you give them an easy task to start, you let them get warmed up and feel like they are used to the product. That way the more challenging aspects of the issue they're trying to resolve do not feel as overwhelming.

Roll for Initiative

Conceptualizing and creating documentation can be intimidating. Whether you're doing a revamp of your current docs or are just trying to figure out how to move forward with sketching out your future docs taking these lessons from board game guides have helped me set off on the right foot.

Just like a board game you can use documentation to excite people about your product:

Highlight the key features that will be important to them and make them easy to understand. Give your users a simple overview just like you’d want in a “quick start” guide for a game.
Engage your users rather than flooding them with information—people get overwhelmed by a guidebook that’s hundreds of pages long.
Set them up to understand the easiest and more straightforward way to use your product, and then let them pick their adventure.

Your users are going to love it.

This post was created in cooperation with Nicereply—the customer satisfaction tool for Front.