Not consistency for its own sake. Speed, and the ability to grow without decay.
Not consistency for its own sake. Speed, and the ability to grow without decay.
Without a system, every new page is a fresh set of decisions. Spacing drifts, type sizes multiply, and after a year the site looks like it was made by several studios who never met.
A system fixes the decisions once so that new work inherits them.
Type scale, spacing scale, colour with defined roles, component behaviour including their states, and rules for motion. Written down, not held in someone's head.
New pages get quicker over time instead of slower. That is the whole return, and it only shows up after the system has been used a few times.
A useful system can be a type scale, a spacing scale, a colour set with defined roles, and five components. That is enough to stop the drift that makes a site look like it was built by several studios who never spoke.
Systems that begin as exhaustive documentation projects tend not to get used. The ones that survive start small, get used immediately, and grow because someone needed the next piece.
Most component bugs live in the states: hover, focus, disabled, loading, error, empty. A system that only defines the resting appearance leaves every hard decision unmade, and each developer will make it differently.
The empty state is the one most often forgotten and the one users hit first, before they have any data.
Without somebody responsible for it, a design system decays into a folder of stale screenshots that nobody trusts. The maintenance burden is small, but it is not zero.
The payoff only arrives after the system has been used a few times, which is precisely when most teams stop investing in it.
The saving is not in drawing buttons. It is in decisions not re-litigated. A new page in a team without a system involves a conversation about spacing, a conversation about the heading size, and a conversation about which of the three existing card styles to use. With a system, none of those conversations happen and the page ships in a fraction of the time.
The second saving is in review. When components are agreed, review is about whether the page says the right thing rather than whether the padding matches, and that is a far better use of everyone's attention.
The third is in onboarding. A new designer or developer with a documented system is useful in days rather than weeks, because the answers to their first fifty questions are written down.
Almost always because they were treated as a deliverable rather than a living thing. A system handed over as a file and never touched again drifts out of sync with the product within one quarter, and once it is wrong once, people stop trusting it and go back to copying whatever the last page did.
The second cause is being too complete too early. A system with ninety components before the product needs twelve is a maintenance burden acquired in advance, and most of it will be wrong because it was designed without a use case.
The third is having no route for exceptions. Real products need things the system did not anticipate. Without an agreed way to propose an addition, people simply build outside it, and the system becomes a description of the past.
A type scale with defined roles, a spacing scale, a colour palette where each colour has a job rather than a name, and the handful of components you use on every page: button, input, card, navigation.
Every component documented in all of its states — default, hover, focus, active, disabled, loading, error, and empty. The empty and error states are where most systems are silent and most products look unfinished.
One named owner, and a standing half hour a fortnight to keep it true. A system without an owner is a document, and documents rot.