Sticking to a design system: a tool to help designers and developers maintain the shared language

Good design is a language, and when everyone is speaking the same language, that’s when things get done. ~ Arjun Narayanan

What is a design system?

Also known as a design language, or UI library, a design system is really an extension of what you might know as a style or brand guide, into a series of design components for you and your team to reuse.

The Talis design system lives at http://design.talis.com/ and we developers refer to it often when implementing changes to our products.

Pain points

The hard part is actually sticking to your system, even as your product evolves and changes. Multiple teams are writing new code and designing new features, maybe in different programming languages and using different UI frameworks - at Talis we have many on the go! It’s tempting to think that the handover from a designer to a developer should be a uni-directional flow of pixel-perfect mockups. But that just isn’t realistic or advisable, because the design process should involve feedback from those implementing. This is both so that the development team get sight of the design roadmap before it’s set in stone to enable longer-term technical planning, and also so that problems, concerns, or the effect on work and time estimates can be voiced early. We talk about doing reviews of code at 30% and 90% in our Engineering Handbook, but we also try to follow that pattern for reviewing design and product work. We have found this goes a long way to reducing the friction of design handover, but it doesn’t completely alleviate the tendency for our products to drift from what’s set out in our design system.

A problem shared …

In October last year, I was given a scholarship to attend the Design Tools Hackathon 2018. (Thank you to Sketch who sponsored me!) There were around 80 participants from 15 different countries; a mix of designers and developers. The conference consisted of half a day of talks and then a day and a half of hacking. I had worried that as a developer I’d be out of my depth, given I hadn’t used many of the design tools involved, but it turned out that at a hackathon centred around extending design tools, developers who could hack together working prototypes were in high demand! If you’re interested, check out the recap blog post, which has recordings of all the talks, including on topics like “Design Engineering” and how to roll out a design system in a remote-only company. Bonus points if you spot me in the hack demos :)

Through brainstorming hack ideas, I found that many other developers and designers also confronted this issue frequently, and the tooling they had wasn’t really helping them stick to their shared language. I also discovered new tools I’d never used before and found some really powerful workflows that I felt were just scratching the surface of the common pitfalls in modern development teams.

One such tool is Zeplin, a connected space for product teams to handoff designs and style guides with accurate specs, assets and code snippets. The idea is that the designer uploads their designs from Sketch into Zeplin to make it available to developers to review and implement seamlessly. The app provides the developer with a list of CSS properties to style each element in the design. You can give it a go for free at https://zeplin.io/

While a list of CSS properties goes some way to helping you implement a design in code, it won’t necessarily correlate to your existing design system. What follows is a fiddly process of mapping the components and styles in the design, and generated by the handover tool, to ones already existant in your repository. Identifying any deviations from the agreed style guide at this point is crucial. Maybe there are new paradigms that need adding to your design system. Maybe there’s a change in the design that has gone unnoticed until now. As the person implementing the design, the developer is in prime position to validate it against what has gone before and catch any potential design debt.

Ultimately, the goal is DRY code (Don’t Repeat Yourself). In existing code bases with well established stylesheets, there are often many pre-build helper classes that are used to customise and style elements. Instead of adding more bulk to the stylesheet by creating entirely new classes every time you add new element to a page, you want to build your element using existing CSS classes.

…is a great jump off point for a hackathon

We theorised there was a better way! What if a tool like Zeplin could tell you exactly what components from your style guide were in use in a given design? What if Zeplin could tell you off the bat the classes you’d need to implement it? And which bits of the style fell entirely outside of your design system altogether?

This lead to our MVP: A Zeplin extension that, given a CSS stylesheet, compares the CSS properties in the stylesheet with the CSS generated by Zeplin and outputs a list of matching helper classes. Magic! You can check out our code on GitHub. Currently it requires you to bundle your stylesheet in with the extension, but once the Zeplin API is extended to allow, we’d like to give users a way to upload their own stylesheet and let the extension take care of the rest.

For more info on building Zeplin extensions, see the Zeplin extension documentation.

Systems are only as good as the people in them

Of course, tools don’t really solve problems - they optimize processes. The real solution comes down to the relationship between your design team and your development team and the quality of your communication. Getting buy-in can be hard, but I hope I’ve convinced you there might be ways of dismantling barriers to seamlesss developer/designer collaboration.