Design feeds spent two years announcing funerals. UX is dead. Figma is dead. The titles kept arguing while the actual job posts quietly stopped making sense. So I closed the feed and read a week of real ones instead, 633 design briefs on the biggest freelance marketplace, to see what the market believes when nobody is performing for an audience.
It believes a Product Designer is worth about five dollars an hour more than a UI/UX Designer at the median, then asks both of them for the same work. The same share named Figma. The same share mentioned conversion. And six in ten of the product designer posts were for physical objects, watches and kitchenware, not software at all. The words on the post are noise with a price tag attached.
Written from Zaporizhzhia, Ukraine. Lo-fi in the headphones, an air-raid app on the phone, the work ships on time.
Here is what does not move when the discourse does. Responsibility. A UI/UX Designer is responsible for the interface: navigation, visual hierarchy, the design system, accessibility. A Product Designer is responsible for the business result through that interface: onboarding, activation, retention, monetization, referral. The points where a user's goal meets the company's goal, and the metrics that move when you get them right.
Tools change. That line does not. I am a UI/UX Designer, and I picked this lane on purpose. The rest of this article is for hiring managers deciding which kind of responsibility their project actually needs.
I counted, instead of arguing
I did not want another opinion about titles. So I took a week of design briefs from the open market, the place most of these roles are actually hired, and counted what the words buy.
The title Product Designer costs more. What it asks for is the same. The share of posts that want Figma barely shifts between titles, and the higher-paid title is not the one that mentions a business outcome more often. You are paying for a word.
So I stopped treating the title as the answer. It moves the salary band and the search results, not the work. What someone is actually on the hook for shows up somewhere else.
Tools are a tell, not a test
The tools a designer reaches for hint at the answer, so they are worth reading. A UI/UX Designer tends to live in Figma: design systems, components, Dev Mode handoff. A Product Designer tends to spend more of the week in research (Maze, Dovetail, UserTesting) and in fast build tools like Lovable, v0, or Bolt, putting something clickable in front of users early.
But the tool does not define the role. A UI/UX Designer who opens Lovable to test a screen has not become a Product Designer. Lovable and tools like it are for fast hypothesis testing: a clickable answer for right now, a way to check an idea this week, often a thing that never survives to real development. Reaching for it is a tell about how someone works. It is not the thing that makes them responsible for the metric.
So read the tools as a signal, then check the signal against the real question. What is this person on the hook for. A Product Designer whose portfolio is all Figma frames and no outcomes is usually a UI/UX Designer with a different title.
What a UI/UX Designer owns
Component libraries with proper auto-layout. State coverage across loading, empty, error, and success. Accessibility specs that pass an audit. Responsive breakpoints and behavior. Developer handoff through Figma Dev Mode, with Code Connect surfacing real React, SwiftUI, or Jetpack Compose code from the design system instead of generic CSS.
A strong UI/UX portfolio in 2026 still leads with high-fidelity screens, before-and-after auto-layout case studies, and design-system documentation. The case studies are about consistency, hierarchy, and the speed of the development team that picks up the work.
What a Product Designer owns
The business result, expressed through the interface. Onboarding that gets people to first value. Activation and retention. Monetization and referral mechanics. The work starts from a metric and a user goal, not from a screen. Research, synthesis, and working prototypes are how they get there, but the deliverable is a number that moved, not a frame.
A strong Product Designer portfolio in 2026 reads like a small product company's roadmap. The case studies name the metric, show the decision, and end in a shipped change and its result. The working prototype is evidence, not the point.
The portfolio test
Two heuristics that work during a 20 minute portfolio review.
The first heuristic is file type. Open the three most recent case studies in the portfolio. If the dominant artifacts are Figma frames, design-system pages, and handoff specs, you are looking at a UI/UX Designer. If half the artifacts are research synthesis pages from Dovetail or Maze, user-flow diagrams, and live deployment URLs from Lovable or v0, you are looking at a Product Designer.
The second heuristic is the first sentence about a new product. Show the candidate a product they have not seen. Ask what they would do first. A UI/UX Designer talks about the screen, the hierarchy, the system. A Product Designer talks about the user, the problem, the metric the work is supposed to move. Neither answer is wrong. They tell you which lane the candidate has built their reflexes in.
A UI/UX Designer designs the interface. A Product Designer designs the business result through it.
Three hiring scenarios
Scenario one. You are taking an existing product to a refresh and you need to ship the redesign through engineering. Hire UI/UX. The work is design system, screens, state coverage, accessibility, and clean Dev Mode handoff. A Product Designer can do this work, but you will pay for capabilities you do not need.
Scenario two. You have a problem space and you do not know what the product should be yet. Hire a Product Designer. The work is owning the path from a user problem to a product that moves a metric: research, synthesis, flow definition, and prototypes you can test this month. That is a responsibility a pure interface designer is not set up to carry, whatever tools they know.
Scenario three. You have a working prototype that came out of a discovery sprint and you need to harden it for production. You probably need both, sequenced. The Product Designer who built the prototype hands off to the UI/UX Designer who turns it into a design system and ships it to engineering. Both names appear in the credits.
Where the framing breaks
The responsibility line is clearer than the tool line, but it is not a wall.
Some senior UI/UX Designers own real product outcomes. Some Product Designers stay deep in Figma every day. Small teams often have one person carrying both, and that person is called whatever the team needs that week. The tools keep converging too: Figma Make and Figma Sites pull building back into Figma, and a UI/UX Designer can now ship a working prototype without an engineer. That is exactly why the tool is the wrong test. When the tools collapse into one, the question that still tells the roles apart is the one that never moved: who is responsible for the metric.
What 2muchcoffee covers
We ship UI/UX work through the lane I work in. Design systems, components, accessibility, Dev Mode handoff. If your project is a UI/UX engagement, the studio is set up to deliver that work end to end.
For Product Design engagements that own activation, retention, and conversion end to end, the studio partners or refers. That responsibility is a different one, and it deserves practitioners who carry it full time.
One concrete action
Before your next intake call with a designer, finish one sentence. The person we hire will be responsible for ___.
If the blank is the interface (clear screens, a design system, accessibility, clean handoff), you are hiring UI/UX. If the blank is a business outcome (activation, retention, conversion) owned through the interface, you are hiring Product Design. If you cannot fill the blank, the role is not defined sharply enough to hire for yet, and the next conversation is with the team lead, not the recruiter.
Be View portfolio ↗
