Roughly half of design teams at mid-sized product companies split UI and UX into distinct roles, according to periodic industry surveys from groups like the Nielsen Norman Group and UX hiring platforms — the other half run generalist "product designer" roles that cover both. Neither structure is objectively better; each creates a different kind of handoff, and understanding how that handoff actually works day to day explains a lot about why some product teams ship coherent experiences and others ship a pile of disconnected, individually-polished screens.
In a split-role team, the handoff point is usually the wireframe. UX finishes low-fidelity flows — boxes and labels with no color or typography, just structure and sequence — and hands them to UI, who translates that structure into a fully designed, on-brand interface. The handoff is rarely a single clean moment; it's more often an overlapping conversation where UI raises questions ("this flow has three primary actions on one screen — can we prioritize one?") that sends UX back to revisit the structure before visual work continues.
Monday: UX reviews the previous week's usability test recordings and drafts an updated flow for the onboarding sequence based on where testers got confused. Tuesday: UX and UI sit down together to walk through the new flow — UI flags that one step introduces a decision point with five options, which contradicts Hick's Law (the more choices presented, the longer decision time takes) and asks for it to be simplified to three. Wednesday: UX revises the flow; UI begins exploring visual direction for the simplified version. Thursday: UI shares a first pass; UX checks it against the original research notes to confirm nothing from the user interviews got lost in translation. Friday: both review together, sign off, and hand to engineering with an updated flow diagram and finished mockups.
Most of these friction points are manageable with process; what's harder to fix is a genuine mismatch in seniority — a very senior UX researcher paired with a junior UI designer, or vice versa, tends to produce a lopsided handoff where one side's decisions go largely unchallenged, simply because the less experienced person doesn't yet have the confidence or vocabulary to push back on a senior colleague's call.
Plenty of small teams operate with a UI designer (or a generalist doing mostly visual work) and no one explicitly responsible for UX. This isn't automatically catastrophic — a sharp product manager or founder can absorb a meaningful share of the research and flow-validation work informally, through customer calls and support ticket review, without holding the title. What tends to go wrong is more subtle: without someone whose explicit job is to advocate for the user's mental model over the business's internal logic, flows quietly start to mirror how the company is organized internally (a signup form that separately asks about "billing contact" and "technical contact" because that's how the sales team thinks about accounts) rather than how a new user actually thinks about signing up. Nobody makes a single bad decision; the flow just slowly accretes internal logic that makes sense to the team and less sense to a stranger encountering it for the first time.
The cheapest partial fix, short of a dedicated hire, is a standing habit: before any new flow ships, have someone who wasn't involved in building it try to complete the task with no explanation. It's not a substitute for real UX practice, but it catches a meaningful share of the internal-logic problem before it reaches real users.
The week-in-the-life example above assumes a co-located or synchronous team. Distributed teams across time zones handle the same UX-to-UI handoff differently, usually by front-loading more documentation into the handoff itself, since there's less opportunity for a quick hallway clarification. UX work tends to ship with a written rationale attached to each major decision — not just the wireframe, but a short paragraph on why a given flow was chosen over alternatives — specifically so a UI designer working eight hours out of sync can pick it up without waiting a full day for a reply to a question. Recorded walkthroughs have become a common substitute for the live sit-down: UX records a short narrated tour of a new flow, and UI reviews it asynchronously before starting visual work, trading some of the back-and-forth speed of a live conversation for a handoff that doesn't stall on time zone gaps.
Most teams now do both phases inside Figma, which reduces (but doesn't eliminate) handoff loss — UX can build wireframes in low-fidelity components that UI then restyles in place rather than rebuilding from scratch. FigJam or Miro typically hosts the earlier flow-mapping and research-synthesis work, before anything moves into Figma proper. Tools like Zeroheight or Storybook document the design system so UI decisions (spacing, states, color usage) stay consistent even as different people touch different screens over time.
Ideally yes, even briefly. The most common source of friction on split teams isn't disagreement — it's each side working from an outdated or incomplete picture of what the other decided. A short joint review catches misalignment before it's built.
There's no universal answer, but the more useful question is usually "what does the data say?" rather than "whose call is it?" — a quick usability test on the disputed point often resolves the disagreement faster than a debate about seniority or ownership.
Very common. Many senior product designers started specialized in one side and broadened over time, since understanding both makes each individually stronger — a UI designer who understands research context makes better visual-hierarchy calls, and a UX designer with visual literacy communicates flows more persuasively to stakeholders.