Light Machinery

A note on designing design systems, designing zeroheight, and keeping the machinery around the work as light as possible.

Jan 2018 • 800 words

One of the stranger things about designing tools for design systems is that they somehow want to become heavier than the thing they're trying to support. A style guide starts as a place to explain components, then suddenly it wants team management, permissions, branches, history, comments, downloads, Slack plugins, brand colours, account settings, templates, and structure to decide what happens in a team of 1 all the way through to a team of 10,000.

Some of it is useful (an optimistic way of saying inevitable). But the hard part is knowing when the work of operating this encumbers actual business outcomes. 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 to get things done because that was apparently the most direct route between the idea in my head and the thing I wanted people to use. It wasn't elegant in the way people mean when they talk about elegant software. But it did the job, and I had fun making it.

The idea behind all of it was basically the same: get rid of repetition, communicate design decisions in the language of engineers, and let people get back to actually measuring impact rather than debating border radii. Atomic CSS helped because it made it obvious what class did what. Build pipelines helped because they turned a messy set of manual steps into something formulaic. None of this was especially romantic, but it was useful, which is the point I think a lot of people miss.

Designing ZeroHeight recently made the same problem visible from another angle. It was not a case study, exactly, and I am not sure I want to write one of those. But it was a good example of the tension. The product sits close to the Sketch, and tries to turn what is inside those files into something a wider team can understand. It sounds simple, but very quickly you get into questions about source of truth, versioning, comments, inviting collaborators, downloading assets, creating pages, syncing libraries, updating components, and deciding where settings should live without turning it into a graveyard.

The temptation is to solve all of that by adding more. Another modal. Another onboarding step. Another explanation. Another empty state with an illustration and a paragraph trying to make the user feel good about being stuck. I don't think that is always wrong, but I try to stop myself whenever I catch myself doing it. Forced education often feels like a symptom of a product that has become too complicated too early. If someone has just connected a Sketch Library, the first thing they probably want to do is organise it, label it, invite a teammate, and make it useful. They do not want to sit through a guided tour of another company’s philosophy on design systems.

That was the useful constraint in the zeroheight work. Keep it light. 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 a new 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. Most of the decisions were small, but together they decided whether the product felt like a tool or a system for managing the tool.

I think this is where a lot of design system work gets itself into trouble. The ambition is usually good: shared language, reusable parts, better documentation, fewer strange one-off decisions. But the structures around that ambition can become very heavy very quickly. A system that exists to reduce friction can introduce a new kind of friction. A style guide that exists to create clarity can become another place where people need permission. A process that exists to protect quality can quietly become the reason nobody updates anything.

So, it's better to be careful about where the weight goes. Put the structure where it creates leverage and hide it where it gets in the way. Let people stay inside the tool they are already using when the task is small. Make the important things obvious. Make the repetitive things boring. Make the system feel like it is helping the work move, rather than asking the work to justify the system.

That is the thread I'm seeing through Sass files and Gulp tasks to Sketch plugins and style guides. Small teams do not need more ceremonies. They need just enough tools to make good work repeatable, and not so much that the process becomes the thing everyone is maintaining.