Talently
Talently
UX Designer

UX Designer

Designs digital experiences that solve real user problems with rigor, evidence, and clarity.

A UX Designer is responsible for understanding user needs, behaviors, and motivations in order to design digital experiences that are useful, usable, and meaningful. Their work spans user research and journey mapping through wireframing, prototyping, and validation with real users. They collaborate closely with Product Managers, UI Designers, and development teams to ensure that design decisions are grounded in evidence and are technically feasible to implement. Their impact is measured by the real user experience — not the aesthetics of the screens.

FigmaDesign ThinkingUser ResearchPrototypingUsabilityAccessibility

Recruit the best UX Designer here

Start now

Main Responsibilities

  • Plan and conduct user research (interviews, usability tests, surveys) to ground design decisions in evidence.
  • Define and communicate the design problem before proposing solutions, ensuring the team is solving the right problem.
  • Create user flows, wireframes, and prototypes at varying fidelity levels appropriate to the project phase.
  • Validate design hypotheses with real users through usability tests and behavioral analysis.
  • Collaborate with UI Designers and developers to ensure the implementation preserves the intended design experience.
  • Maintain and evolve the design system and user experience guidelines for the product.

Key Skills

Technical Skills

  • Figma proficiency for wireframing, interactive prototyping, and collaboration with product and development teams
  • Qualitative research methods: in-depth interviews, moderated and unmoderated usability tests, card sorting
  • Quantitative research methods: surveys, behavioral metrics analysis, A/B testing in collaboration with data teams
  • User flow design, information architecture, and customer journey mapping
  • WCAG accessibility principles and inclusive design techniques applied from the wireframing phase
  • Behavioral analytics tools: Hotjar, FullStory, Mixpanel, or equivalent to complement qualitative research

Soft Skills

  • Genuine empathy with users to distinguish between what they say they want and what they actually need
  • Ability to defend design decisions with user evidence against unfounded stakeholder opinions
  • Clear visual communication to present research findings and design ideas to non-designer audiences
  • Openness to critique and the ability to separate ego from the work in order to iterate based on feedback and evidence
  • Systems thinking to design coherent solutions across multiple flows and product touchpoints
  • Judgment to know when formal research is necessary and when a quick validation is sufficient to move forward

Real use cases

Context

The greatest waste in product design is building the right solution for the wrong problem. Early user research reduces that risk.

Real examples

  • Discovery interviews to understand the jobs-to-be-done of target users
  • Competitive analysis and benchmarking of reference experiences in the space
  • Empathy maps and personas grounded in real research, not team assumptions
  • Problem framing with How Might We statements derived from research findings

Context

High-stakes flows — onboarding, checkout, feature activation — directly drive the product's key metrics. A poorly validated design in these flows has a direct impact on conversion and retention.

Real examples

  • Iterative onboarding flow design with validation at each stage
  • Moderated usability tests on the payment flow with representative users
  • Funnel drop-off analysis with analytics tools to identify friction points
  • Redesign of error recovery flows that frustrate users

Context

Products with many features or extensive content require an information structure that allows users to find what they are looking for without excessive cognitive effort.

Real examples

  • Card sorting to validate users' mental models about content organization
  • Tree testing to evaluate whether the proposed navigation structure is comprehensible
  • Navigation system design for products with multiple user roles
  • Information architecture redesign for products with findability problems identified in research

Context

Accessible design is not a checklist at the end of the process — it is a mindset that expands the product's reach and improves the experience for all users.

Real examples

  • Wireframe reviews with an accessibility lens before they reach visual design
  • Design of text alternatives and keyboard navigation flows for complex components
  • Usability tests with users with visual, motor, or cognitive disabilities
  • Accessibility criteria defined as part of the acceptance criteria for every feature

Context

A UX-grounded design system ensures that interaction patterns are consistent and that usability decisions scale across the entire product.

Real examples

  • Definition of reusable interaction patterns with documentation on when and how to use them
  • Experience consistency audits to identify contradictory patterns across the product
  • Collaboration with UI and engineering on component definitions that balance flexibility and consistency
  • UX writing guidelines integrated into the design system for error messages, empty states, and confirmation flows

Basic questions

