Hiring a UI designer based on polished screenshots can leave you with attractive screens that fall apart when users make mistakes, data is missing or developers start building. Before you commit, evaluate the decisions behind the visuals: interface behavior, accessibility, reusable components and how clearly the candidate communicates constraints.
The strongest evidence comes from a combination of portfolio work, a structured conversation and a small paid exercise. No single screenshot, tool certification or interview answer can establish whether someone is right for your product.
This guide gives founders and hiring managers a practical evaluation process, including questions to ask, artifacts to inspect and a scorecard for comparing candidates fairly.
Define the role before reviewing portfolios
Start with the work you actually need done. Designing a conversion-focused website, a mobile checkout and a data-heavy SaaS application require different experience. A portfolio can be excellent and still be a poor match for your project.
Write a short role brief that identifies your users, their main tasks, the platforms involved and the expected deliverables. Specify whether the person will work within an existing component library or help establish one.
A UI designer typically focuses on the interface’s visual hierarchy, layout, components and interaction states. UX responsibilities can overlap, but do not assume the role automatically includes user research, product strategy or usability testing. Likewise, designing an interface does not establish front-end engineering ability.
Define those boundaries before assessing candidates. If your gap also includes product direction and implementation, comparing a technical partner with individual developers can help you decide whether a design-only hire is enough.
Evaluate portfolio evidence, not presentation quality
Ask the candidate to walk through one relevant project in depth. A detailed discussion of a shipped workflow usually reveals more than a tour of ten polished landing pages.
Establish the context first: who used the product, what they needed to accomplish and which constraints shaped the work. Then clarify ownership. Did the candidate create the interface, contribute selected screens or mainly apply an existing design system?
When evaluating a UI designer, look for a clear connection between the problem, the design decisions and the resulting interface. Ask to see an earlier version, a rejected approach or a change made after feedback. These artifacts reveal how the work developed rather than just how it was presented.
Match the evidence to your product’s complexity. Valnee’s Northstar sales CRM redesign provides a relevant example of a sales workspace where task focus and information hierarchy matter more than decorative polish.
Treat outcome claims carefully. If someone cites improved conversion or reduced support requests, ask how that result was measured and what else changed. Do not require business metrics from candidates who lacked access to them. Honest limitations are more useful than unsupported numbers.
Respect confidentiality too. Sanitized artifacts and a clear explanation of the work can be sufficient when client agreements prevent sharing original files.
Interview for reasoning, not software vocabulary
Knowing Figma shortcuts is useful, but it does not prove sound judgment. Use the interview to explore decisions, trade-offs and responses to constraints.
A strong UI designer should be able to explain why an interface works without relying entirely on personal taste. Their reasoning should connect to user tasks, content, consistency and implementation needs.
“Show me a decision you changed after feedback.” Look for a specific example, what prompted the change and how the candidate assessed the alternative. Being willing to revise work matters more than defending every initial choice.
“What did you choose not to design?” This tests prioritization. Useful answers might involve reusing a familiar pattern, deferring a low-value interaction or simplifying a screen to fit the release scope.
“What would change if this screen had ten times more content?” This exposes assumptions about data density, navigation and long labels. The candidate does not need an instant finished solution, but should recognize where the current design might fail.
“Where did engineering constraints affect your work?” Listen for collaboration rather than blame. Ask how the team resolved the constraint and what the candidate documented afterward.
Avoid rewarding confidence alone. A thoughtful clarification question can be stronger evidence than a fast, polished answer based on assumptions.
Inspect interface states and accessibility
A happy-path screen is only one part of an interface. Ask the candidate to show what happens when content is absent, a request fails, an action is unavailable or a user enters invalid information.
For a SaaS product, inspect loading, empty, error and populated states. For commerce, examine validation, unavailable products and payment failures. Choose scenarios relevant to the role rather than expecting every portfolio to cover every product category.
Ask your prospective UI designer how these states preserve context and help people recover. An error message should explain the problem and, where possible, the next action. An empty state should distinguish between “nothing exists yet” and “your filters returned no results.”
Accessibility should be part of this review, not a separate question about whether the candidate “cares” about it. Check readable text, visible labels, color-independent status indicators and planned focus states.
The WCAG 2.2 quick reference provides a concrete benchmark. At Level AA, normal text generally requires a contrast ratio of at least 4.5:1, while qualifying large text requires at least 3:1.
Ask how keyboard interaction and focus order will be communicated to developers. Visual mockups alone cannot prove accessibility: semantics, behavior and assistive-technology compatibility depend on implementation and testing as well.
A credible candidate understands both their responsibility and the limits of what design files can establish.
Run a small, paid design exercise
Use an exercise to investigate gaps in the evidence, not to collect free production work. Keep the task bounded, compensate the candidate and share the evaluation criteria beforehand.
For example, provide a fictional subscription-management screen, representative content and a short brief: users need to find a subscription, understand its status and update a billing detail. Ask for one main screen, one relevant failure state and a short explanation of the choices.
Give each UI designer the same brief, time allowance and access to supporting materials. A two-hour exercise can be a useful starting point, but adjust the scope to the role and offer reasonable scheduling flexibility. Do not expect a complete design system, research study or production-ready flow within that window.
Evaluate the questions they ask before designing. Do they clarify the primary task, recognize missing requirements and distinguish assumptions from confirmed information? These behaviors matter because real projects rarely begin with perfect briefs.
Review the work together afterward. Ask what they would change with more time and what they would validate before implementation. This helps separate a rushed artifact from weak judgment.
Set a consistent policy on AI assistance. If tools are permitted, ask candidates to explain their use and demonstrate ownership of the decisions. Do not ask anyone to upload confidential client material into third-party tools.
Check whether developers can build from the work
A visually convincing prototype can still leave developers guessing. Request a walkthrough of a sanitized handoff file or ask the candidate to explain how they prepare designs for implementation.
Look for reusable components, clear naming, consistent spacing and documented behavior. Where relevant, inspect responsive layouts, long-content handling and component variants. The goal is not a particular file structure; it is whether another person can understand the intended system.
A UI designer should be able to distinguish which details are fixed, which can adapt and which need discussion with engineering. For instance, what happens when a table cell contains a long company name? Does a narrow layout preserve the main action? Which states belong to the same component?
Ask how the candidate reviews the implemented interface. Useful answers describe comparing the build with the design, identifying meaningful discrepancies and agreeing on priorities with developers.
Do not require every candidate to write code. If coding is necessary for your role, evaluate it separately rather than inferring engineering competence from a design portfolio.
Use a UI designer hiring scorecard
Record evidence immediately after each interview. A shared scorecard helps prevent the most charismatic candidate, or the most visually fashionable portfolio, from dominating the decision.
The following weights are a suggested starting point, not a validated hiring formula. Adjust them before reviewing candidates to match your product and the role’s responsibilities.
| Criterion | Evidence to inspect | Suggested weight |
|---|
| Visual hierarchy and clarity | Readability, layout, content prioritization and consistency | 25% |
| Interaction completeness | Relevant states, recovery paths and handling of realistic content | 25% |
| Accessibility judgment | Contrast, labels, focus planning and awareness of implementation requirements | 20% |
| Systems and handoff | Component reuse, responsive behavior and clear documentation | 20% |
| Collaboration and reasoning | Ownership, explanations, feedback handling and constraint awareness | 10% |
Use a simple scale: 1 means weak evidence, 3 means adequate evidence and 5 means strong evidence. Calculate each weighted contribution as the rating divided by five, multiplied by its weight. Record “not assessed” separately rather than treating missing evidence as proof of poor ability.
Compare each UI designer against the role requirements, not just against the other applicants. A high overall score should not cancel out a missing must-have, such as experience handling complex application states. Write a brief evidence note beside each rating so the decision remains explainable.
Verify ownership, references and working terms
Before making an offer, revisit any unclear portfolio contributions. Ask what the candidate personally delivered and who else was involved. Team projects are normal; presenting shared work as entirely individual work is the concern.
When references are available, ask specific questions about reliability, feedback and implementation support. “Would you work with them again?” is useful, but “What happened when requirements changed?” usually produces more actionable information.
References are supporting evidence, not a substitute for assessing the work. Junior candidates and people under confidentiality restrictions may have fewer options. A former manager or engineering collaborator can still offer relevant context.
Before hiring a UI designer, put the practical expectations in writing: scope, deliverables, review responsibilities, availability and what counts as a revision versus new work. Clarify how editable files, asset licenses and ownership rights will be handled.
Pay particular attention to unexplained gaps between attractive visuals and usable behavior. Missing states, unclear authorship and an inability to discuss trade-offs deserve follow-up. A modest-looking portfolio with clear reasoning may be a better fit than exceptional presentation backed by little evidence.
Frequently asked questions
Do I need someone with experience in my industry? Relevant product complexity usually matters more than an exact industry match. For a dense enterprise application, experience with permissions, tables and complex workflows can be more informative than familiarity with your market alone.
Can a UI designer also handle UX work? Yes, but verify the specific responsibilities. Ask for evidence of research, workflow design or usability testing if those activities are part of the job. A combined title does not establish competence across every discipline.
Should I ask for an unpaid design test? Prefer existing work and a structured portfolio review first. If you need a custom exercise, keep it small and paid. Avoid asking candidates to solve a current business problem that you intend to use without compensation.
How much should visual style influence the decision? It matters when it supports readability, consistency and the product’s needs. Do not confuse a fashionable aesthetic with the ability to handle realistic content, accessibility or implementation constraints.
Choose based on evidence you can explain
The hiring decision should come down to demonstrated judgment, relevant execution and a workable collaboration model. Keep your notes, compare candidates against the same requirements and resolve material uncertainties before signing.
If you need interface design connected to product strategy and development, Valnee Solutions provides UI/UX design, custom application development and technical audits. Discuss your product’s current gaps to determine whether you need focused design support or a broader technical partner.
Valnee