When a design system team inventories an existing product, why should it also audit the current design and handoff process, and what should it look for?
answer
- inconsistency has a cause
- trace one feature end to end
- where values get retyped
- design files vs shipped UI
- interview both sides
basics
~20 sUI inconsistency is a symptom of how work flows from design to code, so the inventory should trace how designs are specified, handed off, built and reviewed. Look for hand-retyped values, unspecified states, stale design files and per-team libraries.
solid answer
~50 sAn inventory of screens and code shows *what* is inconsistent; auditing the process shows *why*, and a system that ignores the why will be bypassed the same way. I would trace a few recent features in the course-registration portal from design file to production, and interview designers and engineers on each team. I would look for where values are re-entered by hand, which states designs leave unspecified so engineers improvise, whether each team keeps its own component library in the design editor, how far the design files lag behind what shipped, and whether any review catches visual deviations before release. The output is a map of the current workflow with its pain points, which tells the system team what to provide beyond components — shared libraries, documentation, handoff conventions — and gives a baseline to compare against later.
go deeper
Recall that inconsistent UI usually has process causes — retyped values, missing specs, separate libraries — not just careless individuals.
Explain how tracing a feature from design file to production reveals where inconsistency enters, and why interviews add what artefacts cannot show.
Show how you would run the audit across teams and platforms, read signals such as stale design files and happy-path-only specs, and turn them into requirements for the system.
Frame the audit as organisational diagnosis: it reveals which incentives and gaps a system must change, and whether components alone can fix the problem at all.
## Why audit the process at all An **interface inventory** catalogues the colors, type, spacing, icons and components a product really uses, before a **design system** is built. On its own it describes symptoms: nine button styles, thirty-one grays. Those symptoms have causes in how work moves from idea to production — the **design and handoff process**. If the system team fixes the symptoms without understanding the causes, the same process will produce new variants on top of the system, and inconsistency returns. Auditing the process answers three questions: - **Where does inconsistency enter?** At design time, at handoff, during build, or after release? - **What do teams lack?** A shared source of values, specified states, a review step, time? - **What must the system provide beyond components?** Libraries in the design editor, documentation, conventions for handing off work. ## How to trace it 1. **Pick a few recent features** that shipped with visible inconsistency, and a few that shipped cleanly for contrast. 2. **Collect the artefacts** for each: design files, specs, tickets, review comments and the shipped screens. 3. **Interview both sides**: designers about where they took values and components from; engineers about what the specs left out and how they filled the gaps. 4. **Compare** the design files with what shipped, and note where and why they diverge. ## What to look for | Signal | What it usually means | |---|---| | Values retyped by hand from static images | Near-duplicate colors and sizes in code | | Specs that show only the happy path | Engineers improvising error, empty and loading states | | Each team keeping its own component library in the design editor | Parallel families of look-alike components | | Design files older than the shipped screens | Changes made in code never flow back to design | | No visual or accessibility review before release | Deviations and contrast failures reach users unnoticed | | Web and native mobile specified separately | Platform differences nobody chose on purpose | ## Methods that work - **Walk-throughs** of one feature's history with the people who built it. - **Artefact review** of design files for detached or locally modified copies of shared components. - **Short surveys** across teams about where they look for values and how long handoff takes. - **Observation** of a real handoff meeting or review, if the teams allow it. ## What it produces The output is a **map of the current workflow** with its pain points marked — not a verdict on anyone's discipline. It tells the system team which problems components alone will not solve, and gives a baseline: later, the same questions show whether handoff has actually improved. ## Example: a university course-registration portal Tracing three features in the portal, the team finds that the timetable-conflict warning was designed three separate times because each spec showed only the successful registration. Designers in two teams keep separate button libraries in the design editor, and the mobile app's designs were last updated months before its latest release, because fixes were made directly in code. Engineers report typing colors from exported images. None of this appears in a screen count, yet each finding explains a cluster of variants — and each points to something the system must offer, from specified states to a shared library both platforms draw from.
- Why interview both designers and engineers instead of only reading design files and code?Artefacts show outcomes, not causes. Designers can explain which decisions they made per project and where they lacked a shared source; engineers can explain where specs were missing and what they guessed. The gaps between the two accounts are often where inconsistency is born, and neither artefact records them.
- What does a large gap between design files and shipped UI tell a design system team?That design files stopped being a trusted source after handoff: changes were made in code and never fed back, or designs were not updated after review. A system introduced into that workflow will diverge the same way unless designers and engineers share one source and a habit of keeping it current.
saying these in an interview costs you the question
- UI inconsistency is purely a lack of engineering discipline.
- Design files show exactly what shipped, so comparing with code is unnecessary.
- A process audit is really just about picking new tools.
- Handoff problems disappear as soon as a component library exists.
- Only designers need to be interviewed about the design process.