Every design system team eventually faces the same argument in a review. A product designer wants a light-grey “subtle” button for the marketing hero, and it fails contrast. Someone says “but it looks better”. Someone else says “but accessibility”. Forty minutes later nobody has changed their mind. Principles exist to end that meeting in two minutes, and team models exist so that someone has the authority to apply them.
\nMost published design principles are slogans: simple, consistent, human, delightful. Try this test on any principle: could a reasonable team choose the opposite? Nobody argues for complicated or inhuman software, so those words never decide anything.
\nA useful principle names a trade-off and picks a side. Here are the four Northwind UI uses:
\nEach one would lose to its opposite at some other company. A gaming studio might reasonably say “expressive everywhere”. That is how you know the principle carries information.
\n\nPrinciples also need to live where decisions happen: in the component proposal template, in the review checklist, at the top of the documentation site. A principle that only appears in the launch deck is gone within a month.
\nPrinciples need people with the time and authority to apply them. Nathan Curtis described the three classic shapes in 2015, and they still describe most organizations:
\nFor the second attempt we started centralized: two designers and three engineers, plus a product manager shared with another team. Centralized was right while the foundations were being built, because tokens and core components need a few people making many consistent decisions quickly.
\nOnce Button, inputs, Dialog and the token pipeline were stable, we opened contributions and moved to hybrid. Product teams now build roughly a third of new components, and the core reviews, documents and releases them. Section 5 covers how that contribution process works in practice.
\nNotice that the team model changes with the system’s age. Ask “what does the system need this year?” rather than “which model is best?”. With principles and an owning team in place, you are ready for the first real piece of architecture: design tokens.
\n","toc":[{"id":"sec-1","text":"Principles that decide things","level":2},{"id":"sec-2","text":"Who runs the system: four team models","level":2},{"id":"sec-3","text":"What Northwind chose","level":2}],"takeaways":["A useful principle picks a side in a real trade-off; if no reasonable team would choose the opposite, it is a slogan, not a principle.","Principles earn their place in reviews, when they settle an argument without a meeting.","A centralized team gives quality and speed of decisions but can become a bottleneck far from product reality.","A federated model spreads ownership across product teams but needs a small core to stay coherent.","[object Object]"],"further":[{"title":"Design principles (U.S. Web Design System)","url":"https://designsystem.digital.gov/design-principles/"},{"title":"Design Systems 101 (Nielsen Norman Group)","url":"https://www.nngroup.com/articles/design-systems-101/"}],"quiz":[{"q":"Which of these is the strongest design principle for Northwind UI?
","options":[{"text":"Our components are simple and intuitive.","why":"No team would argue for complicated and confusing components, so this never settles a decision."},{"text":"Consistency across every product.","why":"Everyone agrees with it in the abstract, and it gives no guidance when consistency conflicts with a product’s real need."},{"text":"Accessible before beautiful; we drop a variant rather than ship one below WCAG 2.2 AA.","why":"Correct. It names a trade-off, picks a side, and tells you what to do when the two goals collide."},{"text":"We design with empathy for our users.","why":"A value worth holding, but it doesn’t help choose between two concrete options in a review."}],"answer":2},{"q":"A 12-person company has one product team and wants a design system. Which team model fits best right now?
","options":[{"text":"Solitary, where the product team builds the system as part of its own work.","why":"Correct. With one team there is nobody else to coordinate with yet; a separate system team would have no other customers."},{"text":"Centralized, with a dedicated three-person system team.","why":"A dedicated team serving a single product team is mostly overhead at this size."},{"text":"Federated, with contributors from many teams.","why":"Federation needs several product teams to federate; with one team it is the same as solitary."}],"answer":0},{"q":"Northwind tried a fully federated model with no dedicated people. What is the most likely failure?
","options":[{"text":"Components become too consistent and teams lose flexibility.","why":"The usual problem is the reverse; without a core, components diverge."},{"text":"Release cadence becomes too fast for teams to absorb.","why":"Without dedicated owners, releases tend to stall rather than speed up."},{"text":"Contributions stall or conflict because nobody owns reviews, releases and the overall direction.","why":"Correct. When everyone owns the system part-time, its upkeep loses to every product deadline."},{"text":"Designers stop using Figma libraries.","why":"Tool usage isn’t driven by the team model; ownership and quality are."}],"answer":2}],"exercise":{"kind":"choice","multiple":false,"options":["grow-core","hybrid","dissolve","freeze"],"correct":["hybrid"],"title":"Pick the next team model","prompt":"Year two at Northwind. Tokens and 14 core components are stable. The five-person core team has a nine-week backlog of component requests, and three product teams have each built a solid date picker on their own. Leadership asks you what should change. Pick the best move.
\n","hints":["The core team is now the bottleneck, and product teams have proven they can build good components.","Look for the option that keeps someone accountable for quality while adding capacity."],"explanation":"This is the classic moment to move from centralized to hybrid. The core keeps ownership of tokens, reviews, documentation and releases, which protects quality and coherence. Product teams add capacity by contributing through a defined process, and the best of the three date pickers becomes the system’s version instead of a fourth one being built.
\n","checkLabels":{},"optionText":{"grow-core":{"text":"Double the core team so it can build every requested component itself.","why":"More people shortens the queue briefly, but a central team still can’t match the context of 40 product teams, and headcount rarely doubles on request."},"hybrid":{"text":"Keep the core for tokens, reviews and releases, and open a contribution process so product teams can upstream components like the date picker.","why":"Correct. It adds capacity where the knowledge already is, while the core keeps the system coherent."},"dissolve":{"text":"Move the core engineers into product teams and let everyone contribute to the system part-time.","why":"This repeats the 2021 failure: without dedicated owners, reviews and releases lose to product deadlines."},"freeze":{"text":"Freeze new component requests for a year so the core can polish what exists.","why":"Teams keep building what they need anyway, so a freeze produces more one-off components and less adoption."}}},"words":694,"readMinutes":3}