Talently
Talently
UI Designer

UI Designer

Translates the intent of the experience into coherent, accessible, and visually compelling interfaces.

A UI Designer is responsible for designing the visual and interactive layer of digital products: the typography, color, spacing, components, animations, and visual system that users perceive and interact with. Their work transforms the wireframes and flows produced by a UX Designer into pixel-perfect interfaces that communicate the brand's identity, respect usability principles, and are implementable by the development team. They collaborate closely with UX Designers, front-end developers, and branding teams to ensure visual consistency across the entire product.

FigmaDesign SystemsTypographyAccessibilityPrototypingMotion Design

Recruit the best UI Designer here

Start now

Main Responsibilities

  • •Design the product's visual components while maintaining consistency with the design system and brand principles.
  • •Create and maintain a component library in Figma with variants, states, and implementation specifications.
  • •Ensure that designs meet WCAG accessibility standards for color contrast, typography sizing, and focus states.
  • •Collaborate with front-end developers to ensure that the implementation preserves the design's visual intent.
  • •Design micro-interactions and animations that reinforce system feedback and improve perceived quality.
  • •Participate in design system evolution by documenting patterns, design decisions, and component usage guidelines.

Key Skills

Technical Skills

  • Advanced Figma proficiency: components with variants, auto layout, styles, interactive prototypes, and design tokens
  • Applied typography principles: visual hierarchy, type scale, legibility, and font pairing
  • Applied color theory for interface design: palettes, WCAG contrast, light and dark modes, and color semantics
  • Visual system design: design tokens, atomic components, and pattern documentation for development teams
  • Motion design and micro-interaction principles using Figma Prototyping or After Effects
  • Basic CSS and HTML knowledge to communicate precisely with the front-end team about implementation specifications

Soft Skills

  • Strong visual judgment to make design decisions grounded in principles, not personal preference
  • Ability to give and receive design feedback constructively, separating the work from the ego
  • Fluid collaboration with UX Designers to translate flows and wireframes into visual designs without losing the functional intent
  • Precise communication with developers about implementation specifications: spacing, states, responsive behavior
  • Consistency and discipline in keeping the design system current as the product evolves
  • Openness to technical constraints: understanding front-end implementation limitations as design input, not obstacles

Real use cases

Context

A well-built design system multiplies team velocity and ensures visual consistency across the entire product. It is the foundation on which every designer and engineer builds.

Real examples

  • Design token definition for colors, typography, spacing, and elevation as the system's single source of truth
  • Atomic component library construction with documented variants and states in Figma
  • Dark mode design using semantic tokens that automatically adapt colors without redesigning each component
  • Usage guidelines for each component: when to use it, when not to, and what alternatives exist

Context

Every new feature or product needs a visual treatment that respects the existing system while addressing new information presentation requirements.

Real examples

  • Dashboard design with clear visual hierarchy that directs attention toward the most relevant metrics
  • High-density configuration interfaces organized for easy scanning
  • Onboarding flows with visual progression that reduces the perception of complexity
  • Error pages and empty states with clear communication and contextual calls to action

Context

Modern digital products must function correctly on desktop, tablet, and mobile with visual adaptations that respect the conventions of each platform.

Real examples

  • Responsive layout design with defined breakpoints and documented per-component behavior at each size
  • Main navigation adaptation for mobile using native patterns for each platform
  • Condensed versions of complex components designed for small screens
  • Responsive implementation specifications for the development team with documented behavior

Context

Micro-interactions are the details that distinguish a product with high perceived quality from one that feels generic. System visual feedback communicates to users that their actions had an effect.

Real examples

  • Hover, focus, and active states for all interactive elements in the system
  • State transition animations that reinforce interface hierarchy and flow
  • Loading indicators and content skeletons that reduce the perception of latency
  • Critical action feedback: confirmations, errors, and success states with contextual animations

Context

The design does not end in Figma. Collaboration with the development team ensures the implementation preserves the visual intent and that specifications are clear enough to avoid multiple review cycles.

Real examples

  • Component specifications with all states, variants, and behaviors documented
  • Figma handoff with design tokens connected to code to reduce design-to-implementation divergence
  • Implementation reviews with a visual acceptance checklist before the merge
  • Working sessions with front-end developers to resolve implementation questions in real time

Basic questions

