Skip to content
tezvyn:

How do you handle a one-off token exception for a campaign?

Source: uxpin.comHardHow cards are made

How do you handle a one-off token exception for a campaign?

Tests balancing speed and systemic consistency. Strong answers outline a governance fast-track with sunset clauses, document the exception, and isolate it via campaign overrides instead of mutating core tokens. Red flag: permanently hardcoding the one-off.

What's really being asked

This question evaluates whether you understand design system governance as a socio-technical contract rather than a style guide. Interviewers want to see that you can balance business velocity against systemic consistency, prevent design drift, and manage organizational politics without becoming a bottleneck or a pushover.

A GOOD ANSWER COVERS four things in order. First, governance: propose a lightweight fast-track for exceptions that still requires written justification, stakeholder sign-off, and a mandatory sunset clause such as thirty to ninety days post-campaign. Document every exception in a public drift log or exception registry so the team can spot patterns. Second, technical isolation: never mutate core primitive or semantic tokens; instead expose the one-off through a campaign-scoped override, an experimental token namespace, or a feature flag. Use a conspicuous naming convention like campaign-holiday-2024-neon so the hack is searchable and greppable. Third, long-term risks: visual fragmentation across surfaces, token bloat that slows build times, broken theming or dark mode, accessibility violations, and erosion of trust that teaches product teams to bypass the system. Fourth, communication: announce the exception to the design system channel, update documentation, and schedule the cleanup task in the roadmap before the campaign launches.

COMMON WRONG ANSWERS include refusing all exceptions on principle, which signals political inflexibility and a lack of business partnership. Another red flag is allowing a hardcoded hex value directly in a component file without any token abstraction or audit trail. Candidates also stumble by proposing technical workarounds but omitting a sunset clause, removal ticket, or drift log, which guarantees the exception becomes permanent technical debt. Ignoring the power dynamics entirely, such as letting an executive override bypass documentation, is also a failure mode.

LIKELY FOLLOW-UPS the interviewer may ask next include how you would respond if an executive mandated the change without process, what you would do if the campaign color fails WCAG contrast against existing backgrounds, how you measure drift or audit exceptions quarterly, and at what threshold of repeated exceptions you would recommend expanding the core token set instead of continuing with one-offs.

ONE CONCRETE EXAMPLE is a marketing team requesting a neon green not in the brand palette for a holiday banner. Governance step is filing a one-page exception request with a hard sunset date of campaign end plus two weeks, approved by both product and design system leads. Technical step is creating a campaign holiday2024 promo banner background token that lives only inside a campaign feature flag, leaving core colors untouched. The token is greppable, linked to a Jira cleanup ticket, and logged in the drift registry. If marketing asks for the same color six months later, the log proves the palette needs an official extension rather than another exception.

Interview question

A marketing team requests a neon green outside the brand palette for a holiday banner. Which response best balances velocity and systemic consistency?

  • a.Reject the request outright to preserve palette purity and prevent visual fragmentation.
  • b.Expose it through a campaign-scoped override with a sunset clause, drift log entry, and scheduled cleanup ticket.Correct
  • c.Add the color to the core semantic tokens with a comment to remove it after the campaign ends.
  • d.Hardcode the hex value in the banner component and announce the exception in the design system channel.
Why?

Campaign-scoped overrides with sunset clauses and drift logs isolate the exception without mutating core tokens, keeping it greppable and truly temporary. Hardcoding the hex and merely announcing it skips technical isolation and formal governance, which virtually guarantees the exception becomes permanent technical debt.

Just read this? Test yourself on what you have been reading.

Read the original → uxpin.com

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.

See open roles