UID 07 - Atomic Design, Design Token & Design System con Francesco Improta

Source: transcript Part 1 + Part 2 + slide deck
Speaker: Francesco Improta
Related: UID 07 - Course Map, Design System, Design Tokens, Atomic Design, Interface Inventory, Design System Governance

One Sentence

This lesson explains how a Design System turns scattered interface decisions into a shared, modular, documented, and governed system that helps teams design and build digital products consistently.

Speaker Context

Francesco Improta works as a Product Designer for the Dipartimento per la Trasformazione Digitale. This matters because the lesson is not only about making components in a design tool; it also explains what happens when a design system must support many teams, many products, public-service constraints, and long-term maintenance.

Core Thesis

A design system is not just a visual library. It is a design product that serves other products.

It connects:

• design principles
• visual foundations
• Design Tokens
• reusable components
• interface patterns
• templates
• code resources
• documentation
• governance

The goal is not to create a beautiful archive of components. The goal is to help people make better interface decisions faster, with less inconsistency and less repeated work.

Lesson Map

flowchart TD
  A["Why design systems exist"] --> B["What a design system is"]
  B --> C["How to set the boundaries"]
  C --> D["Design audit and interface inventory"]
  D --> E["Design tokens"]
  E --> F["Atomic design"]
  F --> G["Documentation and governance"]
  G --> H["AI and future workflows"]

Why Design Systems Became Important

The lesson starts from the shift from desktop web design to responsive, multi-device product design.

Earlier web design could often focus on one main desktop layout. With responsive design, smartphones, tablets, and unknown future devices, designers needed more flexible systems instead of isolated fixed pages.

This is why the history matters:

• grid systems helped designers structure pages
• responsive design changed the idea of layout
• the “post-PSD” era made static page files insufficient
• teams needed shared rules that could survive many screens, devices, and contributors

The design system appears as a response to scale and complexity.

What Is a Design System?

There is no single global definition, but the lesson compares three useful angles:

Author	Emphasis
Brad Frost	the official story of how an organization designs and builds interfaces
Alla Kholmatova	connected patterns and shared practices organized around a product purpose
Nathan Curtis	documented visual styles, components, code, and design tools that make adoption more efficient

My synthesis:

A design system is an evolving set of interconnected design decisions, resources, and practices used to create digital interfaces.

The important word is system. The parts are not independent. A color token affects a button. A button affects a form. A form affects a checkout flow. Documentation affects how developers implement it. Governance affects whether the system stays coherent over time.

What A Design System Is Not

A design system can contain a brand style guide and a UI kit, but it is larger than both.

Not enough by itself	Why
Brand style guide	focuses mainly on identity: logo, brand colors, type, tone, and visual rules
UI kit	gives reusable interface pieces, but may not explain why, when, or how to use them

A real design system also includes decision logic, documentation, process, ownership, and maintenance.

What A Design System Is For

The slide deck gives four main functions.

Function	Meaning
shared language	teams call the same things by the same names
decision support	reduces subjective arguments and creates a reference point
design organization	centralizes rules, patterns, resources, and visual foundations
faster development	improves handoff, implementation, and maintenance

This matters in everyday collaboration. A design system helps with stakeholder feedback, designer-developer communication, product consistency, and technical implementation.

Essential Parts Of A Design System

Francesco groups the contents into three families.

Guidelines

Guidelines describe how to think and decide.

They can include:

• design principles
• how-to guides
• UX guidelines
• accessibility rules
• information architecture principles
• interaction rules
• language, microcopy, and tone of voice
• maintenance and contribution processes

Ready-To-Use Resources

These are the reusable building blocks.

They can include:

• Design Tokens
• visual foundations
• Design Library
• components
• design patterns
• templates
• code resources

Operational Tools

These help the system work in practice.

They can include:

• UI kits
• developer kits
• accessibility checklists
• adoption checklists
• contrast tools
• plugins
• brand assets
• presentation templates

An important rule: a design system should be technologically agnostic. It should support different platforms and technologies, not depend on only one implementation environment.

Setting The Boundaries

Before building a design system, the team needs to define its parameters.

Parameter	Question
rigidity	Should the system give flexible guidelines or strict rules?
modularity	Does it organize global elements, specific components, or both?
organization	Is ownership distributed, centralized, or hybrid?
scalability	Is it for one product, many products, or a public ecosystem?

Context changes the answer.

