I made the case that custom tools leads to effective designer and developer collaboration. I also made the point that I’m not talking about just pattern libraries. Let me explain why.

Pattern libraries are a great resource for a company to have. They are an excellent resource for onboarding and reference for seasoned team members. This is where they excel; documenting the way we work.

What they don’t do is build our apps. Our websites. They don’t make our buttons or type styles. They don’t allow us to create, they allow us to display and to document.

A pattern library is great for showing the results of our work. They are the window into the capability of our tools and libraries. But on their own, they are inactive. They don’t move, they follow.

So what are these tools I speak of?

Frameworks

Frameworks. Libraries. People call them different things. They are the foundational pieces of software for your business software. Foundation is a Sass framework. Ruby on Rails is a Ruby framework. And React is a JavaScript framework.

Foundation works the way that Zurb work.

Ruby on Rails works the way that 37signals work.

React works the way that Facebook work.

Ruby on Rails and React, don’t have much to do with visual design. Yet, the way their respective companies work and think resulted in these opinionated tools. Opinionated tools that influence the way other people who use them, work.

Foundation. Bootstrap. Material Design. These are about visual design. They evoke the design thinking of the companies that birthed them. The way Zurb’s design team works influences how we work when we use Foundation. The way that Twitter’s design team thinks about interface design is in Bootstrap. And the same with Material Design and any other ready-to-go framework.

Go build your own Sass framework.

Codify the way your design teams think and work. Teach your developer teams how your design team works. They need to spend time with the designers to understand and then codify their systems. Your design team will also learn to understand how your developer team works. They will see how their design world translates into the developer world.

Codifying design systems

Great design teams, design systems. This makes the work everyone on their team does, coherent. It makes their body of work feel like one person did it. It makes it easier on their customers. They don’t have to relearn systems as they move through the product. Each section of the product is consistent despite having a different designer.

Design systems make a product more consistent. And it makes the design process for that product more efficient.

I believe great design teams should design systems. Not just big design teams.

There are many systems which you might recognise. A system of colours. A typography system. A grid system. A set of interaction rules (what swatch means “click me”). There are many others.

As a developer you might not think there’s too much going on here. Let’s look at colours. You don’t need to know anything more than “eyedropper”, right? Maybe you’ve gone as far as creating an associative array: a name for each known hex.

$colours: (
    darkgrey: #333,
    lightgrey: #eee
)

colour(darkgrey) // #333

But do you understand the scope of the colour pallete? What happens when a PSD arrives with a new colour? Do we just add to that array?

Can you look at a comp without an eyedropper and still build it?

Great colour systems are more than associative arrays of strings. They are well thought out. Colours should be used consistently for specific purposes. Take the time to understand how the design team uses colour. Try to codify it. This will make sure your design team have thought about how they use colour. It will also mean your developer team understands the system, because it is rational.

swatch(copy), swatching(titling) or swatch(framing) are much better than colour(darkgrey), and colour(lightgrey). Why? First, it’s much easier to know which swatch to use. Second, by studying the colour system you may have learnt something critical. You’ve come to understand that in one context, titles are the same colour as copy. But in other contexts (maybe a dark mode), they are different colours.

$swatches: (
    default: (
        copy: #333,
        titling: #333,
        framing: #eee
    ),
    dark: (
        copy: #ccc,
        titling: #eee,
        framing: #333
    )
)

swatch(titling); // #333
set-theme(dark);
swatch(titling); // #eee

We’ve taken colour systems as an example. The same thinking can be applied to typography, grid, animation, interaction and many more systems. Study them. Find the abstractions. Codify them so you can write expressive code. Write what the designers meant.

When we understand and try to codify design systems: we find rationality and order. Sometimes we even gain a deeper understanding of the seams of that system. We develop a shared vocabulary and way of speaking about our work. All which reduce the friction of getting from design, to build.

Up Next: The process of design

I talk about the design process that allows UX, visual designers and front-end developers to work at the same time without stepping on each others feet. Find out how to work in parallel »