Designer Interview Questions

I would pick a case where I was genuinely wrong rather than one where the research was flawed. I would explain the decision and why it seemed right, what the research actually showed, and how I separated a usability failure from a comprehension failure before changing anything — those look the same in a session and have opposite fixes. Then what I changed and what the next round showed. The strongest answers say what they now do earlier to catch that class of mistake, usually testing the riskiest assumption before building the polished flow.

I would design for the constraint rather than degrade to it: fewer network round trips, content that renders before images arrive, tap targets that work one-handed on a cracked screen, and slow and offline states that are designed rather than accidental. I would test on a real budget device, not a throttled desktop. For India I would also weigh data cost, intermittent connectivity, and devices shared between family members. A strong answer names something they cut to make it fast, not only something they added.

I would start from what the business needs the redesign to change, then use the evidence that already exists — funnel analytics, support tickets, session recordings, and what the team already believes is broken. I would run the core tasks myself and mark every point where I hesitate. Then I would sort the findings into usability, comprehension, and scope problems, since each needs a different fix. The strongest answers finish with a prioritised list tied to a metric rather than an inventory of everything that looks dated.

A variant when the purpose is the same and only the emphasis changes — a secondary button is still a button. A new component when the behaviour, the content model, or the accessibility semantics differ, because forcing those into a variant produces props that are mutually exclusive and a component nobody can use safely. I would also weigh maintenance, since every variant is permanent. A good answer says how they check whether the need is general or one team’s local preference.

I would find where the drop-off actually is before touching the design: which step, which device, which payment method. Most checkout loss is not aesthetic — unexpected cost, a forced account, a payment that fails with no way to recover, or validation that only fires after submit. I would fix the largest measured leak first and instrument the change so we know whether it moved. For India I would look hard at payment method coverage and retry behaviour. A strong answer says what they would test, not what they would redesign.

Contrast is the easiest part to fix and the least of it. I would talk about focus order and a visible focus state, labels that still make sense read out of context, touch target size, error messages that say what to do rather than what went wrong, motion that respects a reduced-motion preference, and layouts that survive 200% zoom. I would also mention testing with a keyboard alone and with a screen reader, because those find the problems no automated audit reports.

I would ask what specifically is expensive, because usually one detail carries the cost rather than the whole design. Then I would offer the version that keeps the user outcome and drops that detail, and be explicit about what we lose by doing it. If it genuinely cannot ship, I would rather cut scope than ship a half-built interaction, since a broken animation reads as a broken product. A strong answer treats the developer as the person who knows the real cost, not as an obstacle to route around.

I would use the cheapest method that still produces evidence: a five-person hallway test, a first-click test, an unmoderated task on a prototype, or simply reading support tickets for that flow. I would test the riskiest assumption rather than the whole design, since that is where the information is. I would also be honest about what a small sample can do — it finds usability problems reliably and measures preference badly, so I would not use it to settle a debate about which version people like.

A usability problem is when someone knows what they want and the interface makes it hard to get. A comprehension problem is when the interface works fine and they do not understand what it is for or what will happen if they proceed. In a funnel they look identical, and the fixes are opposite: one needs interaction changes, the other needs language, sequencing, or expectation-setting. A strong answer says how they tell them apart in a session, usually by asking what the person expects to happen before they click.

I would not defend pixels in the room. I would ask what problem the change is solving, because there is almost always a real concern underneath a bad suggestion. Then I would take it away, come back with that concern addressed in a way that holds up against the research, and show the tradeoff explicitly. If they are the decision-maker and still want it their way, I would state the cost in writing and move on. A strong answer separates preference from evidence without making the stakeholder wrong in public.

I would plan for text expansion and let containers grow rather than fixing heights, keep text out of images, and check that the type stack renders Devanagari correctly at every weight I use. Numerals, dates, and currency should follow what people actually read locally. The harder part is register: a literal translation of English microcopy usually sounds wrong or too formal, so I would have it reviewed by someone who uses the product rather than only by a translator.

I prototype when the risk is in the interaction — timing, gesture, state changes — or when I need to test comprehension before committing engineering time. I ship straight to build when the pattern is already established in the product and the risk is low, because prototyping something we are already sure about is waste. A strong answer names the specific question the prototype exists to answer, since a prototype without a question turns into a demo and gets judged on polish instead.

In my last Designer project, I found a repeated bottleneck in user research, interaction decisions, craft, and stakeholder alignment and turned it into a focused improvement plan. I defined the baseline, aligned the team on the metric, shipped the change in two iterations, and reviewed the result after launch. The strongest version of this answer names the exact metric you moved, the decision you owned, and the tradeoff you made to get the result without hiding team contributions.

I would describe a situation where I needed buy-in from a peer team or senior stakeholder, then show how I earned trust with evidence rather than pressure. A strong answer explains the other person’s concern, the evidence I used to reduce their risk — in Designer work that usually means something concrete drawn from user research, interaction decisions, craft, and stakeholder alignment — and the compromise that moved the work forward. The outcome should show influence through clarity, not title power.

I would pick feedback that changed a real work habit, not a harmless weakness. For example, I once received feedback that my updates were too technical for business stakeholders, so I started sending one-line context, impact, risk, and next step summaries before deeper detail. For a Designer the feedback worth choosing is one that changed how you handle user research, interaction decisions, craft, and stakeholder alignment. The answer should end with evidence that the change stuck, such as faster decisions, fewer clarification meetings, or better stakeholder confidence.