Tags: os

Day two of An Event Apart San Francisco is finishing with a talk from Brad on design systems (so hot right now!):

You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.

I will attempt to liveblog the Frostmeister…

“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.

As Mina said:

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

A design system the story of how an organisation gets things done.

When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.

Brad’s going to talk through the life cycle of a project.

Sell

He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:

• Reduce technical debt—less frontend spaghetti code.
• Faster production—less time coding common UI components and more time building real features.
• Higher-quality production—bake in and enforce best practices.
• Reduce QA efforts—centralise some QA tasks.
• Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
• Useful reference—an essential resource hub for development best practices.
• Future-friendly foundation—modify, extend, and improve over time.

Once you’ve explained the benefits, it’s time to kick off.

Kick off

Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.

How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.

Plan

Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.

How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.

Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.

Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?

You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.

Design and build

Brad likes to break things down using his atomic design vocabulary. He echoes what Mina said earlier:

Embrace the snowflakes.

The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.

When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.

The design system informs our product design. Our product design informs the design system.

—Jina

Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.

So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.

It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.

The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.

Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.

You can bake best practices into your design system. You can make accessibility a requirement in the code.

Launch

What does it mean to “launch” a design system?

A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

—Nathan Curtis

There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:

1. Least integrated: static.
2. Front-end reference code.
3. Most integrated: consumable compents.

Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.

Consumable UI components need to be bundled, packaged, and published.

Maintain

Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.

A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.

—Nathan Curtis

What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.

That’s where design tokens come in. You can define your design language in a platform-agnostic way.

Summary

This is hard.

• Your design system must live in the technologies your products use.
• Look at your product roadmaps for design system pilot project opportunities.
• Establish code conventions and use tooling and process to enforce them.
• Build your design system and pilot project UI screens in a frontend workshop environment.
• Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
• Use semantic versioning to manage ongoing design system product work.
• Use design tokens to feed common design properties into different platforms.

You won’t do it all at once. That’s okay. Baby steps.

When I was travelling across the Atlantic ocean on the Queen Mary 2 back in August, I had the pleasure of attending a series of on-board lectures by Charles Barclay from the Royal Astronomical Society.

One of those presentations was on the threat of asteroid impacts—always a fun topic! Charles mentioned Spaceguard, the group that tracks near-Earth objects.

Spaceguard is a pretty cool-sounding name for any organisation. The name comes from a work of (science) fiction. In Arthur C. Clarke’s 1973 book Rendezvous with Rama, Spaceguard is the name of a fictional organisation formed after a devastating asteroid impact on northen Italy—an event which is coincidentally depicted as happening on September 11th. That’s not a spoiler, by the way. The impact happens on the first page of the book.

At 0946 GMT on the morning of September 11 in the exceptionally beautiful summer of the year 2077, most of the inhabitants of Europe saw a dazzling fireball appear in the eastern sky.  Within seconds it was brighter than the Sun, and as it moved across the heavens—at first in utter silence—it left behind it a churning column of dust and smoke.

Somewhere above Austria it began to disintegrate, producing a series of concussions so violent that more than a million people had their hearing permanently damaged.  They were the lucky ones.

Moving at fifty kilometers a second, a thousand tons of rock and metal impacted on the plains of northern Italy, destroying in a few flaming moments the labor of centuries.

Later in the same lecture, Charles talked about the Torino scale, which is used to classify the likelihood and severity of impacts. Number 10 on the Torino scale means an impact is certain and that it will be an extinction level event.

Torino—Turin—is in northern Italy. “Wait a minute!”, I thought to myself. “Is this something that’s also named for that opening chapter of Rendezvous with Rama?”

I spoke to Charles about it afterwards, hoping that he might know. But he said, “Oh, I just assumed that a group of scientists got together in Turin when they came up with the scale.”

Being at sea, there was no way to easily verify or disprove the origin story of the Torino scale. Looking something up on the internet would have been prohibitively slow and expensive. So I had to wait until we docked in New York.

On our first morning in the city, Jessica and I popped into a bookstore. I picked up a copy of Rendezvous with Rama and re-read the details of that opening impact on northern Italy. Padua, Venice and Verona are named, but there’s no mention of Turin.

Sure enough, when I checked Wikipedia, the history and naming of the Torino scale was exactly what Charles Barclay surmised:

A revised version of the “Hazard Index” was presented at a June 1999 international conference on NEOs held in Torino (Turin), Italy. The conference participants voted to adopt the revised version, where the bestowed name “Torino Scale” recognizes the spirit of international cooperation displayed at that conference toward research efforts to understand the hazards posed by NEOs.