In a car-rental site's design system, several teams use the warning banner to advertise insurance upgrades despite a documented don't; how would you diagnose and fix it?
answer
- misuse is a signal, not defiance
- was the don't seen when choosing
- the unmet need behind the misuse
- a sanctioned home for offers
- migrate, then re-audit
basics
~20 sTreat repeated misuse as evidence: check whether teams saw the don't when choosing, and what need drove them. Usually a promotion component is missing, so add a sanctioned alternative, restate the reason, surface guidance where designs start, then re-audit.
solid answer
~50 sRepeated misuse by several teams is a signal about the system, not just the teams. I'd **diagnose** first: find the instances, ask the teams why without blame, and check whether the don't was visible where they actually chose the component — the design library and the code documentation, not only the website — and whether it gave a reason. The likely root cause is an **unmet need**: product wants to promote insurance and the system has no promotional component, so the most eye-catching one gets borrowed. Then **fix**: provide a sanctioned offer pattern through the contribution process, rewrite the don't with its reason — warning styling on adverts trains renters to skip real warnings — and link to the alternative. Help teams migrate existing screens, consider an automated check if it recurs, and re-audit to confirm the count falls.
go deeper
Recall that a don't needs a reason and an alternative, and that a warning style exists to signal a problem the user must notice.
Explain how warning styling on adverts erodes the meaning of real warnings, and why guidance must appear where designers and engineers actually choose components.
Demonstrate a diagnosis-first rollout: inventory, blameless interviews, root cause matched to fix, a sanctioned alternative, migration and a re-audit that proves the count fell.
Frame recurring misuse as a gap in the system's coverage of business needs, and weigh building an offer component against keeping promotion outside the system.
## Why repeated misuse is a system signal A **design system** is a shared set of tokens, components, patterns and guidance consumed by many product teams. Its **usage guidelines** say when to use each component, when not to, and what to use instead. When one team misuses a component, it may be a slip. When several teams misuse the same component in the same way despite a written don't, the system is telling you something: the guidance was not seen, was not believed, or left a real need with nowhere to go. In this scenario a car-rental site's teams style insurance upsells — 'Add full cover for a small daily fee' — as the system's **warning banner**, the component meant for problems the renter must notice, such as a licence that expires before the return date. The screens render correctly. The damage is to meaning. ## What the misuse actually costs - **Warnings stop working.** Renters who see the warning style on adverts learn to skim past it, so the banner saying their booking is at risk gets skimmed too. - **Trust erodes.** A sales message dressed as a problem reads as a pressure tactic. - **Assistive technology may amplify it.** If the warning banner is built to be announced to screen readers as an urgent message, a screen-reader user hears the upsell as an interruption. - **The misuse spreads.** New teams copy the nearest existing screen, so each instance recruits the next. ## Step 1 — Find it and ask why 1. **Inventory the instances**: search the code for the warning banner carrying promotional copy, and ask design leads for the design-file equivalent. 2. **Talk to the teams** that did it, without blame. The goal is the reason, not a confession. 3. **Check the decision point**: where was the component chosen? If designers pick from a design editor's library and engineers from their editor's code completion, a rule that lives only on the documentation website was never in front of either of them. ## Step 2 — Match the cause to the fix | Root cause | What you hear | Fix | |---|---|---| | Guidance not seen when choosing | 'We didn't know there was a rule' | Surface the don't in the design library's component description and the code's inline documentation | | Rule stated without a reason | 'It looked arbitrary' | Add the user consequence in one sentence | | No sanctioned alternative | 'Product needed something that stands out' | Provide an offer pattern or component | | Conflicting incentives | 'The upsell target is ours' | Show product owners what the misuse costs their own warnings and renters' trust | In cases like this the third row is usually the real one: the system has no legitimate way to highlight an offer, so teams borrow the most eye-catching thing it has. Guidance alone cannot fix a missing component. ## Step 3 — Fix the guidance and the gap - **Add the alternative first.** An offer card or promotion slot, designed with product and marketing, gives teams a legitimate home for the upsell. Route it through the system's contribution process rather than inventing it inside the guidance page. - **Rewrite the don't with its reason and its detour**: 'Don't use the warning banner for offers — renters learn to ignore warnings. Use the offer card instead.' - **Add a do / don't pair** drawn from the actual misuse, so teams recognise their own screen. - **Put the guidance where choices happen**: the component's description in the design library, its code documentation on web and native mobile, and the design-review checklist. ## Step 4 — Migrate, guard and verify 1. Help the affected teams move their screens to the new component; a rule surrounded by existing violations reads as optional. 2. If the misuse recurs, consider an automated check — for example, flagging the warning banner where its content comes from the promotions source — accepting that no check reads intent perfectly and that the check is a backstop, not the fix. 3. **Re-audit** after a release cycle. The fix worked if the count falls and new promotional needs arrive as requests for the offer component instead of borrowed warnings. ## What does not work - Rewording the rule more forcefully ('NEVER') without adding a reason or an alternative. - Removing or locking the warning banner, which breaks its legitimate uses. - Treating the teams as the problem; they were solving a real product need with the tools the system gave them.
- The product owner insists the upsell must look urgent to hit its target; how do you respond?Separate prominence from urgency. The offer can be prominent — placement, imagery, an emphasised style — without borrowing the semantics of a problem. Show the cost in their own terms: if renters learn to ignore warning styling, genuine warnings about licences or payments get missed, which creates failed pickups and support load. Offer to design the prominent offer component with them.
- How would you know the fix actually worked?Re-run the same inventory after a release cycle and compare counts of warning banners carrying promotional content. Check that new promotional work arrives as use of, or requests for, the offer component, and ask the original teams whether the guidance now appeared where they made the choice. A falling count with no new borrowings is the signal.
saying these in an interview costs you the question
- Repeated misuse just means teams didn't read the docs; send a reminder.
- Stronger wording such as 'never' is enough to stop a misuse.
- Misusing a warning style for adverts only costs visual consistency.
- Removing or locking the component is the quickest way to stop misuse.
- An automated check alone fixes misuse without offering an alternative.