Scaling Automoor’s Design System
A structured, token-based design system for a European automotive SaaS platform bringing consistency, speed, and clarity to a growing product team. I joined as Senior Product Designer and owned the audit, redesign, and implementation from the ground up.
Design System
UI Design
Tokenization
Documentation
My role
Senior Product Designer. I led the audit, the new foundations, the component library and the documentation.
Team
Design and engineering, working from one shared Figma library.
Platform
A web based dealership management system for Swiss car dealers.
About Automoor
Automoor is a dealership management system for the Swiss market. It brings vehicles, customers, sales, dispatch and handover into one place, so the team can sell cars instead of searching for information. As the product grew, so did the number of screens, people and ways of building the same thing.
Why a design system?
Every new feature was being designed and built from scratch. Colors, type and components drifted from screen to screen, and new designers had to learn the product by guessing. A design system would give designers, developers and product managers one source of truth, so the team could ship faster without the product falling apart.
Principles
Before drawing a single component, we agreed on three principles to guide every decision in Automoor UI 2.0.
Problems we found in the audit
We audited every screen and the existing component set to find pain points, inconsistencies and room to improve. Five problems kept coming up.
01
Contrast issues
Many text sizes and colors failed contrast, especially gray labels on gray surfaces in dense data tables.
02
High onboarding cost
The same button existed in several versions. New designers had to guess which one was right, and explaining where each was used took real time.
03
Redundant elements
Duplicates such as bubble and popover did the same job twice. They made the CSS heavier, slowed pages down, and made the team wary of adding anything new.
04
Inconsistent grids and spacing
Cards showing the same content used different margins, padding and alignment almost every time, because every screen used its own grid.
05
Hard coded colors and sizes
Colors and sizes were picked as raw hex codes and pixel values, screen by screen, so nothing could be changed in one place.
Naming things by purpose
We chose a semantic approach: every token and component is named for its purpose, not its appearance. A color is “Semantics, Error 700”, not “red”. That one decision shaped everything that followed.
01
Improved consistency
Elements look and behave the same across every screen, which reduces confusion.
02
Easier to read
Meaningful names make the design and the code easier to understand and discuss.
03
Better accessibility
Contrast checked color pairs and clear states are built in, not added later.
04
Simpler maintenance
Changing a token in one place updates every screen that uses it.
05
Built to scale
New features plug into existing tokens and components instead of starting over.
Foundations
Everything in the system starts here: color, type and icons, each named for what it does.
Semantic colors
A confident primary blue, a ten step neutral scale for dense data screens, and a 700 and 50 pair for every status.
Typography
Inter across the product, in Regular, Medium and Semi Bold. Fifteen text styles cover headings, body, subtitles and buttons.
Iconography
One Tabler icon set with a single stroke weight, 1,505 icons in all, plus 90 featured icons in five sizes and five colors for empty states and highlights.
Elements
The building blocks every screen uses. Each one has its types, sizes and states defined and documented.
Button types
Five types for five levels of emphasis, from the one primary action on a page to quiet inline links.
Button sizes and icons
Two sizes, with or without icons, so the same component works in a dense table row and a page header.
Input fields and states
Text fields, dropdowns, dates and multi select, each with default, active, filled, submitted, success and error states.
Components
Elements come together into the patterns dealers use every day.
Usage rules
Every component page in Figma documents its states, the tokens it uses and how to use it. Buttons are a good example.
Used across the product
Each Automoor screen is assembled from the same published library. Counted across five core screens:
27
Buttons
27
Tabler icons
11
Checkboxes
10
Status chips
How we rolled it out
We rolled the system out in priority order, starting with the elements that touched the most screens, and checked every change in real workflows before it shipped.
“Consistency isn’t a constraint on speed. It’s what makes speed sustainable.”
Zuraiz Zafar
Senior Product Designer, Automoor
One shared library
Design decisions live in one published library
Consistent screens with no extra work
New screens reuse the same components
Faster onboarding
One documented system instead of duplicates
What I learned
A design system is a product, not a file. It needs principles, documentation and real adoption to survive a growing team.
The hardest part was discipline: consolidating what already existed before adding anything new.
“The best component is the one the team never has to rebuild.”
/ More work
More case studies
