UI/UX Designer interview questions and answers

UX design is about the whole experience a person has while trying to reach a goal with a product. It covers research, understanding needs, user flows, information architecture and testing whether people can actually complete tasks. UI design is the visual and interactive layer people touch: layout, typography, colour, buttons, icons and interaction states like hover or error. A simple way to say it is that UX decides what the product should do and how the journey works, while UI decides how each screen looks and feels. They depend on each other. A beautiful interface cannot fix a confusing flow, and a good flow can still fail if buttons are hard to see or read. In most product teams one designer does both, moving between research and visual detail.

I start by understanding the problem: who the users are, what goal the business has and what we already know from data or support tickets. Then I do research that fits the time we have, such as a few interviews or reviewing analytics, and write a clear problem statement. Next I explore several ideas with sketches and low-fidelity wireframes, and review them with the PM and engineers early to catch technical limits. I turn the best direction into a prototype and test it with around five users. I fix what I learn and test again if needed. After that I prepare a clear handoff with all states and edge cases. Finally I check the metrics after launch to see whether the change actually helped. The process is not strictly linear; I adjust it to the size of the problem.

Usability testing means watching real people try to complete realistic tasks with a design, so we can see where they struggle. For a simple test, I first write the goals and three to five tasks, such as finding a product and paying for it. I recruit around five participants who match our target users. In each session I explain that we are testing the design, not them, and ask them to think aloud. I give the tasks without hints and use neutral prompts like what are you expecting here. I note where they hesitate, make errors or give up. After the sessions I group the issues, rate them by severity, and share short findings with clips. Then the team fixes the top problems and, if possible, we test again.

Accessibility matters because a large share of people have a disability, and many more have temporary or situational limits, like a broken arm or bright sunlight on a phone screen. Accessible design is also required by law in many places and simply reaches more customers. In my designs I check colour contrast against WCAG AA, which is 4.5 to 1 for normal text. I make sure focus states are visible and that every action works with a keyboard. I never use colour alone to show meaning, I give form fields real visible labels, and I write alt text guidance for images. I keep tap targets large enough and support text resizing. I also test key flows with a screen reader, because checklists alone do not catch everything.

A design system is a shared set of reusable components, patterns, design tokens and guidelines that both designers and developers use to build a product. It usually includes things like buttons, inputs, modals, colour and spacing tokens, typography rules, and guidance on when to use each pattern, plus matching coded components. Teams use it for consistency, so the product feels like one product even when many teams work on it. It also saves time, because people do not redesign or rebuild a button every sprint, and it improves quality, since accessibility and states are solved once. A design system is a product in itself. It needs owners, documentation, versioning and a way for teams to request or contribute new components, otherwise it gets out of date and people stop using it.

I start with content, not styling: what is the one thing the user must understand, and what is the main action on this screen? Then I use visual tools to express that order. Size and weight make headings and key numbers stand out, while colour and contrast draw attention to the primary button, so there is only one strong call to action. Spacing and grouping show which elements belong together, and position matters too, since people scan from the top and along the reading direction. I keep secondary actions quieter, for example as text buttons. To check, I do a squint or blur test to see what stands out, and I test with users by asking what they notice first and what they would do next. If their answers match my intent, the hierarchy works.

Mobile first means I design for the smallest screen first and then expand to tablet and desktop. The small screen forces me to prioritise: there is room only for the core content and the main action, which usually makes the desktop design cleaner too. I also think about how people use phones: one hand, thumbs reaching the bottom of the screen more easily, large enough touch targets, interruptions and slower networks. So I keep pages light, put primary actions within reach and avoid hover-only interactions. Then, at larger breakpoints, I add layout columns, show more detail and use the extra space for things like side navigation. Many products get most of their traffic on mobile, so starting there aligns the design with how most users actually experience it.

Nielsen's ten heuristics are broad rules of thumb for usable interfaces. Examples are visibility of system status, matching the real world in language, user control and freedom like undo, consistency and standards, error prevention, and recognition rather than recall. I use them in two ways. While designing, they are a checklist: does every action give feedback, can users go back, are we using familiar words? I also run quick heuristic evaluations on existing products, ideally with two or three colleagues, noting each issue, the heuristic it breaks and a severity rating, so the team can fix the most serious ones first. They are quick and cheap, but they are expert judgement, so I still test with real users to confirm which problems actually trip people up.

