I didn't call it a "design system." That term barely existed when we started doing it. I called it "the kit" - a shared set of components, patterns, and rules that every project at IDESIGN started from. Buttons, form fields, typography scales, colour palettes, spacing rules. All defined once, used everywhere. It saved us time. It saved our clients money. And it made our enterprise applications feel like they belonged together rather than being assembled from spare parts.
How It Started
Three years ago, I noticed a problem. Every new project started from scratch. We'd design buttons, choose typography, define form styles, set up a colour palette. Then we'd do it again on the next project. And again. Each time, the decisions were slightly different. Not because the problem was different, but because we made the decisions on different days in different moods with different deadlines.
The result was inconsistency. Not between projects, which is expected, but within projects. A button on page one would be slightly different from a button on page four. The spacing between sections would drift from 32px to 40px to 24px depending on which developer built which page. The typography would start clean and accumulate exceptions until there were seven font sizes where there should have been four.
So I built the kit. A Sketch file (the tool of the time) with every component we commonly used, defined precisely. Alongside it, a CSS library with the same components coded and ready to use. A developer starting a new project would pull in the kit and have a foundation that was already consistent.
It wasn't sophisticated. It was a shared starting point. But it changed how we worked.
What Consistency Actually Gives You
The case for consistency in enterprise interfaces isn't aesthetic. It's cognitive.
When a user learns how one part of a system works, that learning should transfer to every other part. If a blue button means "confirm" on the dashboard, it should mean "confirm" everywhere. If form validation appears below the field on the settings page, it should appear below the field on every page. If the spacing between cards is 16px in the inbox, it should be 16px in the reporting section.
Every inconsistency forces a micro-decision. "Is this button going to do what I think it does?" "Where do I look for the error message?" These decisions are invisible to the designer but real to the user. In an enterprise system used eight hours a day, hundreds of micro-decisions add up to fatigue.
Consistency isn't about making things look the same. Once a user learns a pattern, every screen that follows that pattern is instantly familiar.
Rainui Teihotua
Chief Creative Officer
The Components in Our Kit
The kit evolved over two years. Today it includes:
Typography. Four heading sizes, two body sizes, one caption size. That's it. Every text element in every application maps to one of these seven options. The constraint sounds limiting. In practice, it eliminates the "should this be 14px or 15px?" conversation and frees up mental energy for the decisions that actually matter.
Colour. A primary palette of five colours plus neutrals. Each colour has a defined purpose: primary action, secondary action, success, warning, error. Every project gets a custom primary colour to match the client's brand. The rest stays consistent.
Spacing. A scale based on multiples of 8px. Every margin, padding, and gap uses a value from this scale. It sounds mechanical. It looks coherent. The eye can't tell you why an interface feels "right," but inconsistent spacing is one of the most common reasons it doesn't.
Components. Buttons in three sizes and four states. Form inputs with labels, placeholders, validation, and disabled states all defined. Cards, tables, modals, navigation patterns. Each component is designed once and reviewed against accessibility standards before it enters the kit.
Patterns. Not just components, but how they combine. A standard form layout. A standard table with sorting and filtering. A standard detail view. These patterns are flexible enough to adapt but structured enough that every project starts from a proven arrangement rather than a blank canvas.
What I'd Do Differently
The kit works. But looking back, I'd change two things.
Document the reasoning, not just the components. The kit shows what each component looks like. It doesn't explain why it looks that way. New designers on the team follow the patterns but don't understand the principles behind them. When they encounter a situation the kit doesn't cover, they guess rather than reason. I've started writing brief rationale notes alongside each component. It should have been there from the start.
Version it properly. For the first year, the kit was a file that I updated whenever I felt like it. No version numbers, no changelog, no migration notes. When the kit changed, existing projects didn't know about it. We've since moved to a versioned system where changes are tracked and communicated. The discipline matters more than the tooling.
Where the Industry Is Going
I've noticed that the broader design industry is starting to talk about exactly what we've been doing. "Design systems" is the term. Companies like Google (Material Design), Salesforce (Lightning), and Airbnb have published elaborate systems with documentation, component libraries, and governance models.
Those systems are impressive. They're also built for teams of hundreds working on products used by millions. The scale is different. The principle is the same: define your patterns once, use them consistently, and free your team to focus on the problems that are unique to each project.
For an enterprise-focused studio like IDESIGN, a design system doesn't need to be Material Design. It needs to be a shared set of decisions that prevent inconsistency and accelerate delivery. Our kit does that. It's been refined across dozens of projects and it makes every new project start stronger than the last.
If you're building enterprise applications without a shared component library, you're solving the same problems on every project and solving them slightly differently each time. That costs time, money, and user trust. Start small. Define your typography, your colours, your spacing, and your buttons. Use them everywhere. Build from there.
The buzzword will fade. The principle won't.