Your team is starting a design system for a public library catalog's web and mobile apps; why build it inside one pilot product first rather than for every product at once?

## The pilot-product approach A **design system** — the shared foundations, components and guidance that many product teams consume — can be built in the abstract for every product at once, or inside one **pilot product** that uses each piece as it is created. The pilot approach builds the system alongside real feature work in one product, then widens to others once the pieces are proven. This question is about *why* that shape works and how it fails. Choosing which team to pilot with, and what the first release contains, are separate decisions. ## Why not build for everyone at once - **Design by committee** — every component becomes a negotiation among teams with different needs, and compromises pile up as extra options. - **Speculative APIs** — without a consumer, variants and options are guesses that tend to be too many or the wrong ones. - **No feedback loop** — problems surface only after several teams have built on the pieces, when changing them is expensive. - **Slow visible value** — nothing reaches users for a long time, which weakens support for the effort. ## What a pilot product gives the system - **Real requirements** — actual screens, data, content lengths and platform constraints instead of imagined ones. - **Fast feedback** — a partner team reports within days that an abstraction is awkward, while it is still cheap to change. - **A reference implementation** — shipped screens that show other teams what using the system looks like. - **Credibility** — a working example argues for adoption better than a plan does. ## The risks, and how to contain them | Risk | Symptom | Containment | |---|---|---| | Overfitting | Names, options or layouts only make sense on pilot screens | Name by purpose; review designs with a second product before release | | Entanglement | System code reaches into the pilot's data, navigation or state | Keep system code in its own package with its own tests from day one | | Ownership capture | Other teams see it as the pilot team's library | The system team owns the shared model; pilot-specific requests stay in the product | | Premature promotion | Others adopt pieces only one product has exercised | Treat pieces as candidates until a second consumer has used them | A common heuristic is to generalise a pattern only once it appears in two or three places. It is a habit, not a law — foundations such as color and type are shared from the start — but it guards against abstracting from a single example. ## Running it on a library catalog 1. Build inside the catalog's web search experience: result rows, availability labels, filters and the place-hold action are created as system pieces while the feature ships. 2. Keep every piece in the shared package rather than in the web app, with its own documentation and tests. 3. Invite the mobile team into design reviews early, so each component's model makes sense on both platforms before it is called stable. 4. Let the mobile app become the second consumer; whatever breaks there is overfitting to fix now, not later. 5. Widen to other products once pieces have survived both consumers. ## When the pilot shape needs adjusting A pilot teaches less if the chosen product is atypical — a one-off internal tool reveals little about a customer-facing app — or if its deadline is so tight that the team cannot afford to give feedback. The usual remedy is not to abandon the approach but to pair the pilot with an early second consumer, or to pilot a narrower slice such as the foundations alone. The underlying principle stays the same: let real use shape each abstraction before many teams depend on it.