I build repeated elements like buttons, inputs and cards as main components, and use instances everywhere else, so one change updates the whole file. Related versions go into a component set with variants, for example type, size and state, and I add component properties for things like an optional icon or the label text, which keeps the number of variants small. Every component uses auto layout so it resizes with content like real code would. Colours, typography and spacing come from variables and styles instead of raw values, which also makes light and dark modes easy. I name layers and properties clearly, publish the components to a team library and add short usage notes. I avoid detaching instances; if a component cannot do what I need, I improve the component instead.

First I question every field: if we do not need it now, we do not ask. Then I group questions logically and use a single column, which is faster to scan. Every field has a visible label above it, not a placeholder that disappears, with hints for format where needed. I pick the right input type, like a numeric keyboard for phone numbers and date pickers where they help, and I support autofill and password managers. Validation happens when the user leaves a field, and error messages say what went wrong and how to fix it, in plain words, next to the field. For long forms, an error summary after submit links to each problem. All of this must work with a keyboard and screen readers, and finally I test the form with users and watch field-level drop-off in analytics.

With one week, I start with research that already exists: analytics, support tickets, sales notes, app reviews and past studies. That often answers basic questions in a day. Then I list our riskiest assumptions and pick one or two to test. I might run three to five short calls with customers, or test a rough clickable prototype by day three or four using an unmoderated tool. I keep the scope tight and focus on the main task. I share findings quickly in a short summary so the team can act. I am also honest with the PM about what we could not validate, and I plan follow-up measurement after launch, like tracking task completion and running a quick survey. Small, fast research is much better than none.

First I listen and ask questions to understand what is behind the feedback. If someone says make the logo bigger, the real concern might be brand recognition or trust. Once I understand the goal, I can respond to that instead of arguing about pixels. I separate personal taste from impact on users or the business. If I still disagree, I explain my reasoning using evidence, such as research findings, analytics or accepted principles like accessibility guidelines. Often I show two options and the trade-offs of each. When we cannot agree and the risk is real, I suggest a quick usability test or A/B test so data decides. I also stay open to being wrong, because stakeholders often know things about customers or constraints that I do not.

I agree on the goal and the success metric with the PM before designing, and record a baseline. The metric depends on the change. For a checkout redesign it might be conversion rate and checkout drop-off. For onboarding it could be activation, meaning the share of users who reach the key action. I also choose guardrail metrics, such as support tickets, error rates or refunds, to make sure we are not improving one number while hurting another. Where possible we run an A/B test so the effect is clear. I combine numbers with qualitative data, like a short survey, session recordings or usability tests, to understand why the metric moved. After launch I share results openly, including when the change did not work, so the team learns.

Many designs only show the happy path, but real users meet empty, loading and error states all the time. A new user sees empty screens first, so those states shape first impressions. For empty states I explain what will appear here and give one clear action to get started, like create your first invoice. For loading I use skeleton screens or progress indicators that keep the layout stable, and I show results as they arrive if the wait is long. For errors I write plain messages that say what happened and what to do next, keep the user data, and offer a retry or another path. I design these states as part of the main flow, not afterwards, and include them in the handoff so developers do not have to guess.

I treat it as a shared problem, not a fight. I ask the engineer to show me which parts are expensive and why, for example a custom animation or a component that does not exist in our design system. Then I separate what really matters for users from what is nice to have. Often the core value can be kept with a simpler solution, like using an existing component or a standard transition. We sketch alternatives together, since engineers often know cheap ways to get a similar result. Then I bring the options to the PM with the trade-offs so we can decide the scope, maybe shipping a simpler version first and improving it later based on data. I also try to involve engineers earlier next time so surprises like this happen less.

I start by agreeing research goals with the product manager and engineers: what decisions will this research inform? Then I write a screener to recruit people who match the behaviour we care about, for example people who invoice clients monthly, usually five to eight per segment. My discussion guide moves from warm-up, to stories about recent real experiences, to deeper probes, with open questions like "Tell me about the last time" and no leading or hypothetical questions. During sessions I stay neutral, follow interesting threads and ask why, and I record only with consent while a teammate takes notes. Right after each session we write quick debriefs. At the end I synthesise using affinity mapping, turn themes into insights with evidence and quotes, and share a short readout with recommendations and open questions.

