Why should a design-system team treat the product teams that consume it as customers, and what changes in practice?
answer
- product mindset, internal market
- discovery before building
- roadmap from their problems
- documentation is the product surface
- customers, not bosses
basics
~20 sProduct teams can usually build their own UI, so a design system succeeds only by serving them better than that. Treating them as customers means researching their needs, prioritising from their problems, and treating docs and releases as the product surface.
solid answer
~40 sConsuming teams nearly always have an alternative, building or copying their own components, so the system competes for their use. Treating them as **customers** changes the work: the team does **discovery** with product teams before building, sets its **roadmap from their problems** rather than its own interests, treats **documentation, examples and release notes** as the surface customers actually touch, and watches where teams struggle or route around the system. It also means communicating plans and changes in advance, because customers depend on the system for their releases. It does **not** mean building every request: like any product team, the system says no to requests that would harm its coherence, and explains why.
go deeper
Recall that consuming teams can usually build their own UI, so the system has to earn its use by serving them well.
Explain what the customer mindset changes: discovery before building, a roadmap from product problems, and documentation treated as the main surface.
Show how you would investigate a team that routes around the system, and how you balance one team's request against the system's coherence.
Weigh mandate against earned use as adoption strategies, and decide how much discovery capacity the system team must fund to stay relevant.
## The idea A design system has consumers: the product teams that build with it. Unlike an external product’s customers, they rarely pay directly, but they almost always have a choice. They can build their own components, copy and modify the system’s, or ignore guidance. A system that does not serve them better than those alternatives is bypassed, whatever the official mandate says. Treating consuming teams as **customers** is the product mindset applied to internal infrastructure. ## What changes in practice | Practice | Without a customer mindset | With it | |---|---|---| | Deciding what to build | The system team’s own ideas and interests | Problems observed in product teams | | Research | None, or a survey after launch | Interviews and observation before building | | Documentation | Written last, if at all | Treated as the main product surface | | Change | Announced on release day | Communicated ahead, with migration guidance | | Failure signals | Noticed when someone complains loudly | Watched for, such as local copies and workarounds | ## Discovery with consuming teams 1. **Interview** product designers and engineers about what slows them down and what they rebuild. 2. **Observe** them building a real screen with the system, noting where they get stuck. 3. **Review** their shipped screens for local copies, overrides and workarounds, each of which is a signal that the system did not meet a need. 4. **Feed** these findings into prioritisation, rather than keeping a backlog of what the system team finds interesting. ## Documentation as the product surface Most consumers experience the system through its documentation, examples and release notes, not by reading its source. Unclear guidance or missing examples feel to them like a broken product, even if every component works. A customer-minded team invests in these surfaces with the same care as in the components. ## A worked example: a fitness-tracker companion app The system team for a fitness-tracker companion app builds a charting component. The coaching team, however, keeps building its own charts. A customer-minded team asks why instead of issuing a mandate. It finds that coaching needs to show a target range as a shaded band, which the system chart cannot draw, and that the documentation never explains how to show missing days when the tracker was not worn. The team adds the range band after checking that the sleep team needs it too, writes the missing-data guidance, and shows the coaching team the result. The local chart is then retired by the coaching team’s own choice. ## Customers, not bosses The customer framing has a limit that strong candidates name: - A system serves **many** customers; a request that helps one team can harm others or the system’s coherence. - The team should say **no** to requests that fragment the system, explain why, and offer an alternative such as a pattern or an extension point. - Prioritisation weighs how many teams share a need, how often it recurs, and how well it fits the system, the same way an external product weighs feature requests. ## Communicating change to customers Customers plan their releases around the system, so change must reach them before it lands: - announce planned breaking changes early, with the reason and a migration path; - write release notes for the reader who uses the component, not for the team that changed it; - give a clear channel for questions and for reporting problems; - tell teams when a request is declined, and why, rather than letting it disappear. ## Common mistakes - Relying on a mandate from leadership instead of earning use. - Measuring success by how many components exist rather than whether consumers’ problems are solved. - Treating every team’s request as equally urgent, which fragments the system. - Doing research once at launch and never again. ## Why interviewers ask The question separates candidates who see a design system as a code artefact that others must use from those who see it as a product that must earn its use. The second view predicts better adoption, fewer forks and fewer surprised consumers.
- How do you decide which customer requests to build?Weigh how many consuming teams share the need, how often it recurs, and whether it fits the system's principles and structure. A request shared by several teams and consistent with the system usually goes on the roadmap; a one-team need that would fragment a component is often better met with a documented pattern, an extension point, or a local implementation the team owns.
- What signals tell you customers are routing around the system?Local copies of system components with small modifications, heavy overrides of styles or behaviour, new components that duplicate existing ones, and questions that reveal teams did not find or trust the documentation. Each is evidence of an unmet need or a usability problem in the system, and worth investigating before issuing any mandate.
A design system team is like a restaurant in a food court: diners can always walk to another stall, so the menu, service and signage have to earn every visit, yet the kitchen still cannot cook every custom dish a single diner asks for.
saying these in an interview costs you the question
- Believes a mandate alone ensures product teams will use the system.
- Thinks treating teams as customers means building every request.
- Treats documentation as optional once the components work.
- Reads local copies of components as disobedience rather than unmet needs.
- Sets the roadmap from the system team's own interests.