All the ways to use a Design API

In the last chapters, we've been through practical examples about how to use a Design API to connect designers and developers. In this chapter we'll go deeper and explore together the myriad of possibilities offered by a Design API.

What you can do with a Design API

A Design API is flexible: twist it according to what you need

A Design API connects all the teams consuming a design system by the tools they use daily. Thanks to these connections, all teams can easily use an organization's branding that is always up-to-date.

A Design API offers a new kind of flexibility for product teams. Teams can use a branding which is always up-to-date by configuring the Design API to automatically collect and distribute design data.

A Design API will store in an external source of truth your organization's branding. Consider a Design API like a central database containing design data. Like in any database, data can navigate in different ways depending on the relationship models you setup.

There are 3 different database relationships:

1. One-to-one (1:1) relationships
2. One-to-many (1:N) relationships
3. Many-to-many (N:N) relationships

Those relationships will help you connect the Design API to as many teams and tools as you want.

Use cases

Use case 1: Updating design decisions in a design tool to update a code repository (1:1)

The first idea that comes in mind is to update design data from design to code. Like updating a color palette to automatically update coded colors in a code repository.

Use case example: Updating colors in Figma to automatically update colors in a GitHub repository

Workflow using Specify:

1. Designers update colors in their Figma file
2. Specify automatically synchronizes your repository containing your colors collected from your Figma file
3. Specify automatically distributes your colors in your configured GitHub repository

Use case 2: Updating design decisions in a design tool to update several code repositories (1:N)

Let's say your organization has:

• a marketing website
• a web app
• a component library in Storybook
• an Android app
• an iOS app

Then a Design API like Specify would allow designers to:

1. Update design tokens and assets in Figma
2. See changes updated components inside Storybook
3. Validate those design updates and automatically make them available for every platform (web, Android, iOS)

Use case 3: Updating design decisions from several design tools to update several products and tools (1:N)

This use case gives you a glimpse of what will be possible in the next decade.

Let's deconstruct it together 🔎

"Update design decisions from several design tools..."

Nowadays, getting design data out of design tools like Figma, Adobe Xd or Sketch is the norm. But those tools are mainly focused on interfaces and components. Basic design tokens like colors, text styles, shadows or gradients are supported. More specific design decisions like borders, dimensions or breakpoints are not.

Specific tools helping designers and developers get UI in the user's end environment already exist. Some help you create shadows (Josh Comeau's Shadows Palette Generator) in CSS. Others like ColorBox or Leonardo help you define colors palette. And others like Type-Scale help you create type scales. Finally, you could even use Ableton to create sounds used in your branding like Slack do for their notifications.

What if you could create design decisions from anywhere you wanted while striving for brand consistency?

In short, at Specify we believe you should be able to use any tool you want to create design decisions.

"...to update several products and tools"

Your organization's branding is used in many different places: design tools, prototyping tools, websites, mobiles applications, email signatures, CMS themes, ads in the street, slides...

All the tools teams use to consume this branding must also be taken into account.

In short, you branding is used in many more places and ways you imagine. A Design API is the key to align your branding on every targeted mediums, platforms and tools.

Use case 4: Updating a color in a design tool to update several code repositories and slide templates

• PR created in Web app GitHub repository
• PR created in Android app GitHub repository
• PR created in iOS app GitHub repository
• component library in Storybook is automatically updated and deployed
• Styles library in Google Slide, Pitch and Powerpoint are updated

How Design APIs empower all brand architecture models

This topic is an opportunity to understand how design system can positively impact an organization's brand architecture.

First of all: what do we already know? We know design systems help reach brand consistency on a brand level. We know design tokens are at the core of every design system. Finally, we know many organizations are working hard setting up design systems to power all their different sub-brands.

What are multi-brand design systems?

Before diving in, we must ask ourselves one question: what does multi-brand mean?

A "multi-brand" organization is an organization owning several products and/or services that are all branded.

Many enterprise companies have a big product portfolio:

• Google
• Atlassian
• Microsoft
• Amazon
• Volkswagen
• General Electric
• Unilever
• P&G

And that portfolio might also stretch across multiple brands and platforms:

• Multi-Product
• Multi-Brand
• Multi-Platform

Several brands can live under the same roof. But how do we ensure a consistent experience across the whole product portfolio?

Within the same portfolio, how independant are sub-brands from one to another?

To sum things up, we have 3 different brand architecture models for multi-brand organizations.

Branded house

The Branded House model is also called the Umbrella Brand model.

In this model, the firm is the brand. It's a collective of complementary brands that cater to unique audiences but benefit from shared equity under the same umbrella.

All sub brands are inheriting from a parent brand identity. Some of them may have small identity tweaks or particularities but most of the brand can be reunited in a single design system. This design system will be strict. Component styles cannot be easily overridden to ensure brand consistency across all sub brands.

House of brands

The branding is focused on the subset brands. Subset brands benefit from a strategic or operational alliance, but may serve customers in different ways, without an obvious connection for the consumer.

Every sub-brand has its own audience, customers and market. All sub-brand differ on their typography, image art direction or even tone of voice. They don't have anything in common so the better way to handle their branding is for all sub-brands to have their own design system. Their design system's rigidity will vary from one sub-brand to another.

Hybrid

The hybrid model aims to incorporate elements of both the branded house and house of brands models to give each brand maximum advantage. Hybrid brand model is often the result of acquisitions.

This will be a mix of the Branded House and House of brands models. This is why, you'll find some organizations based on this model to have one or more design systems.

How brand models shape design systems

Whatever the brand model used by an organization, there is always a way to reach brand consistency.

Design systems are not monolithic applications. They are composed of different layers you can separate to fill the needs of a multi-brand organization:

1. Guidelines
2. Processes
3. Libraries

The main idea is to centralize as much materials as possible. According to the brand model the amount of centralized material will vary.

Let's see how different brand models can consume and shape a design system.

Branded house

Lots of layers are consumed by all sub-brands:

• Guidelines
• Processes
• Libraries

Specific elements like design tokens, components or patterns for a brand are in their own product library if necessary.

House of brands

Few layers can be centralized as all brands differ from each other. They all target different audience and market. In short, every brand will have its own design system. However, depending on the market of all sub-brands, some elements could be shared across different design systems. Those elements can be guidelines, processes, or even white-labelled components.

Hybrid model

Once again, it's a mix of the two previous model. This will result in a potential central design system consumed by several brands accompanied by as many other specific design systems as needed.

Some tips

• Use white labelled components to feed brand specific design systems or component libraries.
• Molecules and organisms can be independant if tweaking colors and text styles is not enough and your components layout differ from one brand to another. Apply your branding on atoms / molecules, and layout on high order components like organisms / layout / pages.

Conclusion

Your design system must support your organization brand model. Identify yours and shape your design system around it. It's obviously easier said than done. However, you must get the full picture to make your design system durable and trustworthy.

Resources

• How Design-Tokens Empower Multi-Brand Design Systems by Louis Chenais