I begin with a content audit to see what exists, what is outdated and what can be merged or removed, combined with analytics and search logs to see what people actually look for. I talk with stakeholders about business priorities and with users about their top tasks. Next I run an open card sort with representative content to learn how users group and name topics. From that, I draft one or two candidate structures, and I test them with tree testing using realistic tasks, measuring success and where people go wrong. I iterate on labels and groupings until the key tasks score well. Then I design the navigation itself, the menus, breadcrumbs and search, and test it in a clickable prototype. Finally I plan redirects and governance so the structure stays healthy.

First I ask whether we really need it. Native selects are accessible by default and work well on mobile, and modern CSS lets us style the closed state quite a lot. If we still need a custom one, for example with search or rich options, I follow an established pattern like the WAI-ARIA combobox or listbox, ideally from a tested library. My spec covers keyboard behaviour: open with Enter, Space or Arrow keys, move with arrows, type to jump, Escape to close and focus returning to the trigger. It needs a visible label linked to it, a clear focus style, states like expanded and selected announced to assistive tech, enough contrast and big enough targets. Before release we test with VoiceOver and NVDA, keyboard only, browser zoom to 200% and touch devices.

I involve engineers and the product manager early, inviting them to observe sessions, because people act on what they saw themselves. After synthesis I write a small number of insights, each a clear statement backed by evidence such as quotes, clips and counts. I prioritise them by how many users were affected and how severe the impact is. Then I turn each important insight into "How might we" questions and concrete design opportunities, ideally with a metric we could move. I share a short readout, a page or a few slides with video clips, rather than a long report, and run a workshop to agree next steps and owners. Insights go into a research repository so they can be found later, and I check in a few weeks on what changed.

I start by framing the session: the problem, who the users are, the goal and success metric, the constraints and how far along the work is. Then I say exactly what feedback I need, such as "Is the comparison clear?" rather than "Thoughts?". I ask reviewers to tie comments to the goal and user, for example "this might make users miss X", and to describe problems rather than prescribe solutions. As facilitator I timebox discussion, ask quieter people directly and park off-topic debates. When I review someone else's work, I follow the same rules and also mention what works well. Critique is not where decisions are made, so I capture comments and then decide which to act on, and I share back what changed and why. This builds trust and keeps sessions useful.

I would first meet each group to understand the problem behind their request, not just the solution they want. Sales might want a feature banner because deals are lost, support might want clearer instructions because of ticket volume. Then I gather evidence: how many users are affected, analytics, ticket counts and revenue impact. Together with the PM, I map each request against our current product goals and score them by impact and effort. Sometimes one design can solve two needs at once. Prioritisation is the PM decision, so I support it with design input rather than deciding alone. I then share the decision with everyone, showing why some items wait and when we will revisit them. Being open about trade-offs keeps trust, even when people do not get what they asked for.

First I check that the drop is real. I work with analytics and engineering to rule out tracking bugs, performance problems or outside causes like a marketing campaign ending. If it is real, I segment it by device, browser, new versus returning users and funnel step, to see exactly where people are dropping off. Then I look for the reason using session recordings, support tickets and quick usability tests on the new flow. With a likely cause, I agree with the PM on action. If the loss is big and the fix is not clear, we roll back or put the old version behind a flag while we fix it. I communicate openly with stakeholders about what happened and what we are doing. Afterwards I push for staged rollouts or A/B tests on future redesigns.

I first make sure I understand both sides. A goal like increase upgrades is not wrong; the problem is usually how we try to reach it. So I clarify the actual target and the user need it touches. Then I look for designs that serve both, for example showing the value of a paid plan at the moment it is useful, instead of blocking free users with constant popups. If the proposed solution would harm users, like hidden fees or forced consent, I explain the long-term costs: churn, complaints, bad reviews and legal risk. I bring data and examples, and I propose an alternative we can test. I will not ship dark patterns, and if pressure continues I escalate with evidence. In my experience, solutions that respect users usually perform better over time.