Use size, typographic weight, color, and spacing to create clear levels of importance. The most important element must stand out visually through contrast or size. Group related information with proximity and separate groups with generous spacing. Limit hierarchy levels to three or four to avoid overwhelming the user. Reduce the number of elements competing for attention simultaneously: if everything is important, nothing is.
Use the Figma Contrast plugin or tools like Colour Contrast Checker to verify that text on background meets the minimum 4.5:1 ratio for normal text and 3:1 for large text (18px or larger). Interactive UI elements must also meet 3:1 against their surroundings. Also verify dark mode if the product supports it. Include contrast verification as a mandatory step before handoff — not as a retrospective check.
Design at minimum five states: default (base state), hover (feedback when the cursor approaches), focus (keyboard navigation focus indicator — visible, high-contrast border), active/pressed (click feedback, typically darker or with a subtle displacement), and disabled (communicating non-interactivity through reduced opacity or a different color, and a not-allowed cursor). Each state must be distinguishable from the previous without being so different that they appear to be separate components.
Screen legibility: prefer fonts designed for screen over those designed for print. Minimum 16px for body text for comfortable reading. Define a type scale with clear ratios (Major Third, Perfect Fourth) for consistent hierarchy. Verify the availability of the necessary weights (regular, medium, semibold) to build hierarchy without relying on a single weight. Consider loading performance: web fonts with many weights increase load time.
Build the component with auto layout so it adapts automatically to its content. Define variants for different states (default, hover, disabled) and content variations (with icon, without icon, with badge). Use styles and design tokens instead of hardcoded values so global changes propagate automatically. Name layers descriptively and consistently with the system's naming conventions. Document in the component's description when to use it and when not to.
Don't simply invert the colors: dark mode requires a palette redesign. Define semantic tokens (color-background-primary, color-text-secondary) instead of literal tokens (gray-100). Each token maps to a different value in light and dark mode. Brand and accent colors must also be adjusted: vibrant colors that work over light backgrounds can be aggressive over dark ones. Shadows and elevation are replaced with subtle background luminosity variations. Verify contrast for all components in both modes.
Establish the design system as the single source of truth: all designers use the same components, tokens, and styles from the central library. Define a clear process for proposing changes to the system — no designer modifies central components directly without review. Conduct periodic design reviews within the team to catch inconsistencies before handoff. Assign a design system owner responsible for approving changes and keeping documentation current.
All component states (default, hover, focus, disabled, error) documented in the same frame. Spacing and dimensions with exact measurements or references to the spacing system. Responsive behavior documented with breakpoints and expected behavior at each one. Animation specifications when applicable: duration, easing, animated properties. Assets exported in the correct formats and resolutions. A list of interactions that are not obvious from the static design. The goal is for the developer to implement correctly without needing to ask.

Technical questions

Three token levels: primitive (the base values: blue-500, gray-100, 16px), semantic (the meaning: color-action-primary, color-text-secondary, space-md — each referencing a primitive), and component (specific to a component: button-background-primary). Themes and modes only change the semantic layer: the same token color-action-primary points to blue-500 in light mode and blue-300 in dark mode. Components always use semantic tokens, never primitives directly. This model allows changing an entire theme by modifying only the semantic layer without touching any component.
Define cell variants by content type: text, number (right-aligned), status with badge, date, actions. Alignment communicates type: numbers right-aligned for easy visual comparison, text left-aligned. Sortable column headers have active and inactive sort direction indicators. Rows have a subtle hover highlight to signal interactivity. Row actions are revealed on hover or always visible depending on usage frequency. Also design the empty table state and the loading state with skeleton rows.
Proximity: group semantically related fields closer together with greater separation between groups. Similarity: use the same visual style for all fields of the same type (inputs, selects, checkboxes). Continuity: align all labels and fields on a consistent grid that creates implicit visual lines. Closure: use sections with subtle borders or differentiated backgrounds so the user perceives each group as a complete unit. The result is a form whose structure the user can scan without reading each field individually.
Differentiate by urgency: informational notifications appear as toasts in the corner without requiring action, auto-dismiss after 4-5 seconds, and are not positioned over interactive content. Notifications requiring action are persistent modals or banners that do not auto-dismiss. The appearance area must be consistent so the user anticipates it. Sound only for critical notifications, with user control to disable it. Design the state for multiple simultaneous notifications to prevent an endless stack.
Use auto layout in Figma that maps directly to flexbox in CSS, easing translation. Design with the system's grid and tokens so the values already match what the code has defined. Avoid visual effects with high implementation cost and low perceptual impact (complex layered shadows, radial gradients with multiple stops). When proposing something visually ambitious, consult with the developer before finalizing the design to validate feasibility. The best design is the one that is implemented faithfully — not the most elaborate one.
Define a base grid (24x24px is the most common standard) and a consistent internal padding area so all icons have the same visual weight. Establish a unified style: outlined, filled, or duotone, with a consistent stroke width. Name icons by their semantic meaning, not their visual shape (check-circle, not circle-with-tick). Organize into semantic categories in Figma. Verify legibility at small sizes (16px) and in dark mode. Document icons with a specific semantic use (warning only for errors, not decoratively) to maintain consistent usage.
The animation must communicate the spatial relationship between screens: forward navigation uses a left-to-right transition, back navigation right-to-left. Modals and secondary panels emerge from their origin (a button, a list item) to reinforce the contextual relationship. Duration between 200-400ms for navigation transitions: faster feels abrupt, slower feels sluggish. Use easing with acceleration at the start and deceleration at the end (ease-out for entrances, ease-in for exits). Always design with reduced-motion in mind: animation is a progressive enhancement, not a functional requirement.
Personal review checklist: verify contrast on all text, check that all interactive component states are designed, verify behavior at defined breakpoints, review consistency with the design system (no hardcoded values outside the system), verify that assets are correctly exported. Zoom out to 50% to evaluate the overall visual hierarchy: the most important elements should stand out even at a distance. Ask a colleague for feedback before handoff: designers become blind to their own errors after hours of working in the same file.

