UX Designer Interview Questions and Answers

On a billing settings project the constraint was a two-week window before a pricing change shipped. I watched a handful of support calls and read a quarter of related tickets, which showed that people could not tell which plan they were on. From there I sketched three ways to surface the current plan and prototyped the two most different ones in Figma. A quick unmoderated test killed the option I liked, because the comparison table made the upgrade path harder to find. We shipped the simpler version. What I would change is capturing a baseline of plan-related tickets before launch, so the improvement was easier to attribute afterward.

When time is short I rank questions by the cost of being wrong. If a decision is expensive to reverse, such as the core navigation model, I will argue for a few moderated sessions or a tree test. If it is a label change, I will ship it behind a flag and read the analytics instead. I also hunt for existing evidence first, because support tickets, search logs, session recordings and past studies often answer the question without new fieldwork. The worst move is running a large survey that cannot inform any decision before the deadline, so I would rather do five focused interviews and be explicit about the gaps I am accepting.

I try to separate the request from the risk behind it. A stakeholder asking to skip research is usually reacting to a deadline, so I ask what decision they need to make and when. Then I offer the smallest study that could change that decision: five quick sessions, a five-second test, or a review of support data we already have. I explain what guessing costs in their language, such as rework or a launch metric that misses. If they still say no, I write down the assumption we are betting on and propose a lightweight check after release. I push back with evidence, never with principle alone.

We had a checkout redesign where I assumed the address form was fine and the payment step was the problem. In six moderated sessions every participant hesitated at the same field: a phone number that asked for a format nobody recognized, and two people abandoned on mobile. That single finding redirected the work. I dropped the phone requirement for digital goods, added inline format hints, and retested with a handful more participants, where nobody paused at that step. The lesson I carry is that the session you are most tempted to skip, on the part you are most confident about, is often where the real problem hides.

I treat accessibility as a constraint from the first wireframe rather than a review at the end. That means ordering content so it makes sense without styling, checking color contrast while choosing the palette, and designing focus order and visible focus states as deliberately as hover states. I annotate the prototype with heading levels, labels, minimum touch target sizes and what should be announced by a screen reader, so engineers are not guessing. Then I test with keyboard only and, where possible, with a screen reader user. If a component cannot be made accessible, that usually means the interaction is wrong, so I go back a step instead of shipping an exception.

I start by assuming the engineer knows something I do not, because usually they do. I ask them to walk me through the specific constraint: is it the data model, the rendering cost, a third-party library, or simply the time to build it? That answer decides my response. If the constraint is real, I redesign within it, because a design that cannot ship is not a design. If it is a preference or a stale assumption, I show the evidence from testing and propose a small spike or a phased version to learn. What I avoid is turning it into a turf fight, since the goal is a better product, not a winning argument.

When two options both look defensible, I write down the criteria before I judge them: which user goal each serves, what each costs to build, what it does to a metric we care about, and how reversible it is. Then I look for the cheapest test that separates them, often a first-click or preference test on prototypes. If testing is not possible, I ask which option fails more gracefully and lean that way, because a design that degrades well is usually safer. I also notice which option I am biased toward and deliberately argue the other side before I commit to a recommendation.

I pick the measure before I design and match it to the goal. For a task flow that means completion rate, time on task and error rate, plus a qualitative read on where people hesitate. For discovery work it might be whether users can find a specific item or how many searches fail. Analytics like funnel drop-off and support ticket volume help after release, but they need a baseline to mean anything. I also keep qualitative signals, such as quotes and severity-tagged findings, because a completion rate can improve while the experience still feels confusing to the people using it.

I design states as part of the screen, not as an afterthought. For an empty state I ask why it is empty: first run, a cleared filter, missing permissions, or a failure. Each has a different message and action, so I write the actual copy rather than placeholder text. Loading states should explain what is happening and roughly how long it may take, with skeletons that match the final layout so the page does not jump. Error states say what went wrong in plain language, what the user can do next, and how to recover any lost input. I prototype those recovery paths and test them, because that is where people give up.

Attach a before-and-after metric, even a small one, such as fewer failed searches or fewer support contacts.

Show contrast choices, focus order and annotations in the work itself, and mention testing with keyboard or assistive tech.

Tie each tool to an artifact and an outcome, for example a prototype tested with participants that removed a dead end.