Good documentation is invisible. When it works, nobody talks about it. People just move faster, make better decisions, and spend less time asking the same questions twice. When it doesn't work, you feel it everywhere: in the inconsistencies, in the duplicated effort, in the designer who's been here three months and still isn't sure where to find the right component. 

For a long time, we felt it. 

We had a home for our design documentation; a space embedded within a third-party brand management platform owned by our Brand team. It technically did the job, but it never really felt like ours. We were an add-on to someone else's infrastructure, limited in what we could do and how we could shape it. The gap between what we needed and what we had kept widening. 

So, we started asking a different question: what would it look like if we built exactly what we needed? 

The honest case for starting over 

We didn't take this decision lightly. We looked at the alternatives carefully, including off-the-shelf tools, other dedicated documentation platforms, and a fully custom, engineering-built solution. That last option was tempting. Maximum flexibility, complete ownership. But we'd seen how that story tends to go elsewhere. Long build timelines, a reliance on engineering for every update, and a site that slowly falls behind as other priorities take over. 

We didn't want to swap one problem for another. 

What we really wanted was speed, control, and the ability to keep things current without needing to raise a ticket every time. So, we started exploring whether AI could get us there, giving us something that felt custom without all the overhead that usually comes with it. We ran some proofs of concept, they went well, and we decided to go for it. 

The result is the Design Playbook. A documentation site designed by designers, for designers, with full ownership sitting exactly where it should. We built out templates and custom components, a mini design system running in the background, and used AI to support content writing and keep the experience consistent as we scale. 

What we built, and why it matters 

The Playbook isn't just a better place to put things. It's a different relationship with our own knowledge. 

When documentation lives somewhere you don't fully control, it quietly becomes aspirational. A record of how things were supposed to work, not how they actually do. You update it when you have time. You trust it less as months go by. Eventually people stop looking it up and just ask a colleague instead, which is completely understandable, but it's also a huge drain on everyone. Ownership changes that. 

That ownership also means the Playbook is shaped around how we actually work, not around the constraints of a tool we've licensed. We designed it from scratch, which means when we needed anatomy content blocks or best practice content blocks, we built them. When we needed custom page templates that reflect our design system rather than someone else's, we built those too. 

Every design decision is ours to make and ours to change. That might sound like a small thing, but it adds up. Off-the-shelf tools give you a structure and ask you to fit inside it. We built the structure around the work. 

"Off-the-shelf tools give you a structure and ask you to fit inside it. We built the structure around the work."

Thinking bigger 

Here's where it gets exciting. 

Partway through the build, we stopped and asked ourselves who else could benefit from this. Design documentation was where we started, but the opportunity felt bigger. Other disciplines had their own challenges, separate homes for their standards or simply no dedicated space at all. 

We had built something that could genuinely help. So we went to pitch. 

Every team said yes. 

Not all at once, but with a shared direction and a real willingness to come together. 

For Brand, it's a chance to consolidate under one roof, reduce tooling costs, and get the flexibility of a platform we can shape together. For Content, it opens up something we're really excited about. Rather than their standards living somewhere separate, content guidance can sit directly alongside design system components and patterns, right where it's needed. And for accessibility, the Playbook gives dedicated guidance a proper home, written specifically for our design community and easy to find when you need it. 

One place that brings together everything our organisation knows about how we design, write, and build. That's a big deal. 

It's hard to overstate what this kind of alignment means. Design teams talk a lot about breaking down silos, but this is a structural answer to that problem. Not a workshop or a working group, but a shared home that brings cross-functional collaboration one step closer together. 

The business case hiding in plain sight 

There's a version of this story where we kept this to ourselves. A better tool for designers, and more organised space for the design system. And honestly, that alone would have been worth doing. 

But the bigger picture is what really matters to us. 

When teams share standards, what we ship becomes more consistent. When accessibility guidance sits alongside design and content, it gets considered earlier and applied more reliably. When someone new joins the team and we can point them to one trusted place to get started, they find their footing faster. When senior designers aren't answering the same questions repeatedly, they can get back to the work that needs them. 

The Playbook is documentation infrastructure, yes. But more than that, it's what can unify the design function together. 

Consistency. Reusability. Craft and quality. Accessibility. Efficiency. These were the goals we started with. The Playbook isn't just a response to those goals. It's how we achieve them. 

Where we go from here 

Launching the Playbook isn't the finish line, and we know that. The real work now is in the content: building out documentation that's genuinely useful, comprehensive enough to be a true self-serve resource, and kept current enough that people can trust it. 

That's the focus right now. Making this the place people turn to first, because they've learned it gives them what they need. 

But we're already thinking about what comes next. Documentation has always been a fairly passive experience. You arrive, you search, you read, you leave. We want the Playbook to be something designers actively use, not just a place they visit when they're stuck. That means rethinking how information is consumed, not just how it's organised. 

One direction we're genuinely excited about is using AI to make the Playbook responsive in a way static documentation never can be. Imagine being able to describe what you're trying to design and having the Playbook tell you which component to use, which pattern applies, or which guideline is relevant. Not search, not browsing, but something closer to having the knowledge of the design system available on demand. That kind of capability has to be built around your specific system to be useful. It's not something you can get out of a box. 

Because we built this ourselves, we're not waiting for someone else to decide what's possible. We can move in whatever direction serves our designers best, and keep moving as that changes. 

We don't have all the answers yet. But we have the foundation, and for the first time, the control to go and find them. 

The Playbook started as a design team problem. It's becoming a company-wide answer. And that shift, from internal tool to shared infrastructure, is exactly the kind of impact a connected, unified design function can have. 

"The Playbook started as a design team problem. It's becoming a company-wide answer."

We're just getting started.