A retail bank’s mobile team says “our design system is just a component library”: which parts are missing, and what symptoms would you expect?
answer
- list the six parts
- hard-coded values across platforms
- same task, different solutions
- design file and code disagree
- nobody decides changes, teams fork
basics
~20 sMissing are the design language, tokens, patterns, usage guidelines, documentation and governance. Expect hard-coded values drifting between platforms, the same task solved differently by each team, design files and code disagreeing, and forks because nobody owns change.
solid answer
~40 sA component library covers only the coded components. The team is missing the **design language** (principles and visual foundations), **design tokens** (named decisions shared by design files and every platform), **patterns**, **usage guidelines and documentation**, and **governance** (ownership and a change process). The symptoms map to each gap: values hard-coded differently on web and native because no token holds them; teams using the same components differently for the same task because no guidance says when to use what; a design-editor kit that shows variants no platform built; and forks, because nobody knows who approves a change. I would name each symptom, trace it to the missing part, and add the thinnest version of that part first, not rebuild the library.
go deeper
Recall the six parts of a design system and point out which one a component library is. Knowing the list is the first step to spotting what is absent.
Explain which symptom each missing part causes, such as raw values drifting without tokens or inconsistent flows without patterns and guidelines.
Show how you would confirm each gap in a live multi-platform product and sequence small additions by the symptoms that cost the most, without a rewrite.
Address why the organisation funded only the library, and how to reframe the system’s scope so design language, guidance and governance get owners and time.
## Reading the claim When a team says its design system is “just a component library”, it is usually describing what it funded: a package of coded components. The claim is a useful diagnostic, because each part it leaves out produces a recognisable symptom. The skill interviewers look for is tracing symptoms back to missing parts rather than blaming the library. ## The parts that are missing A design system is commonly described as six parts. A component library covers one of them, on the code side only. 1. **Design language**: principles, colour, type, spacing, iconography, motion and voice. 2. **Design tokens**: design decisions stored as named, platform-agnostic data. The Design Tokens Community Group format draft describes tokens as a way to express design decisions in a platform-agnostic way so they can be shared across disciplines, tools and technologies. 3. **Components**: present in code; possibly present as a UI kit in the design editor. 4. **Patterns**: agreed solutions to recurring problems, such as how a transfer is reviewed or how an empty account history looks. 5. **Usage guidelines and documentation**: when to use a component, when not to, accessibility and content notes. 6. **Governance**: who owns the system, how changes are proposed, released and retired. ## Symptoms, traced to causes | Symptom in the bank’s app | Missing part | Why it happens | |---|---|---| | The positive-amount green differs between the two native apps and the web | Tokens | Each platform typed its own value; nothing names the decision | | Three flows show a failed payment three different ways | Patterns, guidelines | Components exist, but no agreed solution for the situation | | A team uses a tag component as a button | Usage guidelines | Nothing says what each component is for | | The design editor shows a compact list row that no platform built | Governance, documentation | Design and code change independently; no process keeps them aligned | | Two teams fork the transaction row to add a variant | Governance | No route to propose a change, so copying is fastest | | Screens look on-brand but feel disconnected | Design language | No shared principles to judge new designs against | ## Diagnosing in practice - **Look for duplication**: search the apps for repeated raw values and near-identical local copies of components. - **Ask how a change happens**: if the answer is “message whoever wrote it”, governance is missing. - **Compare the design editor and the code**: variants present in one and not the other indicate there is no shared source or sync process. - **Read the docs**: if they list component properties but never say when to use a component, guidelines are missing. These checks describe the gap; a full audit of every screen is a separate piece of work. ## What to add first The remedy is usually not a rewrite. Add the thinnest useful version of each missing part, in the order the symptoms hurt: 1. **Tokens** for the decisions that visibly drift, such as colour and spacing, consumed by the UI kit and by every platform’s components. 2. **Usage guidance** on the components most often misused. 3. **A named owner and a lightweight change process**, so forks have an alternative. 4. **Patterns** for the two or three flows where inconsistency causes the most support calls or user errors. ## Web and native both count The diagnosis has to cover every platform the system serves. A bank’s mobile app usually ships on two native platforms, often beside a web site, and each may have its own component library. A team can be proud of a well-built library on one platform while the other platform’s equivalent drifts. Asking which platforms consume which parts, and from what shared source, often reveals that the “system” is really two or three unrelated libraries that happen to look alike. ## Why the misconception persists - A component library is the most visible, measurable artefact, so it is what gets funded and demoed. - Many downloadable offerings called “design systems” are components plus documentation; the organisational parts cannot be downloaded. - Engineers often meet the system only through the package they install, so from their seat the library *is* the system. ## A strong answer - Lists the missing parts without dismissing the library, which is a genuine and necessary part. - Maps each symptom to a specific missing part. - Recognises the problem spans design files, web and native code. - Proposes incremental additions rather than a rebuild.
- Which missing part would you add first, and why?Usually tokens for the decisions that visibly drift, such as colour and spacing, because they fix inconsistency across every platform at once and give the UI kit and the code a shared source. If the loudest problem is instead teams misusing components or forking them, guidance or an ownership process comes first. The order follows the symptoms that cost the most, not a fixed sequence.
- How do you tell drift caused by missing tokens from drift caused by missing governance?Token drift shows up as the same decision holding slightly different raw values on different platforms or screens. Governance drift shows up as divergent structures: forked components, variants in the design editor that no platform built, or local copies with extra options. The first is fixed by naming decisions as shared data; the second by giving teams a route to propose and release changes.
- Is a component library without the other parts ever enough?For a single small team building one product on one platform, it can be, because the team itself carries the language, patterns and decisions informally. The missing parts become necessary as teams, platforms and products multiply, since informal knowledge stops travelling and each team starts making the same decisions differently.
saying these in an interview costs you the question
- Blames inconsistency on the component library’s code quality alone.
- Proposes rewriting the component library from scratch as the fix.
- Thinks adding more component variants will stop teams solving tasks differently.
- Assumes a UI kit in the design editor keeps coded apps in sync.
- Considers governance optional overhead rather than a part of the system.