Top 20 UX Designer Interview Questions
(Junior & Graduate), Answered

Walk through the stages you actually follow: understand the problem (business goals, user goals, constraints), research (existing data, user interviews, competitor analysis), define (a problem statement, personas or jobs to be done), ideate (sketch lots of options before narrowing down), prototype (low or high fidelity, depending on what you need to test), test (usability testing with real users), and iterate and hand off. Make it clear that you start by understanding the problem, before you draw any screens, and use a real project to show each stage as you go.

User-centred design is an approach that puts the needs, goals and context of the people who'll use a product at the centre of design decisions. Without it, teams build on guesses about what users want and are more likely to solve the wrong problem. UCD is iterative: you involve users at every stage, from early research to testing, so you can catch misunderstandings before they're built. It also saves money, because a problem found in a prototype is much cheaper to fix than one found after launch.

Describe the methods you've actually used, then explain when you'd choose each. User interviews are qualitative and exploratory, good for understanding people's motivations and how they think about a task. Surveys reach more people, so they're good for measuring how common a need or opinion is, though they tell you what people say rather than what they do. Usability testing means watching people use a design, so it shows where a flow causes trouble. Card sorting helps with information architecture: how to group and label content. Analytics shows what large numbers of users do, but not why they do it. The methods work well together. Analytics might show where people drop out of a sign-up flow, and a usability test can show you why.

UX (user experience) design covers the whole experience of using a product: the flows, the information architecture, the content, and whether the product helps people do what they came to do. Most of it is problem-solving. UI (user interface) design is the visual and interactive layer: typography, colour, spacing, components and motion. UI is part of the overall experience, and many roles cover both. A product can look polished and still be confusing to use, or be easy to use and still feel clumsy. Teams need both skills.

Accessibility means designing for the full range of people who'll use the product, including people with vision, hearing, motor and cognitive disabilities. Practical steps: meet WCAG colour contrast requirements (at least 4.5:1 for normal text at level AA), make every interactive element usable with a keyboard, don't rely on colour alone to carry meaning, write alt text for images that carry information, and check that it works with a screen reader. Beyond compliance, much of this makes the product better for everyone: clear contrast, large tap targets and plain labels help all users. Build it in from the start, because it's harder to retrofit later.

Name what you've actually used: Figma or Sketch for design; Maze, UserTesting or Lookback for research; Miro or FigJam for workshops; Notion or Confluence for documentation. If you learned Adobe XD at uni, mention it, but Adobe is no longer adding features to it, so make sure you can work in Figma too. Then explain how you choose: paper or a whiteboard for quick early ideas, Figma for prototypes the team works on together, a video call where the participant thinks aloud for moderated usability tests, and a tool like Maze for unmoderated tests with more people. Show that you pick the tool to suit the task.

A design is ready when it solves the problem you defined without adding new friction, fits the technical and business constraints, and has been tested enough that you're confident in the main flows. You'll never remove all the uncertainty, so aim to reduce it to a level that suits the risk. For low-risk changes, ship and measure. For high-stakes flows such as payments or onboarding, test more before you ship.

Give your walkthrough a shape: problem (what you were solving, and for whom), constraints (time, team, platform, business requirements), process (the research or discovery you did), decisions (what you chose, and your reasons), outcome (what shipped and how it performed) and reflection (what you'd do differently). In a team project, be clear about which parts were yours. Don't skip the reflection. Nobody expects a perfect project, but they will want to hear what you learned.

Pick a real example. Describe the decision, why it made sense at the time, what you found out later (from user testing, analytics or feedback) and what you'd do differently. If you can, show how spotting the mistake led to a better version, so the story ends with what you changed as well as what went wrong.

First, work out what kind of pushback it is: a technical constraint, a business concern or a difference in taste. A real constraint is usually worth designing around, while a difference in taste is worth discussing with evidence. Explain your reasoning: what user problem the design solves, and what risk the alternative carries. If their concern is valid, change the design. If you still think the original is right, suggest testing both. Keep the conversation on what's best for users.

Pick something you've actually struggled with, ideally less obvious than the usual examples. Describe the friction you ran into, suggest why it might have happened (a technical limit, competing priorities inside the company, not enough research), and propose a specific change. Be specific and fair, and acknowledge the constraints the original team may have had. They'll be listening to how you reason and explain as much as to your taste.

Stay involved during the build as well as at handoff. Practical steps: involve engineers early, so constraints come up before they're expensive to fix; make handoff files thorough, with edge cases and interaction states written down; be available during the build to answer questions and review work in progress; and do a design QA before launch to catch anything that doesn't match. The relationship helps too. Engineers who feel respected by the designer are more likely to care about getting the details right.

After launch, watch the analytics for unexpected behaviour: where people drop off, features nobody uses, error rates. Collect qualitative feedback from support tickets, in-app surveys or follow-up interviews. Post-launch data shows how people use the product for real, which research before launch can only partly tell you. Log what you learn, prioritise the changes, and feed them into the next design cycle.

Describe the constraint clearly: a tight timeline, little access to users, technical limits or strict brand rules. Then walk through how you worked within it: what you traded off, what you prioritised and how it turned out. Constraints often force you to decide what's most important, so show that they sharpened your thinking rather than stopping you.

Describe the tension, such as the business wanting a promotional banner in the middle of a key flow, or an engineer suggesting a shortcut that would confuse users. Walk through how you made your case, with data, quotes from users or a quick test rather than your opinion. Show that you persuaded people with evidence, and that when you didn't win, you suggested a compromise that kept the most important part of the experience intact.

Be honest. Describe the feedback, your first reaction (it's fine to admit it stung) and what you did with it. End on what changed: the work got better because of the feedback, or you learned something that changed how you approach design reviews. A designer who gets defensive is hard to work with, so show that you listened.

Describe what was unclear: vague requirements, stakeholders with different ideas of success, or a user problem nobody had defined. Then walk through how you made enough sense of it to move forward: which assumptions you wrote down, what you decided to find out first, and how you narrowed the problem to something you could act on. Make the steps you took to get clarity the centre of the story.

Be specific. Name what you actually read or follow, such as Nielsen Norman Group (NN/g) or UX Collective, podcasts, communities, courses, or designers whose work you like, and say why. Then mention something you learned recently and how it changed your work. The detail is what makes the answer believable. "I follow NN/g" is fine. "I read an NN/g article on form design and changed how I lay out our sign-up flow" is much better.

Be honest about your interests. If you're drawn to research, say so. If it's design systems or product strategy, say that. Then connect where you'd like to be in three years with what this role offers. Show that you want to grow as a designer, that this role is a real step in that direction, and that you've thought about it beyond getting a job.

Good questions for UX roles: "How closely do designers work with engineering and product here? Are you involved from the start, or is it more of a handoff?" / "Is there a dedicated research team, or do designers run their own research?" / "What does the design review process look like?" / "What's one design decision the team wishes it had made differently in the last year?"