The challenge of hiring a UI UX designer: a beautiful portfolio, an invisible process
Almost every designer's portfolio looks appealing at first glance. Clean mockups, harmonious colors, and polished presentation. The problem is that the final visuals are only a small part of UX work. Research, decision-making, compromises with developers, and fixes after release rarely show up in images. HR that judges by visual impression often picks designers who are good at presentations, not at solving user problems.
More confusion comes from the terminology. A UI designer focuses on appearance and components, a UX designer on flows and research, and a product designer covers both plus product strategy. A single posting that asks for everything attracts applicants who are hard to compare. So decide first which part of the work you need most, then judge portfolios by the process explained in them.
Challenges
Portfolios show results, not process
Many portfolios contain only final screenshots. Without an explanation of the problem, the research, and the reasons behind the design, HR cannot tell candidates who think systematically from those who are merely good at polishing visuals.
UI, UX, and product designer roles get mixed
A posting that combines research, visual design, and product strategy makes applicants hard to compare. HR ends up measuring people with different strengths against one yardstick, which is unfair.
User research is hard to judge from a CV
CVs usually just write user research without detailing the method. HR struggles to know whether the candidate has interviewed real users or only built personas from assumptions, and the difference greatly affects design quality.
Collaboration with developers shows up late
A beautiful design that is hard to build causes conflict in the team. Collaboration with developers rarely appears in a portfolio, so it is only discovered after the candidate is hired and the project is under way.
From a pile of CVs to a shortlist
Illustrated flow: CVs come in, are screened against your criteria, and only the most relevant candidates move on to the next stage.
The old way
- Open portfolio links one by one and judge by the visual impression at first sight.
- Ask the design team or product owner for opinions without a uniform scoring rubric.
- Contact candidates for a first interview before knowing whether they have a suitable case study.
With TalentRank
- Set up Custom Hiring Criteria that distinguish UI, UX, or product design needs, with a weight for each criterion.
- Upload all CVs to CV Screening AI to get a ranking and a candidate summary against that rubric.
- Use WhatsApp Prescreening to ask for a portfolio link, the most representative case study, and the candidate's availability.
- Run AI Interview with questions about design process, then review the scores and summaries before the interview with the team.
CV screening criteria for UI UX designer hiring
Use this rubric to judge CVs and portfolios by the same standard. Choose weights to fit your need: a UX position emphasizes research and flows, a UI position emphasizes components and visual detail. The process section of a case study matters more than the final look.
| Criterion | Priority | Good signs in the CV | Worth asking about |
|---|---|---|---|
| Case studies that explain the process | High | Each case study covers the starting problem, the candidate's role, research steps, design alternatives, the final decision, and the result. There is also a part on what did not work and what was changed. | Only final images with no narrative, or a smooth story with no obstacles at all. Ask about one hard decision and what the candidate gave up. |
| User research experience | High | Names the methods used, such as user interviews, usability testing, or data analysis, along with the number of sessions and the findings that changed the design, not just the words user research. | Personas and user journeys are made without naming a data source. Ask when the candidate last spoke directly with users and what they learned. |
| Reasoning behind design decisions | High | The candidate can explain why they chose one pattern over another, tie it to user behavior or business goals, and stay open to data that contradicts their assumptions. | Reasons are purely aesthetic, like looking more modern or cleaner. A design decision that cannot be explained is hard to defend in front of stakeholders. |
| Collaboration with developers | High | Mentions clean design handoff, discussing technical feasibility before finalizing, and adjusting designs after developer feedback, with tools like Figma and component documentation. | No stories about implementation, or the candidate blames developers for results that differ from the design. Dig into how they resolved the differences. |
| Design system experience | Medium | Has built or maintained components, color and typography tokens, and usage rules used by several designers or teams, not just used a ready-made library. | Claims design system experience but only used community templates. Ask how they keep consistency when components need to change. |
| Visual detail and interface quality | Medium | Consistent layout, clear information hierarchy, and attention to states like empty, error, and loading, not just the ideal look of one main screen. | Screens look good but have low contrast, very small text, or no state other than the best case. This suggests the design was not thought through for real use. |
Case studies that explain the process
HighGood signs in the CV: Each case study covers the starting problem, the candidate's role, research steps, design alternatives, the final decision, and the result. There is also a part on what did not work and what was changed.
Worth asking about: Only final images with no narrative, or a smooth story with no obstacles at all. Ask about one hard decision and what the candidate gave up.
User research experience
HighGood signs in the CV: Names the methods used, such as user interviews, usability testing, or data analysis, along with the number of sessions and the findings that changed the design, not just the words user research.
Worth asking about: Personas and user journeys are made without naming a data source. Ask when the candidate last spoke directly with users and what they learned.
Reasoning behind design decisions
HighGood signs in the CV: The candidate can explain why they chose one pattern over another, tie it to user behavior or business goals, and stay open to data that contradicts their assumptions.
Worth asking about: Reasons are purely aesthetic, like looking more modern or cleaner. A design decision that cannot be explained is hard to defend in front of stakeholders.
Collaboration with developers
HighGood signs in the CV: Mentions clean design handoff, discussing technical feasibility before finalizing, and adjusting designs after developer feedback, with tools like Figma and component documentation.
Worth asking about: No stories about implementation, or the candidate blames developers for results that differ from the design. Dig into how they resolved the differences.
Design system experience
MediumGood signs in the CV: Has built or maintained components, color and typography tokens, and usage rules used by several designers or teams, not just used a ready-made library.
Worth asking about: Claims design system experience but only used community templates. Ask how they keep consistency when components need to change.
Visual detail and interface quality
MediumGood signs in the CV: Consistent layout, clear information hierarchy, and attention to states like empty, error, and loading, not just the ideal look of one main screen.
Worth asking about: Screens look good but have low contrast, very small text, or no state other than the best case. This suggests the design was not thought through for real use.
UI UX designer interview questions that dig into process
Effective UI UX designer interview questions ask candidates to walk through one project honestly, including the parts that failed. These three groups help assess how they think, how they handle criticism, and how they work with a team.
Portfolio case study
1.Pick one case study in your portfolio. What was the original problem and which parts did you actually do yourself?
A good answer: A good answer explains the problem context and personal role specifically, and separates team results from the candidate's own contribution.
2.Which design did you end up changing completely after meeting users, and what changed your mind?
A good answer: A mature candidate has a story about a wrong assumption and the data that convinced them, rather than treating the first design as already correct.
3.How did you know your design worked after it launched?
A good answer: A strong answer names how it was measured, such as task completion rate, user feedback, or behavior change, and does not stop at 'the design was approved'.
Research and decision-making
4.If you only had one week for research and no budget, what would you do?
A good answer: A practical candidate names lightweight methods such as short interviews with a few users or reviewing customer service complaints, rather than postponing research.
5.A stakeholder asks you to move a button because of personal taste. How do you respond?
A good answer: A good answer still respects the input, then steers the discussion to data or user goals, without being defensive or simply giving in.
6.How do you decide which features to design first when there is not enough time for all of them?
A good answer: A good candidate weighs impact on users and the business, plus technical difficulty, then communicates the reasons for the priorities to the team.
Collaboration and design system
7.A developer says your design is hard to build on schedule. What do you do?
A good answer: A healthy answer looks for a joint solution, such as simplifying the design without breaking the user's goal, rather than defending the design as is.
8.How do you structure components so they stay consistent when several designers work on one product?
A good answer: An experienced candidate mentions reused components, uniform naming, documentation, and a review process for changes, not just a tidy Figma file.
9.Tell me about a time the implementation differed from your design. What did you do and what did you learn?
A good answer: A good answer shows how they check the result, talk to developers constructively, and improve the handoff process on the next project.
Common mistakes
- 01
Judging a portfolio by the final visuals alone
Anyone can make beautiful mockups from a template. Give weight to the problem narrative, the research, the alternatives that were dropped, and the outcome, then ask the candidate to walk through one project in detail.
- 02
Mixing UI, UX, and research needs in one posting
One posting that asks for everything attracts uneven applicants. Decide the main focus of the position, for example flows and research or components and visuals, and list the rest as nice to have.
- 03
Assigning a free design task that is too big
A design task that takes days drives good designers away and risks looking like a request for free work. Limit it to about two hours, or replace it with a session discussing an existing case study.
- 04
Not inviting a developer to the interview
Collaboration with developers decides whether a design actually reaches users. Have one developer join the final session for thirty minutes to discuss handoff and technical feasibility.
- 05
Ignoring how the candidate takes criticism
Designers constantly receive feedback from stakeholders, developers, and users. Give light criticism of one of their designs during the interview, then watch whether they ask questions, consider it, or defend right away.
Scenario
Company
A small software house building mobile apps for several clients that does not yet have a permanent designer.
Situation
The company opens one UI UX designer position and receives applications with varied portfolio links. HR has no design background and wants to screen by process, not by looks.
Expected outcome
HR calls the candidates whose design process is clearly visible, and the team compares them against the same rubric.
- 1HR and the team lead set up Custom Hiring Criteria with high weight on process-driven case studies, user research, and collaboration with developers.
- 2CV Screening AI scores all CVs against that rubric and gives a ranking and a summary of each candidate.
- 3Top candidates are contacted through WhatsApp Prescreening to request their chosen case study and confirm availability.
- 4Candidates go through an AI Interview about design process, then HR reviews the scores and summaries before inviting a developer to the final interview.
What you get
- A candidate ranking based on a UI, UX, or product design rubric
- CV and portfolio summaries: role, research methods, and type of product
- AI Interview answers, scores, and summaries about design process
- Portfolio links and candidate availability from WhatsApp
