Product design vs UX design: which capability do you need?

The short answer

For digital products, product design can connect product direction, user experience, and delivery constraints. UX design focuses on understanding and shaping how people use a product in context. Both can involve research, strategy, and business trade-offs. Their work overlaps, and job titles vary by company.

The two fields share a user-centered starting point, which is an understanding of people's needs and designing something that meets them. If you're deciding whom to hire, start with the decision your team needs help making, because relying on a title alone can leave quite a bit unanswered.

Does your website meet your conversion benchmarks?

Not quite? We have solutions to get you there.

Learn more

Compare the work itself instead of the title

Here's a working comparison for when you're writing a brief or discussing a role.

Nielsen Norman Group's glossary explains that design job titles aren't standardized and that one person may work across several disciplines. Check the responsibilities behind “product designer” or “UX designer” before assuming either title describes a fixed package of skills. Salaries and career switching are outside this comparison; the question here is what your product needs.

Product design: connecting product decisions and experience

Product design involves turning an understanding of users, product goals, and constraints into a proposed way for a digital product to work. That can mean exploring a new concept, designing a feature, or improving something people already use. The work can continue after release as the team learns more from actual use.

For example, when designing a mobile app, a designer might consider which gestures make sense for moving between screens and how to display information in an easy-to-read format. Those choices also need to fit the platform, the available data, and what engineering can implement, because a gesture that looks good in a prototype still needs to work in the product.

Depending on the assignment, the work can include:

• Researching the needs and context of the intended users.
• Reviewing competing approaches to understand available alternatives.
• Sketching how a product or feature could look, feel, and work.
• Building a prototype to explore behavior and test assumptions with potential users.
• Getting stakeholder feedback, comparing it with user evidence, and deciding what needs another pass.

Sometimes that means going all the way back to the drawing board. Sometimes even a small change is enough, and deciding which one is the exact point of such feedback.

Product designers can contribute to strategy and prioritization alongside a product lead and engineers. Responsibility for the roadmap, budget, or release still needs an explicit owner. For a fuller definition, see what product design involves; the product design process covers how that work can move through stages.

UX design: understanding and improving the experience

UX design considers what people need to accomplish, the context in which they work, and the experience the product gives them along the way. Usability, accessibility, understandable information, and feedback all belong in that discussion. So do the expectations and frustrations people bring to the task.

That reaches beyond the appearance of a screen. Don Norman and Jakob Nielsen's definition of user experience includes the broader relationship between a person and an organization's products and services.

In a digital product, UX work might involve organizing content into a useful information architecture, mapping a journey, designing interactions, or testing a prototype. A wireframe can show the structure of a navigation menu; an interactive prototype can let someone try opening its submenus and finding a destination. Each helps answer a different question.

These artifacts make assumptions easier to examine. They can expose a missing step or confusing response, although no prototype accounts for every problem a released product might have. Research and validation should match the uncertainty you're trying to resolve.

Where the work overlaps on real teams

Research, information architecture, interaction design, prototyping, and feedback can appear in either role's work. A UX designer can contribute to product direction; a product designer can investigate a specific usability problem. Both need to understand the user and the business context.

How that work is divided depends on the team. Here are three possible arrangements:

• A small team with one generalist. One designer handles research, flows, prototypes, and UI, with a founder or product lead and engineers contributing their decisions. Check that the person has the skills and time for the scope.
• A larger team with specialists. Researchers, interaction designers, visual designers, and other specialists contribute different kinds of work. Agree on how findings become design decisions and who resolves conflicting feedback.
• A cross-functional squad. A designer works alongside product and engineering on a defined area. The group can investigate a problem together, then divide responsibility for experience, priorities, and implementation.

UI design and product management sit alongside this work. UI design covers interface components, visual presentation, and interactive behavior. Product management concerns product direction and priorities. The boundaries can overlap, so write down who recommends a change, who approves it, and who implements it.

Which capability fits your situation?

The problem or workflow is still unclear

You may know the audience and have a feature idea, while still being unsure what people need to accomplish or why their current approach fails. Start with problem framing and research, with a product lead responsible for the resulting product decision.

Useful outputs could include a description of the problem, evidence about user needs, and a proposed workflow with open assumptions. If the problem and audience are already supported by evidence, keep the investigation focused on what remains uncertain. For Merge engagements where that foundation is missing, product discovery is a possible starting point.

People struggle with an existing flow

Perhaps users abandon a setup flow or repeatedly ask support how to complete it. You need to understand where the difficulty comes from before choosing a redesign.

Look for research, information architecture, interaction design, and validation skills. The output might be findings tied to particular steps and a revised prototype you can check with users. Low conversion alone doesn't establish a UX cause; pricing, reliability, audience fit, or missing functionality may change what the team should do next.

The experience must work across roles and states

A reporting area may serve an administrator, a manager, and a viewer with different permissions. The work needs someone who can connect their journeys, define shared patterns, and discuss constraints with engineering.

A role-and-state map, connected flows, and representative screens can help the team agree on behavior. If the permission policy itself is unresolved, involve the person responsible for that policy before treating the interface as settled. A designer can explain the options and what each would change.