I would start with an interface audit: screenshot key flows across all teams and group similar components to show how many versions of buttons, forms and modals exist. This makes the problem visible to leaders. Next I would work with engineering to build or improve a design system, starting with tokens and the most used components, built in code so teams can drop them in. Governance is as important as the components. I would set clear owners, a contribution model where teams can propose new patterns, design reviews for big changes, and good documentation. Rollout should be gradual, starting with new work and high-traffic screens. I would track adoption, such as the share of screens using system components, and regularly ask teams what blocks them. Consistency comes from making the right way the easy way.

I would not argue about research in general. I would talk in business terms. Building the wrong thing is the slowest path of all, so research is really a way to reduce risk and rework. I would look for a recent example, such as a feature that took two months to build and had low usage, and estimate what it cost. Then I would propose a small experiment: lightweight research that fits inside the normal sprint, like five quick tests on a prototype before development starts. When those tests find a serious problem early, I would share it with a short clip and the estimated engineering time saved. Over time I would link research to decisions and outcomes, like improved conversion. Leaders support research when they see it makes the team faster and more successful.

I start with risk: what happens when the AI is wrong? For low-risk tasks like suggesting a title, errors are cheap. For contracts or medical notes, the design must make verification easy. I set expectations clearly, label AI content and explain what it can and cannot do. Where possible I show sources or the input behind each claim so users can check quickly. The user stays in control: suggestions can be edited, accepted or undone, and high-stakes actions need confirmation. I design error and empty states for when the model fails or refuses. I add lightweight feedback like thumbs or corrections, which helps both users and the model team. Finally, I measure not just usage but whether users catch errors and whether their trust matches actual accuracy.

I take the goal seriously, since churn hurts the business, but I separate the goal from the tactic. Making cancellation obstructive is a dark pattern. Regulators in the US, EU and UK increasingly require cancelling to be as easy as signing up, and it damages trust, reviews and support costs. So I propose alternatives. An honest cancel flow can offer a pause, a cheaper plan or a relevant discount, presented once and easy to decline. An exit survey tells us why people leave, and those reasons often point to product fixes or onboarding gaps that reduce churn at the source. I suggest testing these options and measuring long-term retention and complaints, not just short-term saves. If I were asked to do something clearly illegal or deceptive, I would escalate rather than build it.

I would use layers. Primitive tokens hold raw values, each brand having its own palette and type families. Semantic tokens express purpose, like color.surface.default, color.text.muted or color.action.primary, and these are mapped per brand and per mode, so brand and light or dark are separate dimensions rather than six copies. Components reference only semantic tokens, with a few component tokens where a component needs its own decision, such as button radius differing by brand. In Figma, this maps to variable collections with modes; in code, a pipeline like Style Dictionary generates CSS variables and platform files from one source of truth stored in the repo. Strict naming conventions, review of new tokens and automated contrast checks for every brand and mode combination keep it healthy as it grows.

I start with contextual inquiry: watching dispatchers do real work in their environment, because experts do many things they cannot describe in an interview. I map the workflows, frequencies and the edge cases that cause stress. Design priorities differ from consumer apps. Efficiency matters more than first-time ease, so information density, keyboard shortcuts, bulk actions, saved filters and fast search are important, while new users still get help through clear labels. I respect existing muscle memory and change workflows gradually, with clear communication. High-stakes actions need clear states, confirmations or undo, and errors must be very clear. I measure success with time on task, error rates and how often users need workarounds, and I keep a panel of power users to test prototypes with real data, since fake data hides complexity.

I start by writing down what we know, what we are assuming and what would change our minds, so the team sees the uncertainty clearly. Then I look at risk and reversibility. If a choice is easy to change, like a layout or label, I decide quickly using design principles, analytics we already have, comparable patterns and the team's judgement. If it is costly to reverse, like a data model or pricing structure, I push harder for even a tiny test, such as five quick guerrilla sessions or a fake-door experiment. I usually pick the option that lets us learn fastest, ship it behind a feature flag to a small group, and agree on the metrics and qualitative signals we will watch. I also plan the date we review the decision, so it is a bet we evaluate rather than a permanent guess.