Generative research at the start: interviews and observation to understand the problem and the users before designing. Evaluative research during design phases: usability tests to validate whether the solution works. Qualitative methods for the 'why' (interviews, usability tests); quantitative for the 'how much' (surveys, analytics). The choice also depends on available time and budget: a two-hour guerrilla usability session can be more valuable than weeks of data analysis.
Present with direct quotes and video clips of real users rather than abstract summaries: watching a frustrated user has more impact than a percentage on a slide. Connect each finding to an affected business metric. Involve the team in the research when possible — observing interviews makes findings feel shared rather than handed down from UX. Pair each finding with an actionable hypothesis, not just a problem without a proposed direction.
Cross the frequency of the problem against its impact on the user and on business metrics. A problem affecting 80% of users in the checkout flow takes priority over one affecting 5% in a secondary feature. Involve the product manager in prioritization to align user impact with product goals. Avoid prioritizing problems because they are the most visually obvious or the team's personal favorites.
Don't counter opinions with opinions. Respond with evidence: user interview quotes, usability test results, industry benchmarks, or established usability principles. If there is insufficient evidence, propose a quick test to resolve the question before implementing. The most effective argument is not 'I'm right' — it's 'here is the evidence supporting this decision; we can test the alternative if there's doubt'.
Low fidelity (wireframes, paper sketches) to explore and communicate flows and structures quickly when the concept is still under discussion. Low visual detail focuses feedback on structure and flow, not on color or typography. High fidelity when you need to validate with users how they interact with the product, when presenting to stakeholders for approval, or when it serves as the specification for the development team.
Define success metrics before the redesign is implemented, not after. Combine quantitative metrics (flow completion rate, time on task, error rate) with qualitative ones (satisfaction score, comments in post-launch tests). Compare against the baseline of the previous flow. An A/B test at launch allows the metric change to be attributed to the redesign with greater confidence than comparing different time periods with other variables changing simultaneously.
First make the tension explicit so the team acknowledges it — don't ignore it or resolve it unilaterally. Explore whether there is a design that satisfies both objectives with some acceptable compromise. If the tension is real, present the options with the consequences of each: a dark pattern may increase a conversion metric in the short term but damage trust and retention over time. The final decision belongs to the product manager with that information — not to the UX designer.
Questions about current context and behaviors — not about the product you are about to build: What do you do today when you have this problem? What tools do you use? What are the most frustrating parts of that process? What have you tried that didn't work? Avoid hypothetical questions ('Would you use an app that did X?') because the answers do not predict real behavior. The goal is to deeply understand the problem — not to validate the solution already in mind.

Technical questions

Define the specific tasks the user must complete, aligned with the critical steps of the flow. Recruit participants who represent the actual target user. Moderate without guiding: provide the minimum necessary context and observe without intervening until the participant is completely stuck. Measure: task completion rate, time per task, number of errors, and post-test satisfaction score. Five participants detect approximately 85% of usability problems according to Nielsen. Present findings with session video clips to maximize impact on the team.
Proximity: group related elements spatially so users perceive them as units. Similarity: use the same visual style for elements with the same function. Figure-ground: ensure sufficient contrast so the primary content is distinguished from the background without effort. Continuity: align elements along lines or curves to guide attention. Closure: users complete incomplete shapes — useful for progress indicators or simplified icons. Applying these principles systematically reduces cognitive load without adding explanatory text.
Map the flows and information needs of each role separately before designing the navigation. Identify which features are shared and which are role-exclusive. Evaluate whether the solution is adaptive navigation (same structure with role-filtered content) or separate role-based experiences. Validate with card sorting and tree testing per user segment, not with a single general test. The correct information architecture for an administrator may be entirely wrong for an end user.
Clear Figma specifications with behavioral annotations, not just visual appearance: what happens on hover, on focus, on error, with empty data, with very long text. Deliver complete flows including edge states (empty state, error state, loading state) that are frequently omitted. Participate in implementation review before the merge with a UX acceptance checklist. Report discrepancies as UX bugs with the same weight as functional bugs.
Quantitative data (funnels, heatmaps, session recordings, click events) shows where problems occur and how frequently. Qualitative data (interviews, usability tests) explains why they occur. The most effective workflow: analytics identifies a high drop-off rate at a specific funnel step; qualitative research explains whether it is due to design confusion, a data loading problem, or an unmet expectation. Both methods are needed for actionable diagnoses.
Validate inline in real time (not only on submit) so the user corrects as they type, not after losing all their progress. Show the error next to the field containing it — never only at the top of the form. The error message must explain what went wrong and how to fix it, never just 'invalid field'. Preserve all valid values when there are errors; never clear the entire form. For long forms, show an error summary at the top with links to each problematic field.
Walk through the main flows as a new user without help from the team, noting friction and confusion. Review consistency: are the same interaction patterns used for the same actions throughout the product? Is the language consistent? Verify edge states: empty states, error states, loading states. Compare the design against Nielsen's heuristic principles. Review any prior research results and metrics if they exist. This audit should produce a prioritized UX debt map — not a list of aesthetic preferences.
Don't adapt desktop to mobile as an afterthought: design mobile first, accounting for screen constraints, on-the-go usage context, and touch interaction. On desktop, take advantage of the additional space for information density and secondary actions that would be noise on mobile. Flows can differ between platforms if the usage contexts justify it: a user who completes a long task on desktop may make a quick lookup on mobile for the same product. Validate both experiences with real users on each platform.

