How to Screen UX Designers: 9 Questions and What to Listen For Screening Interview Template

Pick the project in your portfolio you would want to be judged on. What shipped, which parts were yours versus the team's or an agency's, and is it still live today?

What this assesses: The word shipped is doing the work. Strong answers name a product real users touched, separate their part from everyone else's without being pushed (they ran the research and owned the flows, another designer held the visual system, an agency built the marketing site), and know the current state, including that it was since replaced or rebuilt. Weak answers describe a concept redesign, stay in we for the whole story, or cannot say anything about the work after launch. A good share of portfolio case studies never shipped in the form shown, and this question surfaces that in one sentence instead of thirty minutes into a walkthrough.

Tell me about a time research changed the design. What did you run, how many people did you talk to, and what specifically changed as a result?

What this assesses: Ask for the method, the count, and the change, because thin answers fall apart on all three. Strong answers name what they actually ran, whether that was six moderated sessions, an unmoderated test on five tasks, a sweep through support tickets, or ten sales calls they sat in on, and then name a concrete change: the flow lost a step, the default flipped, a feature got cut. Weak answers say the research validated the direction, which means nothing changed, or describe research someone else ran and handed over. A designer who has only ever received findings will need somebody to keep feeding them.

What did the last thing you shipped change in the numbers? Name the metric you or your PM watched and what it did.

What this assesses: Strong answers name a metric that existed before the project started, give the before and after, and are willing to say it moved a little or not at all. Completion rate on an onboarding flow, support tickets about one screen, time to first invoice. Weak answers give a round percentage with no baseline, quote a satisfaction score with no sample size, or say the team never measured it. Not measuring is common and forgivable at a small company. What matters is whether the candidate noticed the gap and pushed on it. Designers who never look downstream of launch will keep shipping things nobody uses and file it as a win.

Walk me through what happens between your final file and the thing running for users. How do you hand off, who builds it, and how do you find out when what shipped is not what you designed?

What this assesses: This one question tells you more about a designer's real environment than any portfolio. Strong answers describe an actual path: what the file carries for engineers, whether specs live in the file or the ticket, how much time they spend in build review, and how they catch drift, which is usually clicking through staging themselves rather than waiting for QA. They will also name what they chose to let go. Weak answers stop at I hand the file to engineering. Someone who has never sat with the built version has never had to defend a design against the twenty small compromises that happen after the file is done.

What is your relationship with the design system where you work now? Did you use one, help build one, or work around one, and when did you last break from it on purpose?

What this assesses: All three answers can be strong. The specifics and the last clause are what separate them. Strong answers describe the real arrangement, whether that is contributing components back through a review process, inheriting a library nobody maintains, or building the first version themselves in a week because there was nothing. Then they name a deliberate break with a reason attached: the standard table could not carry the density this workflow needed, so they made a variant and documented why. Weak answers treat the system as either sacred or irrelevant. A designer who never breaks from it has not hit a hard problem yet, and one who always does will hand your engineers forty unique buttons.

Pick one screen you designed. What did you do about accessibility on it, specifically?

What this assesses: Specifically is the entire question. Strong answers name real decisions: contrast checked against a ratio rather than by eye, visible focus states designed rather than left to the browser, touch targets sized for a thumb, form errors tied to the field and readable by a screen reader, no meaning carried by color alone. Weak answers say they follow [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) and stop there, or describe accessibility as something engineering bolts on at the end. If your product touches government, education, healthcare, or any procurement process with a checklist, this answer is worth more than the portfolio.

Tell me about a design decision you lost. What was the argument on the other side, and what happened after it shipped?

What this assesses: The tell is whether they can state the opposing argument fairly. Strong answers restate it in a way the PM or the engineer would recognize, whether the reason was cost, a deadline, a technical limit, or evidence the designer did not have, and then say what actually happened afterward, including the times the other side turned out to be right. Weak answers make every loss a story about stakeholders who did not get it, or cannot remember losing one. A designer who has never lost an argument has usually never been in a room where anything was at stake.

How do you use AI tools in your design work day to day, and tell me about something one produced that you threw out.

What this assesses: This is a judgment question, not a loyalty test. Strong answers are specific about where the tools help, usually realistic filler content, first-pass interface copy, variants to react to, and synthesizing a pile of research notes, then name a concrete override: a generated flow with no error state, copy that sounded like every other product, a layout that collapsed at the second breakpoint, a synthesis that flattened the one interview that mattered. The signal is that they looked closely enough to reject it. Weak answers refuse the tools on principle without a reason, or describe a process where generated screens go straight into a ticket.

Between research, interaction and product thinking, visual craft, and systems work, where are you genuinely strong and where would you need support? And what would make you turn this role down?

What this assesses: Ask for both halves. On the first, strong answers claim one or two areas, name the boundary of each, and are direct about the gap: strong on complex flows and empty states, slower on brand and marketing pages, comfortable running usability tests but has never done generative research. Weak answers claim all four at the same level, which nobody is. On the second half, strong answers name real constraints such as compensation, remote expectations, whether they would be the only designer, or how much of the job is production work against someone else's spec. That is a candidate telling you where the offer will fall apart while it is still cheap to know.