Walk me through your design process from brief to delivery.

My process starts with understanding the problem before touching any design tools. I begin with a discovery phase: reviewing any existing research, running stakeholder interviews to align on goals and constraints, and doing competitive analysis if time allows. From there I move to user research, whether that is interviews, contextual inquiry, or reviewing analytics, to understand who I am designing for and what they actually need. I then define the problem clearly, often with a "How Might We" framing, before moving to ideation. I sketch broadly, then converge on the most promising directions to prototype. I test prototypes with real users as early as possible, even paper prototypes, so I am not discovering problems after engineering investment. Handoff includes annotated specs, edge cases documented, and I stay involved through implementation to catch anything that loses fidelity.

How do you handle situations where stakeholders push back on your design decisions?

I treat pushback as information, not opposition. My first step is to understand what is driving the concern: sometimes it is a legitimate constraint I was not aware of, sometimes it is risk aversion, and sometimes it is personal preference dressed up as business logic. I distinguish between those. For genuine constraints, I adapt the design. For risk aversion, I propose a lightweight test to reduce uncertainty. For personal preference conflicts, I bring the decision back to user research or data rather than making it a debate about taste. I have learned to present design decisions with the rationale attached from the start, which reduces the frequency of pushback in the first place. When a stakeholder overrules a decision I believe is wrong for users, I document my concern, ask for a review metric to track, and revisit when data comes in.

How do you measure whether a design is successful?

Success depends on what the design was meant to achieve, so I start by agreeing on metrics before I start designing. For task-based flows, I track task completion rate and error rate, often through usability testing first and then analytics in production. For broader product goals, I connect my work to business metrics like conversion, retention, or support ticket reduction. I also track qualitative signals: are users able to describe what a feature does without help? Do they express frustration or confidence during testing? I am sceptical of proxy metrics like "time on page" that can signal engagement or confusion equally. After launch, I do a structured review at 30 and 90 days and bring findings back to the team to close the loop on design decisions.

Tell me about a time you had to design under significant constraints.

At a previous company, I was asked to redesign an onboarding flow for mobile with a two-week turnaround and no budget for additional user research. Rather than starting from scratch, I pulled analytics data to identify the three highest drop-off steps and mapped the existing flow against competitive benchmarks to spot obvious gaps. I ran five guerrilla tests in the office with colleagues who matched our user profile for directional validation. I focused my redesign on those three problem areas rather than overhauling everything, which kept the scope manageable and made the engineering work feasible in the timeline. Drop-off at the critical step fell by 18% in the first month. The constraint forced me to be more surgical and data-driven than I might have been with unlimited time.

Describe a time your design was wrong and how you handled it.

I designed a new navigation structure for a B2C app that I was confident about after internal testing. After launch, support tickets about not being able to find key features increased by 30% in the first week. I had not tested with enough users who were unfamiliar with the old navigation: our internal testers had muscle memory that masked the problem. I flagged it to the team immediately rather than waiting to see if it would resolve. We ran an emergency usability test with five external users within 48 hours, which confirmed the issue and identified two specific points of failure. We shipped a targeted fix within a week. The lesson I took was to always include users with zero prior exposure to the product in navigation tests, and I now build that into my research protocols by default.

How do you collaborate with engineers who push back on your designs?

I try to understand the concern before advocating for the design. Engineering pushback usually comes from one of three places: technical infeasibility, effort that outweighs perceived value, or a preference for a simpler solution they have already imagined. The first two are legitimate inputs I factor in. For feasibility issues, I ask what is possible and redesign within that constraint. For effort concerns, I ask for a rough estimate and use that to decide whether to simplify or hold the line if the design is solving a real user problem. I have found that involving engineers earlier in the process, sharing research findings and inviting them into the problem framing, dramatically reduces friction later. When we disagree, I prefer to prototype the disputed interaction and test it rather than debate it in a meeting.

How do you approach accessibility in your design work?

I treat accessibility as a design constraint from the start, not a checklist at the end. In practice, this means choosing colour combinations that meet WCAG AA contrast ratios during the design phase, sizing touch targets to at least 44px, and designing for keyboard navigation alongside mouse. I use semantic structure in my specs so engineers know which elements map to headings, buttons, or landmarks. I also design for different input modes, including screen readers, which means writing meaningful alt text guidance and thinking about focus order. In usability testing, I try to include at least one session with a user who relies on assistive technology when the product serves a broad audience. I have found that designing accessibly usually produces cleaner, more considered UX for everyone.

Walk me through how you would approach a usability test from scratch.

I start by defining what question I need the test to answer, because the method follows the question. For evaluative testing of a specific flow, I use moderated task-based testing with five to eight participants: enough to surface patterns without over-investing. I write tasks in outcome terms, not instructions: "You want to find your order history" rather than "click the account menu". I use think-aloud protocol to capture reasoning, not just behaviour. I note hesitations, errors, and unexpected paths, not just whether the user completed the task. I debrief after each session to capture my impressions while fresh. I analyse by clustering observations across participants, looking for patterns rather than individual preferences. I present findings with severity ratings and prioritised recommendations, tied back to the original question, so the output is actionable.

How do you decide between high-fidelity and low-fidelity prototypes?

The fidelity should match the question I am trying to answer. For exploring whether a concept makes sense structurally, a rough sketch or paper prototype is faster and removes the risk of people reacting to visual polish rather than the interaction. For testing specific microcopy or visual hierarchy, I need enough fidelity that the wording and layout are as close to final as possible. For stakeholder presentations where buy-in depends on them seeing the vision, higher fidelity reduces the cognitive effort required to imagine the finished product. I also consider the development stage: if engineering is about to start on a feature, a higher-fidelity prototype gives them something closer to the spec. The mistake I see most often is investing in high fidelity too early, before the structure is validated, and then having to throw away polished work.

UX Designer

UX Designer interviews assess your design thinking process, your ability to advocate for users, and how you collaborate with product and engineering. Interviewers want to see portfolio work that demonstrates clear problem-solving, not just polished visuals. This guide covers the questions that come up most often and the answers that distinguish designers who ship great products from those who only deliver beautiful mockups.

For general interview preparation tips, read our guide to common interview questions.

Common UX Designer Interview Questions

Behavioral Interview Questions for UX Designer Roles

Technical Questions for UX Designer Candidates

What Hiring Managers Look for in UX Designer Interviews

What hiring managers really look for in UX Designer candidates:

Process over portfolio. A polished case study with no rationale is less impressive than a messier process that shows clear thinking. Walk them through the problem, not just the solution.
Genuine user empathy. Can you describe real users with specificity? Designers who talk about "users" as an abstract group often have not done enough research.
Collaborative instinct. UX designers who work well with engineering and product get their designs built. Those who treat collaboration as a compromise tend to create friction.
Comfort with ambiguity. The best designers can operate when the brief is vague or the data is thin. Show how you create structure in uncertain conditions.
Business awareness. Knowing why the product exists commercially, and designing with that in mind, is what separates senior designers from junior ones.

Questions to Ask Your Interviewer

→How does the design team collaborate with product and engineering day to day?
→What does the research process look like here, and how much time do designers get for discovery?
→How are design decisions documented and communicated to engineering?
→What does success look like for a UX designer in the first six months?
→How does the company gather and act on user feedback after launch?

Practice These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free during beta. No commitment.

Related Roles