Advanced questions

Federated model: a core design system team (1-2 people) maintains the foundational components and tokens. Each product team can propose extensions and domain-specific components through an RFC process. Components that appear in more than two products are promoted to the central system. The core team releases versioned updates with clear changelogs. Each product team has representation in system decisions so they feel ownership. Governance must balance global consistency with local autonomy: too much central control creates friction; too much autonomy creates fragmentation.
Velocity metrics: time from wireframe to handoff for comparable features before and after the system improvement. Number of design-to-implementation review cycles per feature. Quality metrics: number of visual inconsistencies found in implementation reviews. Team perception via internal NPS surveys: how much do designers and developers trust the system? The most valuable data is qualitative: what specific blockers the improvement resolved. Without pre-improvement metrics as a baseline, demonstrating impact with data is impossible.
Don't change everything at once: identify the components with the greatest visual debt and the highest user visibility. Introduce changes incrementally with feature flags if the infrastructure supports it. Communicate changes in advance, especially in the most-used flows. Keep functionality identical during the visual transition: changing appearance and behavior simultaneously multiplies friction. Measure user satisfaction with each introduced change before extending it to the rest of the product. Familiarity has value; changing without necessity generates resistance without benefit.
Map the framework's components against the design system's to identify where there is direct correspondence (use the framework's component with theming), where there is a gap (a custom component is needed), and where the framework has something the design system doesn't cover. The most efficient strategy is deep theming of the framework with the design system's tokens for common components, and custom components only where the framework cannot meet the requirement without costly modifications. Explicitly document what comes from the framework and what is custom so developers know where to find each component.
Progressive disclosure as the central principle: the interface shows the most common and frequent actions prominently, and reveals additional density and functionality gradually. For expert users: keyboard shortcuts, bulk actions, advanced configuration accessible outside the main flow. For new users: contextual onboarding, dismissible tooltips, and smart defaults that minimize initial decisions. Validate with both profiles separately: solutions that serve both in the same interface exist but require real iteration with users at both ends — not just one.
The fundamental principle is to never rely on color as the sole information channel: always use color plus shape, color plus text, or color plus pattern. Design with palettes evaluated for the most common types of color blindness (deuteranopia, protanopia) using tools like Figma's vision simulator. Error, warning, and success states use icons and text in addition to color. Charts use patterns or direct labels in addition to color for the legend. A design that works without colors is generally clearer and more accessible for all users — with or without visual impairments.

Common interview mistakes

Polished screens without context do not demonstrate design judgment. UI interviewers evaluate why that typography was chosen, why that spacing, why that palette. A portfolio that cannot answer those questions demonstrates execution without reasoning — which is the opposite of what a mature team is looking for.
A design that only shows the default state of buttons, inputs, and cards is an incomplete design. Hover, focus, disabled, error, and loading states are part of the design — not the developer's responsibility to invent. Technical UI interviewers always ask what happens when the user hovers or when there is an error.
UI Design is a discipline with principles. Choosing a typeface because 'it looks nice' or a color because 'it's modern' without being able to articulate the contrast ratio, the type scale, or the color semantics demonstrates that decisions are intuitive and not reproducible or maintainable by a team.
WCAG contrast, visible focus states, and not relying solely on color to communicate information are minimum requirements for any professional UI Designer. Presenting designs with light gray text on white or without a visible focus state demonstrates ignorance of the basic standards of the profession.
A UI Designer who does not understand the basics of CSS (flexbox, grid, border-radius, transitions) produces designs that the development team implements with compromises that degrade visual quality. Basic technical knowledge is not optional — it is what distinguishes a UI Designer who can collaborate effectively with development from one who generates constant friction.
Although the roles collaborate closely, the UI Designer is not responsible for user research or information architecture. A candidate who cannot clearly articulate their specific responsibility and how they work alongside the UX Designer raises doubts about their understanding of the design process and their ability to collaborate effectively in a team with differentiated roles.