15 Questions to Ask a UX Designer Before You Hire One

The most useful questions to ask a UX designer are about how they think, not what they use — walk them through a real project's messy middle, their edge cases, and their developer handoff, and you'll learn more than any portfolio can tell you. Tools are easy to list on a résumé. Judgment shows up only when you ask the right follow-ups.

Hiring a designer is a bet, and most founders make it on the wrong evidence: a shiny portfolio, a confident call, a Dribbble grid of screens that never shipped. The interview is where you separate someone who makes things look good from someone who makes products work. Below are the questions I'd ask if I were on the hiring side — grouped by what they reveal, with the red-flag answers to listen for.

If you want the wider hiring context first — where to find designers, what a fair rate looks like — start with my guide on how to hire a UI/UX designer for SaaS. This piece is about the conversation itself.

Questions to ask a UX designer about process

You're not looking for a "correct" methodology here. You're checking whether there's a repeatable way of working underneath the pretty screens, or whether every project is improvised.

1. Walk me through one project from first brief to shipped — including what went wrong. This is the single most revealing question to ask a UX designer. Good designers talk about the messy middle: the assumption that turned out wrong, the feature they cut, the round of feedback that changed direction. Weak ones narrate a straight line from brief to beautiful mockup, which almost never happens in real work.

2. How do you decide what to design first when everything feels urgent? Prioritization is the job. Listen for how they weigh user impact against effort, and whether they involve engineering early. "I design what the client asks for" is not the answer you want — you're hiring judgment, not a pixel vending machine.

3. What do you do when you disagree with a product decision? You want someone who'll push back with reasoning, then commit once the call is made. A designer who never disagrees isn't thinking; one who can't let go will fight you in every review.

Questions about product thinking

A designer who only thinks in screens will hand you screens. A designer who thinks in outcomes will occasionally tell you the feature you asked for is the wrong feature — and save you weeks.

4. How do you know if a design actually worked after it launched? Strong answers mention specific signals — task completion, drop-off, support tickets, a metric tied to the feature's goal. If the answer stops at "it looked clean" or "the client was happy," you're talking to a decorator, not a product designer.

5. Tell me about a time you talked a client out of building something. This shows whether they see themselves as a partner or an order-taker. The best designers have killed a feature or two, and they can explain the reasoning without ego.

6. Who are the users for the last product you designed, and how did you learn about them? You're checking for genuine curiosity about the person on the other side of the screen. Even without a formal research budget, a good designer finds ways to learn — support logs, sales calls, five quick user conversations.

Questions about states and edge cases

This is where most portfolios go quiet, and where real software lives. Anyone can design the happy path. The difference between a junior and a senior shows up in everything around it.

7. Show me how you'd design the empty, loading, and error states for one of these screens. A designer who has shipped real products reaches for these automatically. If they've only ever mocked up the perfect-data version, your engineers will end up inventing these states themselves — badly, at 5pm on a Friday.

8. What happens in your design when the text is twice as long, or the list has 500 items instead of 3? Real content is messy. Long names, missing images, huge tables, tiny mobile screens. You want a designer who has felt this pain and designs for it up front.

9. How do you handle accessibility — contrast, keyboard navigation, screen readers? Even a basic, honest answer ("I check contrast ratios and don't rely on color alone") beats a blank stare. Accessibility isn't optional in most markets anymore, and retrofitting it is expensive.

Questions about developer handoff

A design only matters once it's built. If handoff is an afterthought, half of the craft you paid for leaks out between Figma and production. This is also where the line between roles gets blurry — my breakdown of a UI designer vs. a frontend developer is worth a read if you're unsure who owns what.

10. What exactly does a developer receive from you? Listen for specifics: organized layers, named components, spacing and type tokens, documented interaction states, notes on responsive behavior. "I share the Figma link" is the floor, not the ceiling. A frontend-ready handoff is the difference between a build that matches the design and one that drifts.

11. How do you handle questions from engineers mid-build? Handoff isn't a one-way toss over the wall. You want a designer who stays reachable, answers quickly, and treats developer feedback as part of the process rather than an interruption.

12. Have you worked inside an existing design system or component library? Most real products aren't greenfield. A designer who can work within constraints — reuse components, respect existing patterns — will move faster and cause fewer merge headaches than one who redesigns from scratch every time.

Questions about communication and timezone

Talent means nothing if you can't reach the person. For distributed teams, this section quietly decides whether the engagement feels smooth or exhausting. If you're weighing a solo designer against a studio or a full-time hire, my comparison of freelance vs. agency vs. in-house designers covers the tradeoffs in depth.

13. What are your actual working hours in my timezone, and how do you handle the overlap? Don't accept "I'm flexible." Get specifics. I work from Bangladesh (GMT+6) with US startups, so I front-load overlap hours and keep async updates tight — the point is that a good remote designer has a concrete system, not a vague promise. Ask how they'll keep you unblocked when they're asleep and you're at your desk.

14. How often will I hear from you, and what does an update look like? Regular, specific updates — with visible progress — beat silence punctuated by a big reveal. Ask to see what a typical weekly update looks like. Radio silence is one of the most common complaints founders have about remote designers, and it's entirely preventable.

Questions about pricing and scope

15. How do you price a project like mine, and what happens when scope changes? This last one filters out a lot of future pain. You want a clear, honest answer: a fixed written quote where the work is well-defined, a transparent hourly or weekly rate where it isn't, and a straightforward way to handle new requests. Vague pricing — "we'll figure it out as we go" — is how projects quietly double in cost.

Ranges vary widely by scope and seniority, so be skeptical of anyone who quotes a firm number before understanding your project. What you're really testing is whether the money conversation is clear and comfortable now, because it only gets harder once work is underway.

Red-flag answers to watch for

Across all fifteen questions, a few patterns should make you pause:

• Only happy-path screens. No mention of empty, error, or loading states means limited real-world shipping experience.
• Tool worship. If every answer is about Figma features rather than decisions and outcomes, the thinking is thin.
• No disagreement, ever. A designer who agrees with everything won't protect you from bad ideas — including your own.
• Handoff as an afterthought. "I just send the link" signals that a lot of quality will be lost in translation.
• Vague on time, money, and availability. These are the easy things to be specific about. Vagueness here predicts vagueness everywhere.
• Portfolio with no context. Pretty screens with no story about the problem, the constraints, or the result are decoration, not evidence.

None of these are automatic disqualifiers on their own. But two or three together usually tell you what the next three months will feel like.

If you're a founder weighing a designer right now and want a straight answer rather than a sales pitch, tell me about your project on the contact page — I reply within 24 hours with an honest read and a fixed written quote where the scope allows. You can also see how I work specifically as a UI/UX designer for US startups if timezone and handoff are on your mind.