Designing the future of documentation

I was GitBook’s first full-time product design hire and helped build a complete new UI for the product before becoming Head of Design and building out a team of lovely, incredible designers.

Git-style workflows for docs

The main premise of GitBook was to bring the branched content and procedural rigour of Git-style workflows to written docs. While technical folks had spent decades already with this paradigm, folks writing ‘standard’ documents like product docs, support guides and FAQs were left with

A structured document format

The heart of GitBook was a structured, semantic, block-based document format. This allowed us to represent documents as structured data and transform it on the frontend based on our own internal components.

This was essentially declarative UI before declarative UI became cool, and a huge part of designing GitBook was designing the various permutations of blocks and content that could exist in the editor.

One of my favourite achievements at GitBook was making an editor that was doing so much behind the scenes just feel intuitive to use. A huge selling point of good design to me is the ability to simplify complex systems without limiting access to what actually makes those systems powerful.

This was a running principle throughout all GitBook product lines and features. If we can abstract it out so it’s usable, without stymieing the capabilities of any underlying system, we’ve done a good job.

Change requests

The headline feature I worked on at GitBook was change requests; essentially a combination of branched content and pull requests from the world of Git.

Change requests allow editors to edit away from ‘production’ content in a protected branch. These branches are live-collaborative, so you’re not losing out on any multiplayer fun while you’ve branched away.

Once you’re happy with the content of your change request, you queue it up for review and eventually get it merged.

Spine: the GitBook design system

A huge chunk of my time at GitBook was spent building and maintaining our design system. For the first launch of the ‘new’ GitBook, we made a few trophy attempts at pulling a design system together, but every ounce of effort went into launching as well as we could.

With the post-launch breathing room and a new era of documentation out the door, I got to work on the first version of Spine, the GitBook design system.

Spine was a Figma-first design system—something which I’d change if I could go back and start again—and was actively maintained (perhaps it still is?) with a federated governance model. Eventually, we’d have a kind of designer-rotation, where someone would always be working on design systems stuff for a cycle or two.

Spine started as something rough-and-ready, barely a component library, but by the time I’d decided to leave GitBook, was a fully-fledged design system, empowering faster delivery, more accessible defaults, and consistent improvement.

Fostering a fabulous team

My absolute favourite part of GitBook life was building a design team there. I hired and led several designers with diverse skillsets, and each one elevated

I’m a good people manager, and the biggest takeaway from my time at GitBook is how good it can feel when things click in a team full of humility, humour, and extraordinary talent.