The product logic is defined and visual execution is next

If your team has already established the users, task, flow, and relevant states, UI and interaction design may cover the next piece of work. Possible outputs include detailed screens, components, and the feedback shown after each action.

Check what supports those earlier decisions. A signed-off flow can still contain an assumption worth testing. For defined product flows, Merge offers UI/UX design support; research, testing, and other additions depend on the agreed scope.

One reporting workflow but two different design briefs

Imagine a hypothetical SaaS product where customers export reports.

Brief A: the team still needs to define the task

The team hasn't agreed which roles need exports, what information each role can access, or why people download the report. Drawing an export button would leave those questions open.

The work needs research and product reasoning alongside experience design. A useful output could combine findings about the reporting task, a proposed permissions matrix, and a flow that makes the choices concrete. The product lead and relevant data or policy owner approve the access rules; design and engineering help assess how those rules affect the experience and implementation.

Before moving ahead, the team should be able to explain who needs the report, what they need from it, and why access differs between roles. A prototype can then help check whether intended users understand the proposed flow. Engineering and security remain responsible for technical access enforcement.

Brief B: the task is defined, but the interaction is confusing

Now suppose the roles, report contents, and access rules are agreed. Users struggle with the filters and can't tell whether an export is processing, complete, or failed.

This brief needs focused interaction and interface work. Possible outputs include a revised filter layout, an interactive prototype, and designs for the relevant export states. The product lead confirms that the changes preserve the agreed behavior; engineering checks what the system can report, while the designer develops understandable controls and feedback.

You could check whether an allowed user can select the intended report and recognize what is happening during export, including what to do after a failure. Separately, engineering and security should verify that a prohibited role cannot retrieve the data. These are proposed checks, not results of a test we've run.

The same capable designer or team could work on either brief. The useful difference is how much is still unknown, which skills the work needs, and who can approve the decisions.

What overlap looked like in Merge's TelQ work

Merge's published TelQ redesign describes work on an existing SMS-testing platform. It included a UX audit, competitor analysis, a visual concept, work on the menu for creating tests, and UI/UX design for the Admin area.

The case shows investigation, interaction decisions, and visual design in one assignment. It doesn't identify separate “UX designer” and “product designer” roles or report a measured outcome.

How design connects to engineering

Whichever role you bring in, discuss implementation while the decisions are still open. Platform compatibility, data availability, loading behavior, and technical limits can affect the proposed experience.

Agree on the artifacts that will help the developers build the intended behavior. Depending on the work, these could include connected flows, relevant states, editable screens, component details, and notes explaining a decision. Make the approved version easy to identify and keep unresolved questions visible, with someone responsible for answering them.

Our design handoff checklist covers that preparation in more detail. Coding, a formal engineering review, and design QA during the build each need their own agreement; neither job title automatically includes them.

Five questions to brief a team or partner

Before comparing candidates or discussing a project, write down your answers to these questions:

1. What decision do we need to make? “Decide how an administrator grants export access” gives someone a clearer starting point than “improve the dashboard.”
2. Who uses this, and in what context? Describe the roles, tasks, devices, and circumstances that affect the work.
3. What evidence do we have, and what's missing? Separate what you've observed from assumptions, stakeholder preferences, and questions still to investigate.
4. What are the constraints, and who approves what? Include technical limits, budget, timing, and the people responsible for product, policy, design, and implementation decisions.
5. What should we be able to observe afterward, and who will check it? Name a task or behavior the team can examine, such as recognizing an export failure and knowing the next step.

When reviewing someone's work, ask them to explain a relevant decision: what they knew, what was uncertain, which options they considered, and how they checked the result. That gives you something concrete to compare with your brief.

Frequently asked questions

Is product design the same as UX design?

The work can be very similar, especially when one designer covers a digital product's research, flows, prototypes, and interface. Product design can connect those decisions across a product area, while UX design focuses on the experience in context. Check the actual scope: the titles don't establish a universal boundary.

Is UI/UX part of product design?

A digital product design assignment can include UI and UX work. That doesn't establish a universal organizational hierarchy. UX can address a journey beyond one product, and a company may split research, interactions, and visual design among several specialists. Specify the work you need and how those people will collaborate.

Can one person do both product design and UX design?

Yes, if they have the relevant skills and enough time for the assignment. Ask for examples of the work your brief requires, including research or validation where needed. Check how much of the work they can take on and where a specialist might need to join.

Which is better for my product: UI/UX or product design?

It depends on the open decisions. If the product logic and flows are defined, focused UI and interaction work may be enough. If roles, journeys, or product trade-offs remain unresolved, include the skills and decision owners needed to work through them. Check the evidence behind the agreed scope before committing.

Choosing the next step

First, choose the people who can address your open decisions, show relevant work, and agree on responsibility with your team. If you already have those skills in-house, your next step may be to gather the missing evidence and refine the brief together.

If you do understand your problem and audience but need help connecting product flows, roles, states, and interface decisions, explore Merge's product design support. Bring what your team already knows, along with the questions it still needs to answer.