I wrote this in 2026 about work from 2015 to 2018.

A style guide rarely stays a style guide for long. It starts as a place to explain components. Then somebody asks for team management, permissions, branches, history, comments, downloads, Slack plugins, brand colours, account settings, templates, and a structure that works for 1-thru-10,000 people.

Some of it is useful (an optimistic way of saying inevitable), but every new layer becomes another thing the team has to maintain. In 2015 and 2016 I was building atomic CSS frameworks with Sass, then wiring them into Gulp and Grunt pipelines so teams could generate consistent interfaces without writing the same thing over and over again. Before I discovered Sass, I wrote a PHP compiler because that was apparently the most direct route between the idea in my head and the thing I wanted people to use. It did the job, and I had fun making it.

The point was to get rid of repetition. I wanted to express design decisions in language engineers could use, then get back to measuring impact instead of debating border radii. Atomic CSS made each class's job obvious. Build pipelines turned a messy set of manual steps into repeatable ones, and I liked it because it was understandable, had a shallow learning-curve, and was ultimately useful.

My work on Zeroheight exposed the same problem at product scale. The product was tied to Sketch and turned what was inside those files into something a wider team could understand. It sounded simple. Then we got into source of truth, versioning, comments, inviting collaborators, downloading assets, creating pages, syncing libraries, updating components, and deciding where settings should live without turning the product into a graveyard.

The temptation is to solve all problems by addition. Another modal. Another onboarding step. Another explanation. An illustrated empty state with a paragraph trying to make the user feel good about being stuck. Sometimes that helps. But often, forced education means the product has become too complicated too early. If someone has just connected a Sketch Library, they probably want to organise it, label it, invite a teammate, and make it useful. They do not want a guided tour of another company’s philosophy on design systems.

It became the useful constraint in the Zeroheight work. Let the hierarchy do some of the work. Top nav manipulates the header, header manipulates the sidebar, sidebar manipulates the main content window. Avoid modalception. Make the no-libraries state clearer before inventing an illustration. Give people a big obvious “Create new” when they already have a style guide. Let settings become more powerful over time, but do not make the whole product feel like settings. These small decisions made zeroheight feel more like a tool and less like software you had to manage.

Looking back, there is a very clear thread through Sass files and Gulp tasks to Sketch plugins, style guides and design systems. Small teams need just-enough-tooling to repeat good work. Once maintaining it becomes the work, something has gone wrong.