Pokémon GO and community documentation

Yes, I’m playing.

Even if you aren’t twitchily checking your phone and resisting the urge to run outside to catch a Pikachu or Gyrados, you’ve probably heard all about the phenomenon of Pokémon GO. One of the most common criticisms of the game is that the in-app documentation is sparse at best. In response, the community banded together and began to document their theories and findings. You can readily find articles covering “eeveelutions,” theories on how to more easily capture Pokémon, and how to capture opposing gyms. It hearkens back to a time of meeting up in schoolyards to swap tips and rumors.

This community-driven documentation has done an amazing job of bringing players together in the absence of official documentation. While this works for a game, you need to be sure that your own documentation does not force your staff or users into this behavior.

In QA

The heart of QA is documentation. While a QA department can get by on oral tradition and tribal knowledge, there’s always the threat of brain drain. Should the unthinkable happen and your QA guru is hit by the lottery, what happens to the testing and validation portion of your workflow? In the best case, you lose efficiency while your remaining QA staff attempt to formalize what was once a loose testing structure. In the worst case, your workflow grinds to a halt while your staff tries to create documentation where there was none before.

The same also goes for general internal documentation, including style guides and information on how to configure business-critical software.

In production

Perhaps there was a miscommunication between your development and tech pubs teams, or something was lost in building out documentation requirements. Regardless, having mis- or undocumented features in your products or services can be a major headache, both in dealing with the fallout and attempting to rectify the inconsistency. Unlike with games or other social media, your users probably won’t converge to do the documentation for you.

Taking action

So how do you try to prevent these issues?

For internal materials, consider using wikis or document repositories for storing critical information. Be sure that any information is easy for your staff to find. Having software licensing information or style guides stored won’t help you if no one can find them.

For external materials, have strong SOPs in place that govern how your content is reviewed before being published. You should also have some means to integrate feedback from users so that future publications can take real-world practice into account.