- UX is now a core Piece: research, design and validation in one seat.
- The single-designer trap (one designer, thirty open Figma files) is where teams break.
- Research is the bottleneck nobody books; design systems are infrastructure, not decoration.
Walk into most growing product teams and ask to meet the design team. You will be introduced to one person. They will have a laptop open with, at last count, somewhere north of thirty live Figma files, four of which they're actively touching today. They are doing the work of three people, none of which they were hired to do exclusively. This is the seat the UX Piece is built for, and it is the seat most teams underestimate worst.
A new core piece.
UX joined the Product Pieces in-house bench in May 2026. Before that it was a partner piece. We'd run discovery, hand the design work to a specialist studio, and pick the project back up at the build phase. The model worked, but only just. Too many engagements landed exactly on the UX boundary and started ricocheting between us and the partner: a research question that needed product judgment, a design call that needed strategy context, a validation pass that needed someone who already knew the roadmap. The work was too strategic to hand off, and too craft-heavy for a PM to do well on the side.
So we changed the model. UX now sits on the Core bench alongside the CPO, PM, PO, Quality and Coaching Pieces. Same vetting bar, same engagement shapes, same accountability. But now it's all under one roof, which means the seam between strategy, design and validation closes properly.
What UX actually owns.
The single biggest misconception about UX is that it's a job title. It isn't. It's three jobs held by one title, and the difference between a real UX function and a "designer" is whether all three are being done at all.
Research. Generative and evaluative. Generative is the work that tells you what to build: interviews, ethnographic observation, jobs-to-be-done framing. Evaluative is the work that tells you whether what you've built works: usability testing, task-completion analysis, comprehension checks. Both, ideally, in continuous rhythm. Nielsen Norman Group has been making this argument since the 1990s and it's still the cleanest framing in the field.
Design. Information architecture, interaction flows, component systems, accessibility. The visible craft most people think UX is, but only one third of the actual remit. This is where IA, flows, components and patterns get made. It's also where the design system either gets built deliberately or accreted accidentally.
Validation. Usability testing, journey mapping, analytics interpretation. The bit that closes the loop after ship. Most teams shove this into "PM tasks" and it dies on the vine; in practice it needs the same hands and eyes that designed the thing in the first place.
Don Norman, who coined "user experience" in the early 1990s, defined UX as encompassing "all aspects of the end user's interaction with the company, its services, and its products". That definition has held up. UX isn't the screen. It's the whole experience of using the thing. The screen is one output of the function.
The single-designer trap.
Here is the pattern almost every Series A team falls into. They hire a designer because the product is "looking dated" or "feeling clunky". The designer is good — sharp, opinionated, fast in Figma. The first three months feel great. Screens get prettier, the team has someone to point design questions at, the founders feel like they've solved the design problem.
Then the work starts to drift. Engineering needs screens now, so the designer ships screens. The PM needs a new feature flow by Friday, so the designer ships a flow. Marketing wants a landing-page refresh, so the designer ships that too. Twelve months in, the designer is a screen factory. There has been no generative research in over a year, no usability testing on anything that shipped, and the design system is "a Figma library we keep meaning to clean up".
The product looks fine. It also fails to convert, has support tickets the team can't explain, and an NPS that nobody quite trusts. The designer is exhausted, the PM is frustrated, and everyone agrees "we need to do more research". But the calendar has no space for it because the screen factory is fully booked.
This is not a designer problem. It's a function problem. You haven't hired a UX function, you've hired a UI producer and asked them to also do research and systems work in their spare time. Nobody has spare time.
Research is the bottleneck nobody books.
Generative research, the work that tells you what to build, is the most leveraged spend in the function and the first thing teams skip. The argument is always the same: "we already know what users want, we just need to ship it." Sometimes that's true. Most of the time it means you've stopped checking.
Evaluative research (does the thing you shipped actually work?) is the second thing teams skip. The substitute is product analytics. "We can see what users are doing in the data." You can see what they're doing. You cannot see why. The why is what tells you whether the next iteration is a tweak or a teardown. Analytics is a measuring tape, not a microscope.
A real UX function books research in continuous rhythm: weekly evaluative sessions on whatever just shipped, a generative round each quarter on whatever's next. Not a "discovery sprint" you do once a year because someone read a book about it.
Design systems are infrastructure, not decoration.
A team of three designers without a design system is three competing design systems. A single designer without a design system is one person re-deciding the same component twenty times across thirty files, which is why those thirty Figma files exist in the first place.
A design system is tokens (colour, type, spacing, motion), components (with states and variants documented), patterns (recurring flows like onboarding, empty states, error handling) and guidelines (when to use what, and why). Look at Atlassian's design system for the gold standard. It's published, versioned, governed and treated like the infrastructure it is.
Most teams treat the design system as a side project the designer will "get to next quarter". They never get to next quarter. The UX Piece treats it as part of the brief from day one, because the productivity gain of a working system is measured in months saved across every subsequent feature.
When you need a UX Piece.
Three signals. Any one is enough, two is urgent, three means you've been operating without a UX function for a while:
- Single overstretched designer. One person doing the work of three. Their calendar is fully booked and there's still a backlog. Quality is dropping because everything is now or never.
- Inconsistent UI across products. The web app and the mobile app look like different companies built them. New features don't match old features. Buttons behave differently in three places. The system has stopped being a system.
- Shipping fast with no research input. Roadmap is full, velocity is high, the team is proud of throughput. Nobody can tell you the last time a user was interviewed before a feature was scoped.
Who not to hire one for: pre-seed teams with a single product and fewer than five engineers. At that scale you need one polymath designer who can do enough of each job to keep you moving, not a structured UX function. The UX Piece earns its keep when there's enough product surface area that no single designer can hold it all in their head.
UX vs UI vs CX: where the line falls.
Useful boundary distinctions, because these terms get used interchangeably and they shouldn't be.
UI is the surface: buttons, layouts, type, motion. The visible craft. See N°09 UI. UX is the whole interaction: how the product feels to use end-to-end, why it's structured the way it is, what the user is trying to do at each step. See N°08 UX. CX is the full lifecycle: marketing, sales, onboarding, support, renewal, advocacy. See N°10 CX.
The UX Piece operates across all three but lives in the UX layer. It influences UI (because UX owns the system that UI inherits from) and it inputs into CX (because journey mapping spans the lifecycle), but its primary accountability is the interaction layer between user and product.
How we use the UX Piece at Product Pieces.
Two engagement shapes, both built around a three-week scoping pattern that runs at the start regardless of the longer-term shape.
Week one: audit. The UX Piece goes deep on the current state. Heuristic review of the product, audit of existing Figma files, interview the designer (if there is one) and the PMs, sample five recent user sessions, read the support tickets. Output: a written assessment of what's working, what's broken, and where the highest-leverage moves are.
Week two: quick wins. The two or three highest-impact changes that can ship inside a fortnight. Usually these are interaction or IA fixes that have been on the designer's "I'll get to it" list for months. The goal isn't the wins themselves. It's to demonstrate that the function moves.
Week three: system. Either start the design system from scratch or audit and consolidate the existing one. This is the work that compounds. Six months later, every feature ships faster because the system carries the load.
From there, two ongoing shapes. Fractional UX Lead, embedded two to three days a week, holding the function alongside an in-house designer (or in lieu of one). Set Piece UX Audit: the three-week scoping pattern as a fixed-scope engagement, ending with a written handover so an in-house team can run the recommendations themselves.
If the Diagnostic surfaces single-designer overload, inconsistent surface, or a missing research rhythm, the UX Piece is usually the answer. Sometimes it's the Coaching Piece pointed at the existing designer instead. Depends on the seniority gap. The Diagnostic tells us which. Back to the index →