A playbook about playbooks

At the risk of becoming way too meta over here, let’s talk about how to write useful playbooks without it taking over your life. I’ve done this a few times now, and am happy to share what I have learnt. I would also love to hear from you what you have found works well and what to avoid!

Photo by Christin Hume on Unsplash

Let’s start with the basics — why?

It’s the first step to enabling scale

Taking information out of an individual’s head and placing it an easily accessible format means you remove that information bottleneck. People don’t have to know who to ask, nor wait for that person to get back to them with the information they need. Documenting the information also means the information sharer doesn’t have to constantly repeat themselves, which save them time and effort. And, of course, it also means you have a ready to go structure and content for onboarding new team members with minimum confusion or fuss.

It enables accountability

Everyone is now quite literally on the same page, which means they can be held responsible for aligning with expectations. This is table stakes for things like data governance and legal compliance.

It’s an eye-opener

As you document the processes used by the team, you will uncover some messy bits or contradictions that are ready for you to resolve. So if nothing else, as an ops specialist, putting a playbook together is a very valuable activity in getting to grips with the status quo.

What should you include?

For me, a playbook documents the HOW we do what we do. It’s not a replacement for training or professional skills development that teaches the core skills and fundamental principles of a discipline, it’s an operational guidebook that explains the process for doing the job in this specific context. This means it does include things like the business context and culture of a team or group, as that very much informs the how we do what we do! The playbook outlines what we expect from everyone in doing a certain thing.

For example: In the playbook, I will cover how we do usability testing in this company, including what tools we use and how to get access to them, where to find training on the tooling, how to recruit participants, what templates we use, etc. But I will not cover when you should do usability testing vs using another research method. That I leave for the research training program and the professional researchers to advise on.

To help me clarify the playbook structure, I ask myself the following:

• What is it I’m getting the most questions about? Let’s document the answers. I start with bullets or short notes, adding more detail later.
• What are the key steps in the workflow? Think about what your team does in their end to end process, step by step in order, and document those steps. This provides the structure for the playbook itself.
• What are the bare minimum essentials my audience will need to know to do these tasks successfully? That’s where the focus should be — additional context and nuances can come later. Be clear about who you are writing the playbook for, as that will determine how much detail you need to go into. But as I said, always start with the basic steps or an overview, and then add detail later.

Who should be involved?

Outsource and ask for help — once you’ve provided the structure, others can help you develop the content, especially if you are new in your role or in the team and don’t actually know the answers. This also means the playbook will document the present reality, which is very important. It’s so tempting to pause and rush to first fix the messes you uncover, but this means the playbook will never get done. Make a mental note, and carry on (unless it is a compliance dealbreaker, of course).

Documenting the mess can in fact be a great strategy, as it gives you
a really nice “before” to compare against once you’ve completed
a few projects.

Where should the playbook live?

It really doesn’t matter! Look at what is already popular in your context for knowledge sharing or referencing, and use that. You will have enough work on your hands getting the playbook ready, don’t also add onboarding a new tool or knowledge base to your task. So use existing tools, locations, and formats. As this is where people already are active, it will also reduce the barrier to entry and ease adoption.

How should you write it?

Break it up — add sections with clear headers so it’s easy to scan through and for the team to get to the relevant bit they need when they’re in the middle of the process. (This also makes developing the content less daunting.)

Optimise for clarity. Keep your sentences short, use bulleted lists, make sure you’re using the active voice and your sentence are direct. Unless your context specifically dictates otherwise, keep your tone light and conversational.

Link to existing content, don’t replicate it. If something already exists that makes your point, reference that. If the tool you are using has great onboarding or training content available, link to that, don’t rewrite it. Otherwise you will be on the hook for syncing your content with these other sources constantly.

Use visuals to break it up and cater for more learning styles: things like flowcharts, process maps, illustrations. BUT! Avoid screenshot by screenshot type of content / instructions: these tend to become outdated fast as products develop and UIs change, and you’ll spend your life redoing them (see above). Rather link to the how-to content provided by the tool. Make it easy to maintain your playbook.

Use checklists and embed templates or the links to them. I often start with a checklist as the introduction, then a more detailed overview of the step by step process. The checklist becomes a really handy reference for everyone, from the more tenured who know how things work, to the new starter. And the templates give everyone an added incentive to refer to the playbook, as these will save them time.

Get feedback as you go, section by section. Can your team find what they need? What’s missing or confusing? This not only helps improve the content, it also keeps people engaged in the process of developing the playbook.

When should you do it?

Right now! Just get started. Start small with your commonly asked questions and rough bullets, and then expand. Developing a playbook is all about iterating — writing, then editing, then updating, then tweaking, then doing it again. So just get started now.

BUT! You will need to step away at some point, so you can go and fix those messy processes you’ve uncovered. So have a clear end date in mind and stick to it — you can always make edits again later.

Once the playbook is written

Once you’ve published your playbook and spread the word about it, you need to make sure it is successful as an ongoing source of truth. This means making sure it is embedded in people’s habits, and that you have a plan for keeping it accurate.

Link, link, link

It’s so tempting to answer a question directly — don’t. Send them the link to the playbook and ask if they can find the answer there. This is a great way to gather feedback on the structure of the playbook and the content itself. If it’s not actually in the playbook yet, answer the question and then add that response into the playbook. Remember that you are asking for a change in behaviour, so be prepared to go through many rounds of sending the link and reminding people to check the playbook first. It will pay off.

Share updates

Make your playbook easy to maintain and keep up to date by democratising edit access to the content. Make it clear that ops will own the playbook as an artefact, and will do final edits or make the call on the content overall(as you are the one making the final call on the processes, after all!), but that the content itself can and should be updated by the team (you may need to define team). I always say: If you spot a mistake, please fix it. If something is missing, please add it. Of course not all topics are suitable for this, and not everyone has the time or inclination, so it might be helpful to set up a backlog of sorts where you can gather all suggestions for improvements or additional topics.
I find it helpful to set up a cadence to not only review the playbook as a whole and make sure it is up to date, but also to tackle some of the suggested improvements or additions.

Go meta

Document your own process too! I’ve currently got four levels of playbook going: one for the whole UX team, one for the team managers, design and research specific playbooks, and then an ops playbook. This means you will be able to go on holiday with peace of mind, because you know you’ve written down your own processes so that others can follow them while you are away.

Don’t be discouraged. It can be quite lonely, working on a playbook — and playbooks are never completely done. You can feel invisible and like no one cares. But this is a long-term play, and it will reap massive benefits for scalability, accountability and in helping you streamline processes. It will always pay off when you onboard new team members! So take a deep breath, and dive in. You won’t be sorry you did.

I’m curious, what have you learned in developing your playbooks?