What you will learn in this lesson#

• Learn what role a design system fills

• Understand why design can become hard at scale

• Get to know the trade-offs of a design system, but also how it can benefit you for years

• Learn what requirements a continuous design toolchain needs to fulfill

• Get to know the rationale behind the toolchain we will use throughout the course

First be structured and systemic, then set the system itself#

Design is a messy, often intuitive process. It often has to go through multiple phases until we've closed the circle from idea or intuition (or user need) to something that resembles a complete realization. Design is highly qualitative, iterative, and usually bears no direct relation to efficiency as we typically think about it.

On the other end of the spectrum, we need overall guidance: something that informs us about guardrails, direction, vision, and any "hard lines" we need to know about. Such a process requires certain rigor, standards, and efficiency.

Example of a design system: IBM Design Language.

The entity that attempts to bridge these two different notions into a union is the "design system." The design system concept is malleable, as there are only loose conventions around what they are in practice. Typically a design system is a shared, centralized location that acts as a single source of truth, which is to say it acts as the authority on design questions. As a static but living artifact, it delegates knowledge into a fixed format instead of leaving every decision and bit of knowledge with people. From a practical perspective, it also provides the latest design elements (UI assets, graphics, static assets kits) and all the direction needed to inform designers and design users (could be developers) how it's meant to be realized into new artifacts, like a product.

What a design system does is, in a sense, nothing that any organization has not already done for centuries: it creates structure and order and replaces a great deal of implicit or tacit knowledge with express directions and guidance. Ideally, the creation of new design artifacts, like components, is eased by these directions, and designers can spend more time innovating in new areas rather than reinvent the wheel on the "known knowns."

Ultimately, a design system creates a foundation for shared understanding. In the next lesson, we'll look more specifically at "design tokens," the concept we use to atomically describe our design system.

The relation between design and code#

Given that digital design is, by necessity, coupled with software development, the struggle to contain any unmotivated half-baked new components and non-normalized variants will lead to increased implementation and maintenance cost (or technical debt).

Example: Component in IBM Design Language.

To be frank, any designed items are most likely expected to be coded at some point, so even a design-to-be is a future cost. If you reproduce a lot of similar components and are unable to make unique items that are clearly distinguishable by presentation and logic, then it's going to be hard to have a neat and ordered component selection/bank.

Setting up some basic house rules around what is a motivated and unique new component—or another type of item—will keep the sum total of the design system assets under control.

What are the fundamental parts of a design system?#

If you Google for longer than ten seconds, you'll get an overload of maps, charts, diagrams, and theories about what the crucial elements of a design system are. In general, you will find something along these lines:

• Design elements: A collection of design elements that could be anything from a few basic UI components to vast multimodal systems with a design language, set of style guides, detailed typography, tone of voice descriptions...

• Access: A way for all stakeholders to access design, ideally in all phases from WIP to in-production.

• Documentation: Well-rounded documentation capabilities, from the overarching and "free-form" to the nitty-gritty details of very specific parts.

• Implementation: The possibility to display how components should be implemented in code either by simple documentation or with rich, interactive examples.

• Governance: A known, explicit, useful, and directed governance model of who decides, owns, and operates the respective parts of the design system, ideally with a platform-agnostic approach.

• Work process: A work process that enables all team members to work and hand over their work with minimal friction and pain.

While there has been a "dribbblization" of design systems, meaning that graphic designers often drool over the new hotness coming out of a startup (there's just so many design systems these days), the real use of design systems is most likely going to be internal. And that's a good thing!

Some misconceptions that can also be quickly addressed are: