Principles and Team Models

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.

Principles that decide things

Most 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.

A useful principle names a trade-off and picks a side. Here are the four Northwind UI uses:

1. Accessible before beautiful. No component ships below WCAG 2.2 AA. If a variant can’t meet it, we drop the variant.
2. Boring in the app, expressive on the site. The dispatch app favors density and predictability; the marketing site may use bolder type and motion, through tokens rather than one-off CSS.
3. Opinionated defaults, documented escape hatches. Components do the right thing with zero props. When a team needs to deviate, there is a supported way, and it is written down.
4. Fewer, better components. We would rather extend an existing component than add a near-duplicate.

Each 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.

Principles 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.

Who runs the system: four team models

Principles 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:

• Solitary. One product team builds a system for itself, and other teams copy it. Cheap and fast, and it reflects one team’s needs. It works while there is only one team that matters.
• Centralized. A dedicated team builds and maintains the system for everyone. Decisions are fast and quality is high. The risk is distance: a central team that ships no product can build components nobody asked for, and its backlog becomes everyone’s bottleneck.
• Federated. Designers and engineers from product teams contribute to a shared system in part of their time. The system stays close to real needs. The risk is that system work always loses to product deadlines.
• Hybrid. A small dedicated core owns quality, releases, tokens and direction; product teams contribute components and fixes through a defined process. This is where most long-lived systems end up.

What Northwind chose

For 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.

Once 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.

Notice 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.