How do you handle a product team requesting a custom Button?
This tests governance discipline. A strong answer asks context questions to separate misuse from a real gap, uses a decision tree for actions and CTAs, and extends the system with a documented variant. A red flag is instantly greenlighting a custom fork.
What's really being asked
This tests your ability to balance product velocity with design system integrity by using a systematic approach rather than ad-hoc exceptions. Interviewers want to see that you can distinguish between a team misusing an existing pattern and a legitimate gap that requires a documented design decision, while avoiding never-ending discussions.
The full answer
A strong answer walks through a clear sequence. First, ask context-related questions before jumping to a solution, just as the Workday team does before using their decision trees. You want to understand the user flow and whether the existing Button variants were actually considered. Second, apply a decision tree mindset for actions and CTAs, drawing from Doctolib's Actions and Calls To Actions decision tree, to determine if the need maps to an existing pattern or requires a new variant. Third, if the need is genuinely unique, evaluate whether it should become a new documented variant with guidelines and examples, or if the system itself should evolve. Fourth, involve stakeholders to document the decision so future teams avoid confusion and repeating the same debate.
The mistakes people make
A major red flag is immediately greenlighting a one-off custom button that lives outside the system, which fragments the UI and invites inconsistency. Another weak pattern is insisting the product team must use the existing Button without investigation, which ignores real needs and erodes trust. A third red flag is proposing a system change without any guidelines or examples, which simply delays the chaos.
What usually comes next
An interviewer might push on how you handle two product teams making conflicting requests for the same component. They could also ask how you prioritize system work when multiple teams claim their need is unique. Another follow-up is how you measure whether a new variant is actually being adopted or if it was unnecessary.
A concrete example
Imagine a team says they need a larger Button for a marketing landing page. Instead of building a one-off, you ask context questions about viewport constraints and whether this is a campaign-specific need or a permanent surface, similar to Workday's context-related questions. You run it through an actions and CTAs decision tree and discover it is actually a call-to-action that should align with the system's existing CTA pattern rather than the standard Button. You work with design to document the exception with guidelines and examples, and update the decision tree so the next team does not need to ask.
Interview question
A product team requests a custom Button for a high-visibility landing page. Which response best demonstrates mature design system governance?
- a.Add the requested Button to the system right away with minimal documentation to avoid blocking the team's launch.
- b.Approve the one-off custom Button immediately to maintain velocity, planning to standardize later if needed.
- c.Ask context questions about user flow, apply a decision tree, and document the outcome as a pattern alignment or new variant.Correct
- d.Require the team to use the existing Button without further discussion to protect system integrity.
Why? this is the answer
The correct approach first investigates context and maps the request to existing patterns via a decision tree before documenting any new variant, balancing velocity with integrity. The most tempting distractor is adding the Button to the system immediately without guidelines, which appears helpful but merely delays the chaos by failing to establish reusable standards.
Just read this? Test yourself on what you have been reading.
Read the original → smashingmagazine.com
- #design-systems
- #component-governance
- #decision-trees
- #ui-architecture
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.
We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles