In a parity audit, a warehouse scanner app's shipped quantity stepper differs from its design file; how do you decide which side is right and where the fix lands?
answer
- neither side wins by default
- check the library first
- which change came last, and why
- field evidence beats a mockup
- four verdicts, four destinations
basics
~20 sNeither side is automatically right. Check the library, the history and the reason: fix a code bug in code, update a stale design, turn a genuine library gap into a system change, and document a justified platform deviation.
solid answer
~50 sI would not assume *the design is the truth*: designs go stale, and code often carries fixes learned in the field. First I check the **library**: what does the stepper component define? Then the **history**: which side changed last, and why — a ticket, a commit message, a field complaint. Then the **evidence**: did workers in gloves struggle with the designed size, does either version fail a target-size or contrast requirement? That usually yields one of four verdicts: a **code defect** (fix code), a **stale design** (update the file), a **library gap** (propose the change to the system so every team gets it, then update both sides), or a **justified deviation** (document it with the reason). If the stepper was enlarged in code after field complaints, it is likely a stale design *and* a library gap.
go deeper
Recall that neither design nor code is automatically correct, and that the library definition is the first thing to check when they disagree.
Explain the four verdicts — code defect, stale design, library gap, justified deviation — and the evidence that distinguishes them.
Show how you trace history and field evidence, recognise a finding that is both stale design and library gap, and route the fix so every product benefits.
Weigh product autonomy against system consistency when a product's field evidence argues for changing a shared component every team depends on.
## Why the design is not automatically the truth A common instinct is to treat the design file as the source of truth and fix code to match. That is right sometimes, and wrong often enough to be dangerous: - **Designs go stale.** Files are rarely revisited after a flow ships. - **Code carries field learning.** Hotfixes often encode real user feedback that never made it back to design. - **Both may have drifted** from the design system's library. The library is usually the best reference for *what the component is*, but it can be the thing that is wrong, too — a component that genuinely does not meet a product's need. So each difference is judged on evidence, not on which side it came from. ## The four verdicts | Verdict | Typical evidence | Where the fix lands | |---|---|---| | Code defect | Code differs from both design and library; no ticket or reason for the change | Fix the code to use the library component as designed | | Stale design | Code changed deliberately, with a reason, and matches the library | Update the design file | | Library gap | The deviation solves a real need the library cannot express | Propose a system change; then update design and code | | Justified deviation | A platform or context difference that is intentional | Document the deviation and its reason | A single finding can carry two verdicts. A change made in code for a good reason can be both a stale design and a library gap. ## Gathering the evidence 1. **Read the library definition** of the component: sizes, variants, states. Does either side match it? 2. **Trace the history** on both sides: when did each change, and what does the ticket, commit or file history say about why? 3. **Look at field evidence**: support reports, worker feedback, observed error rates on the task. 4. **Check the requirements the component must meet**, such as touch-target size and contrast. A version that fails them cannot be the answer, whichever side it lives on. 5. **Talk to the people** who made each change. Ten minutes with the engineer who shipped a hotfix often settles what an hour of archaeology cannot. ## Worked example: the quantity stepper The design file shows the stepper's plus and minus buttons at the library's standard size. The shipped app shows them noticeably larger. The history shows a fix six months ago after workers wearing gloves repeatedly hit the wrong button. The library's stepper has only one size. - It is not a **code defect**: the change was deliberate and evidenced. - It is a **stale design**: the file still shows the old size. - It is very likely a **library gap**: other warehouse and field products probably need a larger touch variant too. The right outcome is to propose a large-target variant of the stepper to the system team, then update this product's design and code to use it — replacing the local enlargement, which would otherwise miss every future stepper fix. Until the variant ships, the product keeps its enlargement and records it as a known deviation with a link to the proposal, so the next audit does not raise it as a fresh finding. ## Preventing the same finding next time - Make a one-sided fix **open a task on the other side** by default. - Record **justified deviations** where both designers and engineers look — the component's usage notes or the product's own design documentation. - Feed repeated gaps into the system's contribution process instead of solving them per product. ## When the evidence is thin Sometimes neither side has a ticket, a commit message or a field report to explain it. Then the **library definition is the sensible default**: it is the shared contract, it carries every future fix, and returning to it removes a local variant nobody can justify. Record the decision in the finding log, so that if someone later produces the missing reason, the choice can be revisited rather than silently reversed again. The judgement shown in answering this well is less about the stepper and more about refusing a default winner: the fix lands wherever the evidence says the truth is.
- When is fixing code to match the design clearly the right answer?When code differs from both the design and the library, and nothing — no ticket, commit message or field report — explains why. That pattern usually means a hardcoded value, a forked lookalike or an accidental change, and restoring the library component brings back every fix the system has made since.
- What if the evidence shows the library component itself is wrong for everyone?Then the fix belongs in the system, not in one product. Raise it with the system team with the evidence, let them change the component and release it, and have products adopt the release. A product-local fix would leave every other product with the defect and create a new fork to reconcile later.
saying these in an interview costs you the question
- The design file is always the source of truth; code must match it.
- Whatever shipped is right, because users have been using it.
- A deliberate code change never needs to reach the design file.
- A product-local enlargement is fine; the library need not know.
- Undocumented deviations are harmless if both teams remember them.