Painting With Code

crossposted from the Airbnb Design blog

Today, we’re excited to share a tool we built to help bridge the gap between designers and engineers working on design systems at scale. react-sketchapp ↗(opens in new tab) is an open-source library that allows you to write React components that render to Sketch documents.

If you’re a designer or an engineer familiar with React, you should feel right at home with the new library, and you can play with it right now ↗(opens in new tab).

Here are some fun things we’ve already started doing with it:

Seamless integration with your data

Bring real data to your designs — including traditional APIs and GraphQL endpoints.

Layout with flexbox

Because React Sketch.app uses flexbox, its components can have the same rich layout as your real components. No more dragging rectangles by hand — everything works like your target layout engine!

Automatic internationalization

We’re an international company, with users in every corner of the world — it’s vital that our designs work well for everyone. Our design tools should enable us to think beyond our native languages.

So, why did we want to put React in Sketch?

Sources of truth

Design systems allow designers to reuse styles, components, and patterns, which in turn gives them time to focus on higher-level thinking. A good design system also empowers engineers to confidently implement new features without relying on redlines or back-and-forth pixel tweaking with a designer. And yet, comprehensive design systems in large organizations can introduce their own growing pains. In our case, one of our bottlenecks was in our Sketch templates.

I’m a big fan of Airbnb’s design system, DLS ↗(opens in new tab). It starts with common primitives — typography, color, and spacing — and grows into a rich library of components that work across platforms, screen sizes, and languages.

Of course, a design system is never complete. We’re constantly adding to DLS, changing existing components and optimizing it to make it usable by everyone in the world.

For each change or addition to the system, a cascade of work is created. Documentation has to be updated, each of our apps’ code has to be changed (in Swift, Java, and JavaScript), and Sketch templates have to be redrawn. These efforts have to be coordinated, and each source must always be in sync with the others.

Code is relatively easy to tie together, and we already have an infrastructure that allows for version control and continuous integration of our applications. Until now though, maintaining Sketch templates relied on manually-intensive human touch points.

Due to how design systems are composed, changes have to be tracked to see how they affect the system — changing a color reference might affect dozens of components. Each component must be redrawn to respect line-height and spacing. Niceties, such as converting colors for display in different formats, annotating specs, and calculating color contrast ratios for accessibility, all increase the potential for errors and inconsistencies. Graphics-based design tools are notoriously bad at version control. All these moving parts left us frequently uncertain about the state of the system. Questions, such as “What’s the font size for titles on mobile,” “Is this still what this component looks like,” or How does this component work on different screen sizes,” were all too common around the office.

These problems compound as organizations grow. What is fixable instantly when a freelancer designs and codes everything alone is a frustration for a three-person design team. Likewise, the inefficiencies that a medium team can roll with are catastrophically wasteful to a team of our size. Pruning human touch points from DLS is foundational to ensuring we can grow into an even more effective team in the next few years.

Using the real thing

I’m obsessed with the tooling principle of just using the thing itself. A designer’s workflow in Sketch is actually pretty similar to using React components: she picks a component, and puts data in it. In Sketch, we use symbols and overrides, in React we use components and properties. The concepts are so similar that it seemed silly not to unify them.

We also wanted to minimize sources of truth. Why keep a separate library of components drawn by hand in Sketch once we have them implemented as the real thing used every day by millions of people?

The fewer sources of truth we have for a design system, the more efficient we are.

“Many hard problems are best solved when they are addressed backward.”
— Charlie Munger, Vice-Chairman of Berkshire Hathaway

Design tools that seek to produce production-ready code are as old as the internet. As the industry has coalesced around Sketch, people have sought to generate code from Sketch. This is exciting, but for our challenges we wanted to do the exact opposite — to keep DLS in sync we have to generate Sketch files from code.

Having built several internal tools on top of Sketch in 2016, we knew the potential of scripting it to manipulate files as we wanted. However, its programming language, CocoaScript, isn’t the most familiar to most developers, and we wanted to be able to fully embrace the power of modern JavaScript to quickly and intuitively create documents.

“React is such a good idea that we will spend the rest of the decade continuing to explore its implications and applications”
— Guillermo Rauch ↗(opens in new tab), founder of ZEIT

At Airbnb, we’re big fans of React.js ↗(opens in new tab). It’s the perfect paradigm for thinking about and building componentized design systems, and we use it for large parts of our web and mobile applications. React is a much bigger idea than any one platform though — as well as the familiar React and React Native implementations, there have been interesting projects using the same principles for virtual reality ↗(opens in new tab), blinking LEDs ↗(opens in new tab), music synthesizers ↗(opens in new tab), and terminal applications ↗(opens in new tab).

React as a paradigm is perfect for wrapping the complexity of underlying platform APIs and providing consistent and smooth tools to the developers using them.

The adjacent possible

“The strange and beautiful truth about the ‘adjacent possible’ is that its boundaries grow as you explore them. Each new combination opens up the possibility of other new combinations”
— Steven Johnson

Over dinner on a rainy San Francisco evening, our team posed the question: “What if we used React to write Sketch files?”Shortly thereafter, we ended up with a pretty good proof-of-concept React renderer. It was perfect for laying out color swatches and type specimens, but we hadn’t yet figured out how we’d use it for more ambitious documents.

Using Sketch-style components, such as <rect>, <circle>, and <line>, meant we’d have to recreate each DLS component to be able to draw it to Sketch. While faster at scale than creating by hand, it was still (programmatically) drawing a picture of the thing rather than just using the thing. We’d inadvertently removed one source of truth and replaced it with another!

A breakthrough came when Airbnb engineer Leland Richardson proposed using React Native-style components. <View>, <Text>, etc. are the basic units of composition for design systems, so that semantically linked our Sketch components with their production counterparts. More excitingly, with Leland’s React Primitives ↗(opens in new tab) project we could render real React components to Sketch, the browser, and our phones at the same time.

We began the project to reduce the time it takes to generate static assets. But through exploring its edges and adjacent possibilities, we’re unearthing exciting and novel ways of interacting with design systems in Sketch. Many tasks that were previously unfeasible, required massive human input, or relied on sketchy (sorry) plugins are now enabled with the same code that our engineers are writing day-to-day.

By lowering the bar for Sketch compatibility, we also open ourselves up to new and exciting experimental tooling, tailored to our workflow. We can prototype the smarter design tooling of tomorrow while maintaining full compatibility with the software that our team uses today.

Moving forward

“We’re investing in code as a design tool. Moving closer to working with assets that don’t only include layout and design, but also logic and data. This helps bridge the gap between engineers and designers, thus reducing the need for design specs–or redlines–and the steps between vision and reality”
— Alex Schleifer, head of design at Airbnb

The project wouldn’t have been possible without deep contributions from the community. Thank you to Andrew Pouliot ↗(opens in new tab), Mathieu Dutour ↗(opens in new tab), and countless others who wrote code, reviewed pull requests, played with demos, and wrote documentation. We’re excited to open source our work, and we look forward to more collaborations in the future 🙂

We hope you enjoy using React Sketch.app ↗(opens in new tab) as much as we do. We’re still in the early days of figuring out all its possible applications, but it’s already a great tool for wrangling design systems at scale, using real data, and bringing design and engineering closer together.

We’re excited to see what you make with React Sketch.app — feel free to reach us by email with feedback, thoughts or suggestions. And if these projects sound interesting to you, our design tools team is hiring Design Technologists in San Francisco 🙂