A startup with one product may need a lighter, informal system. A company with many products may need a more centralized system. A public administration system may need strong governance because many independent teams must still create coherent services.

Design System Charter

A Design System Charter is a shared document that defines the system before production starts.

It can include:

• goals
• scope
• parameters
• team members
• roles
• constraints
• risks
• responsible people
• products that will use the system

The charter is useful because design system work is not only visual. It is also cultural and organizational.

Deciding What To Include

The lesson presents a co-design workshop called Parts, Products and People.

Its role is to help the team decide:

• which parts belong in the design system
• which products will use it
• which people are involved
• who owns which responsibilities
• what should be prioritized first

This is important because a design system should not try to include everything immediately. It should start from shared needs and high-value recurring elements.

Design Audit

A design audit helps the team understand the current state of a product before designing the system.

Possible audit activities:

Activity	Purpose
user flow analysis	understand how users move through the product
Interface Inventory	collect and compare visible interface elements
heuristic evaluation	find usability problems using interface principles
performance evaluation	check technical performance and front-end weight

A good audit includes multiple perspectives: UI designers, UX designers, developers, writers, service designers, QA, team leads, product owners, and stakeholders.

Interface Inventory

An Interface Inventory is a structured catalog of all visual and interactive elements already present in a product.

It is used to:

• reveal inconsistencies
• create a realistic snapshot of the product
• build a shared language
• reduce design debt
• identify what should become part of the system

The basic process:

1. gather the team
2. choose what to analyze
3. collect screenshots
4. group similar elements
5. compare differences
6. present findings and recommendations

Typical categories:

• colors
• typography
• icons
• images
• lists
• messages
• navigation
• buttons
• forms

The important move is from chaos to order: extract the details, map the values, then decide what becomes a shared rule.

In the class activity, the groups found inconsistencies in navigation bars, dropdowns, buttons, tabs, typography, forms, line thickness, radius, and icon behavior. The deeper lesson is that visual differences must have functional meaning. If two elements do the same job, unnecessary visual variation creates confusion. If two elements do different jobs, the interface should make that difference visible.

Design Tokens

Design Tokens are named design decisions.

They transform raw values into reusable, meaningful references.

Example:

Raw value	Token name	Meaning
#0CA789	color-background-primary	primary background color for actions or sections
16px	grid-gap-default	default spacing between grid elements
8px	radius-small	small corner radius

Tokens can control:

• typography
• color
• spacing
• motion
• elevation
• shapes

They solve four main problems:

Problem	How tokens help
consistency	one decision can be reused across many places
single source of truth	the real value lives in one controlled reference
handoff	developers receive structured design decisions, not only visual screenshots
personalization	themes and variants can change without rewriting every component

Naming Design Tokens

Token names should describe responsibility, not only appearance.

The lesson uses this structure:

object category property modifier

Examples:

Part	Examples
object	button, card, header, label, icon
category	color, font, spacing, sizing, radius, motion, shadow
property	background, border, size, text, weight
modifier	primary, secondary, hover, disabled, xs, sm, lg

Good naming practices:

• use the right property for the category, such as color-background or font-weight
• let modifiers represent variants, not raw values
• use only the levels needed
• avoid names that are too long to understand

Bad names usually mix responsibility. For example, color-weight is confusing because weight belongs to typography, not color.

Design Token Architecture

The lesson describes three levels.

Level	Example	Role
global / primitive token	color-blue-500	basic named building block
semantic / alias token	color-background-primary	design decision with meaning
component / specific token	button-background-primary	context-specific component decision

This architecture creates flexibility.

If many components use color-background-primary, the team can change the underlying value once. If the radio button needs a different color from the button, a specific token such as radio-active can separate that responsibility.

Token Workflow

Design tokens connect design and code.

The workflow can move in both directions:

• a token changes in the design tool, then updates components and code
• a style changes in code, then the token definitions and design file must be synchronized

This is why token definitions are often stored in structured formats such as JSON. JSON is useful because it is platform-independent, readable, hierarchical, and easier to automate across web, iOS, Android, and design tools.

Atomic Design

Atomic Design is a method for decomposing interfaces into smaller parts and rebuilding them as systems.

The five levels:

Level	Meaning
atoms	basic visual foundations and indivisible interface elements
molecules	groups of atoms that perform a simple function
organisms	groups of molecules that form a reusable section
templates	groups of organisms arranged into reusable page structures
pages	template instances with real content and high fidelity

