Design and UX
Design systems
A design system is how a product stays one product when dozens of people are building it at once. Tokens hold the decisions, components carry them into code, and documentation explains when each part is the wrong choice. This page covers what a system contains, who has to own it, how it meets front-end development, and why so many begin with enthusiasm and end as an outdated library nobody trusts.
Why this topic exists: Tokens, components, documentation and governance so that many hands ship one product: the site's design-system concept, IxDF's brand-guidelines literature, and the meeting point with front-end code.
Every product with more than a handful of screens reinvents its buttons eventually. A design system is the organised answer: decisions about colour, type, spacing and behaviour recorded once and consumed everywhere, by designers in their tools and by developers in their code. It is where the interaction and visual topics turn into infrastructure.
Layers, and the people behind each
Nielsen Norman Group describes a system as a style guide, a component library and a pattern library working together. The style guide sets rules for brand, voice and visual language. The component library holds reusable interface parts with their states and code. The pattern library shows how those parts combine into recognisable layouts and flows. Tokens sit beneath all three, turning a named decision such as the primary action colour into a value that design files and stylesheets both read.
| Layer | What it holds | Who usually maintains it |
|---|---|---|
| Tokens | Named values for colour, type, spacing, radius and motion | Designers and front-end engineers together |
| Components | Buttons, inputs, dialogs and the like, with every state, in the design tool and in code | A front-end team, with design review |
| Patterns | Combinations such as forms, data tables, onboarding and empty states | Product designers |
| Guidelines | When to use each part, content rules, accessibility requirements | The system's owner, fed by every team |
Start from what already shipped
An inventory of existing screens, listing every button variant, colour and spacing value in use, is the usual first step. It shows how much inconsistency exists and gives the first components a shape drawn from real needs instead of a blank canvas.
Building a system is the easy half; keeping it true is the hard one. A component library that drifts from the code, or code that drifts from the library, loses trust quickly, and teams quietly return to one-off solutions. The speed a system promises depends on a cost that Nielsen Norman Group names just as plainly: someone has to maintain it. Treat it as a product with users, a backlog and a named owner, and version it like any dependency. The beginner's mistake is to design a beautiful component set for a product that does not exist yet; the stance in our glossary is that small teams are better served by a bought kit until the system appears in somebody's job description.
Systems are also where design and engineering meet most directly. Designers who understand how components are built, and developers who understand why a spacing scale exists, are the ones who make them work; the code side continues under web development. Accessibility belongs here as well, because a component made accessible once is accessible everywhere it appears. Bought UI kits and web templates can seed a system, but their terms may limit handing files to a client's developers, a point picked up under design assets and licensing.
Next to this topic
- UX researchInterviews, usability tests, surveys, analytics and when to use which: NN/g's Research Methods and User Testing topics; SFIA User research; the fourth course of Google's UX programme.
- UX and interaction designInformation architecture, flows, patterns and the behaviour of interfaces: NN/g's Interaction Design and Information Architecture topics, IxDF's UX and HCI literature, SFIA User experience design.
- UI and visual designLayout, typography, colour, hierarchy and the craft of the screen: NN/g's Visual Design topic, IxDF's UI design, colour theory and Gestalt literature.
- Accessibility in designWCAG's four principles and conformance levels, assistive technology and inclusive design: NN/g's Accessibility topic, SFIA Accessibility and inclusion, W3C WAI.
- Prototyping and design toolsFigma, Sketch, Adobe XD and the prototyping loop from paper to clickable: NN/g's Prototyping topic; Udemy's Design Tools shelf; the third and fifth courses of Google's UX programme.
- Graphic design and illustrationComposition, type, image and print, and the Adobe and Affinity toolchain: SFIA Graphic design; IxDF's graphic design literature; Udemy's largest design shelf after 3D.
- 3D, animation and motion designModelling, rigging, rendering and motion in Blender, Maya, 3ds Max, ZBrush, After Effects and Cinema 4D: SFIA Animation development; Udemy's largest design shelf.
- Web designLayout for the browser, responsive design, WordPress themes and the hand-off to code: Udemy's Web Design shelf; the programming field owns the build.
- Design assets and licensingTemplates, stock media and fonts, and the licences that decide what you may do with them: the site's design-assets concepts and the /digital-assets/ partner picks.
- Design thinking and service designProblem framing, ideation and the end-to-end service: IxDF's design-thinking and service-design literature; NN/g's Design Process and Customer Journeys topics; SFIA Customer experience.
Concepts to know
Glossary entries with the reason each one matters here.
- Design system
The topic's own concept.
- Template
Where systems end and templates begin.
Tools of the trade
- Figma
Where most systems are built.
Frequently asked
- When does a team need a design system?
- When the same components are being rebuilt by different people and the inconsistencies reach users, and when someone can be given time to look after it. Below that point a shared component file and a short style guide usually do the job for a fraction of the effort.
- What are design tokens?
- Named, platform-neutral values for design decisions, such as the brand colour, one step on the spacing scale or the body text size. Design tools and code both read them, so a change made once propagates everywhere instead of being hunted down screen by screen.
- Should we adopt a public design system or build our own?
- Adopting an existing open system is the cheaper route and suits products without a strong visual identity or unusual interaction needs. Building your own costs far more in time and people, and pays off when your brand, platform or domain genuinely differs. Many teams do both: adopt first, then adjust the tokens and add components.
Courses in the directory
80 courses are filed here; the top 6 by our ranking, details and the provider link on each course page.
Last reviewed 26 September 2026 · Getting Digital