Advanced questions

Separate discovery research (quarterly, deeper) from continuous evaluative research (weekly, lighter). Maintain a panel of available users for quick unmoderated tests (Maze, UserTesting) that can be run in days. Integrate micro-research into the design workflow: five 30-minute usability tests every two weeks is more sustainable than a massive study every six months. Share findings in a centralized repository (Dovetail, Notion) so the whole team accumulates user knowledge without duplicating research.
Connect each UX initiative to a business metric: reduction in onboarding time, increase in activation rate, reduction in support tickets caused by interface confusion. Document the before-and-after state of each redesign with data. To justify preventive research: calculate the cost of a UX bug in production (development time to fix it multiplied by the number of affected users) versus the cost of a usability test that catches it before implementation. Early research is systematically cheaper than late redesign.
Design layers of progressive disclosure: the interface shows the most common actions by default and reveals additional complexity as the user needs or seeks it. Separate onboarding flows from the regular expert user flow to avoid patronizing those who already know the product. Provide keyboard shortcuts, advanced commands, and customization for expert users that coexist with the guided interface for newcomers. Validate with users from both profiles separately: what is obvious to an expert is opaque to a new user.
Don't redesign everything at once: identify the areas with the greatest UX debt and highest impact on metrics. Involve current users in the design process — not as passive validators, but as co-designers who contribute their knowledge of the product. Communicate changes in advance and offer transition periods where both versions coexist. Measure adoption and satisfaction metrics at each phase to enable adjustments. Users resist change not out of irrationality but because they have invested time learning the current system — that investment must be respected in the transition design.
Don't confront the intuition head-on: in the early stages of a product, the founder's intuition often carries more business context than a newly arrived UX designer. Build credibility incrementally: run small research initiatives that surface surprising insights the team didn't have. Make the user's voice visible in meetings through direct quotes and video clips. Propose including the founder in a research session as an observer — watching users struggle firsthand is more persuasive than any presentation. A user-centered design culture is built with concrete wins, not with frameworks.
Audit the product systematically using Nielsen's heuristics and usability tests with real users to get an objective picture of the current state. Classify the debt as: critical (blocks important tasks), significant (causes frequent friction), cosmetic (inconsistencies that don't affect usability). Build a prioritized UX debt backlog with estimated impact and resolution cost. Negotiate with the product manager that a percentage of each sprint's capacity is dedicated to reducing UX debt — the same way technical debt is handled. Without that explicit agreement, UX debt will always lose to new features.

Common interview mistakes

UX interviewers evaluate how a candidate thinks, not how they draw. A portfolio that shows polished screens without explaining what problem they solved, what research grounded them, what alternatives were considered, and how they were validated signals that the candidate is a pixel pusher, not a UX designer.
Every design decision must be justifiable with user evidence, usability principles, or behavioral data. Aesthetic opinions are not design rationale. Technically strong UX interviewers always ask 'why' until they reach the real foundation of each decision.
Happy paths are the easy part of design. Edge states — what happens when there is no data, when an action fails, when the text is too long — are where most real usability problems hide. A candidate who presents only the ideal flow has not thought about the product as a complete system.
The CEO's opinion about the design is not user research, even if the CEO also uses the product. Stakeholders have biases, product knowledge, and objectives that real users do not share. Mixing both feedback sources produces design decisions that satisfy the internal team but not the users.
A full redesign is expensive, risky, and rarely necessary. Proposing a sweeping redesign in response to specific problems demonstrates poor judgment in calibrating the solution to the size of the problem. Surgical fixes at the highest-friction points frequently deliver more impact at lower risk and cost.
A design without defined success metrics is a design that will never know if it worked. Interviewers at data-oriented companies always ask what happened to the product after the redesign. Not being able to answer with concrete data — even qualitative — raises doubts about whether the candidate works with an impact mindset or a delivery mindset.