The movement is from abstract to concrete.

Atoms are more useful for designers and system builders. Templates and pages are easier for clients, users, and stakeholders to understand because they show the system in context.

Where Tokens Sit In Atomic Design

Design tokens sit before atoms.

They are not usually presented as interface pieces, but they shape the atoms. A button label, icon, field border, or heading color can all depend on token decisions.

So the relationship is:

flowchart LR
  A["Design tokens"] --> B["Atoms"]
  B --> C["Molecules"]
  C --> D["Organisms"]
  D --> E["Templates"]
  E --> F["Pages"]

Molecule Or Organism?

Francesco gives a practical test:

Split the component into smaller parts.

• If the parts are basic elements, it is probably a molecule.
• If the parts are smaller components, it is probably an organism.

Atomic design is a method, not a dogma. It helps classify and discuss interface complexity, but it should not become a rigid rule that blocks practical design work.

Documentation And Style Guide

Design System Documentation is the public face of the design system.

The style guide acts as the shared access point where designers, developers, product people, and stakeholders can understand how the system works.

It serves three functions:

Function	Meaning
communicate	gives one access point for teams
inform	explains how and when to use elements
document	records decisions, patterns, and principles

Main documentation sections:

• getting started
• guidelines
• components
• patterns
• how-to contribution and maintenance guides
• downloads and resources

Guidelines can document visual foundations such as color, grid, typography, brand, and icons. They can also document rules such as accessibility, tone of voice, microcopy, internationalization, and information architecture.

Component Documentation

A component sheet should answer practical questions.

It should include:

• how to use the component
• when to use it
• accessibility requirements
• good and bad usage examples
• design specifications
• code and development notes
• versioning

This is the difference between a component library and a usable design system. The component is not only a reusable object. It also needs meaning, limits, behavior, and maintenance rules.

Patterns

Patterns are reusable solutions to recurring product problems.

Examples from the slide deck:

• authentication
• sensitive data
• multi-step forms
• error handling
• empty states

Patterns are larger than individual components because they describe how several interface parts work together in a common situation.

Design System Governance

Design System Governance is the way the system stays coherent as it grows.

Its goals:

Goal	Meaning
coherence	keep product experience consistent across touchpoints
scalability	let the system grow across teams and products
trust	make decisions transparent and encourage adoption

Governance includes different responsibility areas:

• design
• development
• product
• accessibility
• brand
• QA

Good governance also needs communication. Teams need release notes, rituals, shared channels, onboarding guides, and tutorials. If changes are not communicated, the system will drift even if the files are well designed.

AI And Design Systems

The final section connects AI with design system work.

AI is already entering design system workflows, especially for:

• repetitive tasks
• prototype support
• documentation
• component descriptions
• guideline writing
• development support

Francesco mentions the Zeroheight 2026 report: AI is already part of the workflow for 32% of design system teams, 50% are experimenting, and 18% are not using it yet.

The key point is not that AI replaces design judgment. AI is a tool inside a larger system. Design system work still needs human responsibility, critique, context, and governance.

Main Takeaways

1. Design modular systems, not isolated pages.
2. A design system is a product that serves other products.
3. A design system is a means, not the final goal.
4. Tokens turn raw values into reusable decisions.
5. Atomic design helps organize interface complexity.
6. Documentation makes the system usable by other people.
7. Governance keeps the system alive after the first release.

How I Can Use This In My Own Work

When starting a UI project:

1. audit what already exists
2. identify repeated interface elements
3. group inconsistencies through an Interface Inventory
4. define the first Design Tokens
5. build a small Design Library
6. classify elements with Atomic Design
7. document components and usage rules
8. decide who maintains the system

The practical mindset is: do not make a system because it looks professional. Make a system when it helps future design decisions become clearer, faster, and more consistent.

Personal Study Questions

• What parts of an interface should become tokens?
• When should a design system be strict, and when should it stay flexible?
• Which components are truly shared, and which are one-time exceptions?
• What is the difference between a component and a pattern?
• How can documentation help developers work without asking the designer every time?
• What governance model fits a small student project compared with a large public service?

Related Notes

• UID 07 - Course Map
• Design System
• Design Tokens
• Atomic Design
• Interface Inventory
• Design System Governance
• Design System Documentation
• Design Library
• Handover
• Accessibility
• AI for Design