Releasing Design Systems

Delivering Interconnected Outputs to Adopters Over Time

Nathan Curtis
Aug 28, 2018 · 5 min read

Outputs: What‘s Released?

Design systems programs release many types of outputs, not just code. As a result, a system should differentiate and communicate this range of versioned outputs to developers, designers, and other customers.

Code, the Source of Truth

Most systems offers a single source of truth of presentation layer code as:

  • 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

Most teams limit understanding of what they release to simple “we release code.” It’s eye opening for them to realize that they publish so many other tools that change over time. They include:

  • 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

Design systems need a home, a place everyone knows they can find a path to everything that will have the latest and greatest. Housed at a memorable URL, it’s often built with UI components specific to it’s mission.

  • 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?

When distributing code and design assets, it’s vital to offer the code in manners most easily consumed by your adopting engineers. This means that some systems must offer choice across a many options, while others can rely upon a single choice as organizational standard.

For Code

  • BEST: Registries like npmjs (or an internal counterpart like Sonatype's nexus) that provide access and management of released code packages. Developers then use tools like bower, npm, yarn, webpack, and babel to integrate and upgrade that code smoothly in their environments.
  • 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.

For Design Toolkits

  • BEST: Create New as a synced, embedded path in a design tool’s menu to create a new instance from a template.
  • 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.


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

Nathan Curtis

Written by

Founder of UX firm @eightshapes. Speaker. Writer. Fan of Arsenal, Hokies. Cyclist & runner. Father & husband. VT & @uchicago grad.


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