Which disciplines does a design-system team need besides engineers and visual designers, and what does each one contribute?

## Why a design system is not only design and code A design system is often described as “designers and engineers building components”. That description misses the disciplines that make components usable, accessible and adopted. Because a shared component is copied into every product that uses it, a gap in any discipline is multiplied across the organisation. Interviewers ask this question to see whether a candidate understands the system as a product, not a code package. ## The disciplines and what they contribute | Discipline | Contribution | What goes wrong without it | |---|---|---| | **Accessibility specialist** | Sets accessibility requirements for each component, reviews behaviour with assistive technologies, trains others | Defects in shared components spread to every product | | **Content designer or writer** | Labels, error messages, empty states, voice, and the wording of usage guidance | Inconsistent or unclear text; guidance nobody understands | | **Product manager or owner** | Discovers consuming teams’ needs, prioritises the roadmap, communicates plans | The team builds what it finds interesting, not what products need | | **Interaction designer** | Behaviour, states, transitions and input methods | Components look right but behave inconsistently | | **Quality assurance** | Tests states, platforms, sizes and assistive technology combinations | Regressions reach every consumer at once | | **Platform engineers** | Build components for each platform the system serves | One platform lags or gets a poor port | | **Documentation and developer experience** | Guides, examples, onboarding, release notes | Components exist but are hard to find and use | ## Why each matters more in a system than in a product - **Accessibility**: a product team’s accessibility bug affects one product; a system’s affects all of them. That leverage cuts both ways, which is why accessibility expertise belongs inside the system team or very close to it. - **Content**: every component carries words, such as a button label pattern, an error message template or a placeholder rule. Content decisions made once are reused everywhere. - **Product management**: without someone deciding what to build for whom, a system accumulates components and loses users. - **Platform skills**: web and native mobile engineering differ in conventions, accessibility services and layout. A system that serves both needs people who know both. ## A worked example: a fitness-tracker companion app A company ships a companion app for its tracker on two phone platforms, a small interface on the wearable itself, and a web dashboard. Its system team includes: 1. a **designer** and two **engineers**, one for the phone platforms and one for web; 2. an **accessibility specialist** shared with the wider organisation, who checks that the goal-progress ring has an accessible name and a text equivalent of its value, and that charts do not rely on colour alone; 3. a **content designer**, who writes the rules for motivational messages so they encourage without shaming and never misstate health data; 4. a **product manager** at part of their time, who talks to the activity, sleep and coaching teams about what they need next. The wearable’s tiny screen and glance-based use raise interaction-design questions that neither phone nor web experience answers, so the team borrows an interaction designer from the device team for the wearable components. ## Signs that a discipline is missing - Accessibility defects are found in several products and traced back to the same shared component. - Error messages and labels read differently in every product that uses the same component. - The team cannot say why it built its last three components, or for whom. - One platform’s components lag or behave unlike the others. - Consumers ask the same questions repeatedly because examples and guides are missing. Each symptom maps to a row in the table above, which makes it a practical way to decide which role to add or borrow first. ## Staffing the roles realistically - Few systems have every discipline full-time. Borrowing is normal: a shared accessibility specialist, a content designer at part of their time. - Borrowed time must be explicit and planned, or it disappears. - One person can cover more than one role, for example a design technologist who both designs and builds, but the responsibilities should still be named so nothing is dropped. - Consuming teams’ own specialists can review system work, which spreads knowledge and catches issues early.