Releasing Design Systems

Delivering Interconnected Outputs to Adopters Over Time

Nathan Curtis
Aug 28, 2018 · 5 min read

#1 of 6 of the series Releasing Design Systems:
Outputs | Cadence | Versions | Breaking | Dependencies | Process

Companies realize a design system’s value when adopting products use a system to make and ship experiences that their customers use. As a part of that value chain, the system releases features over time. This puts the system into the hands of its customer: designers and engineers doing their job.

Strong system teams take releases seriously. They don’t see themselves as releasing just component library code. Instead, they deliver many more outputs: design tokens, documentation, design assets, and other resources.

This series describes many facets of releasing design systems. It begins by defining a system’s many outputs and where they are delivered. Subsequent articles cover topics of cadence, versioning, breaking changes, dependencies, and a step-by-step approach.

These stories reflect what I’ve learned releasing systems working with teams like Discovery Education, Morningstar, Target, and REI. They are elevated by insights from colleagues at Salesforce, Adobe, Atlassian, Shopify and Financial Times. Thanks for graciously sharing your time and practices!

Outputs: What‘s Released?

Code, the Source of Truth

  • UI Component Library as HTML Markup & CSS. Often referred to as “the CSS,” this package’s consumption rests upon using or compiling CSS as a consistent visual style baseline coupled with reusing HTML snippets.

and/or…

  • UI Components Library as Javascript: Many systems wrap HTML & CSS with JavaScript to fortify logic, encapsulate style, and ease integration and maintenance more directly in a framework of choice. While most libraries target a specific framework (React, Vue, Ember, Angular, …), industry signals suggest a shift to making web components for all frameworks. My last six system efforts? Later 2017: Vanilla HTML, Vanilla HTML. Early 2018: React, Vue. Later 2018: Web Components, Web Components.

In addition, other prominent outputs may be released separately:

  • Design Tokens establishing a visual style via semantically meaningful property-value pairs. Tokens are variables available in many formats for use across platforms (web, iOS, Android), preprocessors (Sass and LESS), and frameworks (like React). Some systems manage tokens in a repository separate from UI component code. As a result, their library — along with other implementations — can depend on token as a package, too.
  • Demo Apps/Sites as a environment with page examples built using the component library. The demo’s also for tutorials and rapid prototyping, including by designers!
  • Cross-platform components suitable for iOS, Android, and Windows.

Design Assets

  • Design Toolkits as template files and symbol libraries offered in design software. Today, almost always Sketch. Tomorrow, Figma, Invision Studio, and other emerging competitors?
  • Fonts, Icons, and even Origami’s Image Sets due to a system’s often expected role in distributing and versioning such libraries.
  • Other Design Resources like illustration and color swatch ASE/CLR files as a springboard for bespoke artwork. These collections change slowly, less formally, and via contributions by community members not a part of a system core team. Yet, from the customer’s perspective and system’s communications, it’s part of the system.

Documentation Site

  • Documentation Sites describe features (like a button), onboard new users, and trigger processes like getting help or contributing. Teams build sites more often using a static site generator or less often with a content management system.
  • Documentation Componentscode-example-pair, do-dont, hex-code, component-explorer – depend on the UI component library and serve usually only the doc site. Such components may be versioned with the documentation site or as a third, separately versioned library relative to doc and the UI components they rest between.

Destinations: Where Does It Go?

For Code

  • BETTER: Hosted assets on CDNs for direct links to versioned style and script as well as fonts and icons that change more slowly.
  • JUST OK: Repository Access to Github, Bitbucket or the like to clone, fork, or otherwise compile, use and maybe — eventually — contribute.
  • IF NECESSARY: Direct Code Downloads, usually of “the ZIP file” of compiled or uncompiled system assets from the doc site for local use and/or manual integration into a separate repository.

Bootstrap and Material Design Lite are examples releasing to 2+ destinations.

For Design Toolkits

  • BETTER: Versioned and distributed using permission-based design asset management software such as Abstract or Lingo.
  • GOOD: Direct toolkit download from a documentation site, with clear version indicated and associated Getting Started doc nearby.
  • JUST OK: Shared drive, via well publicized and possibly simplified internal URL (such as http://system.uitoolkit).
  • NOT GOOD ENOUGH: Buried on some fourth level page on a barely organized wiki site many people can’t find.

Next → #2. Cadence

EightShapes

A collection of stories, studies, and deep thinking from…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store