UI, UX, and Product Design Roles in Cross-Functional Teams

Hello! This course will help you move from UI execution toward UX and product thinking, then build a practice case study and prepare for UX interviews. We’ll begin by clarifying three job titles that often overlap: UI designer, UX designer, and product designer.

Your years of UI work are a starting point, not something to set aside. The important distinction for interviews is between work you have already done professionally and UX methods you are learning to apply. By the end of this lesson, you should be able to describe what each role is responsible for, what it might deliver, and how the roles work with the rest of a product team.

Three roles, one product

Imagine a shopping app where customers often leave checkout after reaching the delivery step. A team needs to understand the problem and decide what, if anything, to change.

A UI designer concentrates on the interface people see and operate: layout, typography, components, responsive behaviour, visual feedback, and accessible presentation. On this project, UI work might include making delivery costs easy to scan, designing clear selected and error states, and specifying how the screen behaves on a small device.

A UX designer concentrates on whether the experience helps people accomplish their goal. They might investigate when customers expect to see delivery costs, map the checkout flow, compare possible ways to present delivery options, and test whether people understand a prototype. The question is broader than “Does this screen look clear?” It is also “Does this flow give people the information they need at the right time?”

A product designer commonly does UX and UI work while taking a wider view of product decisions. They might examine the checkout problem alongside customer needs, conversion goals, delivery-policy constraints, and implementation effort. They would work with partners to decide which improvement is worth pursuing and how to assess its impact.

Watch Relab Studios’ comparison for an initial picture of the roles. Treat its descriptions as common patterns, not fixed rules: companies divide design work differently.

The roles are not three consecutive stations where one person finishes and hands everything to the next. A UI designer may identify a usability problem while refining a screen. A UX designer may produce high-fidelity designs. A product designer may spend much of a week on either activity. The distinction is each role’s typical focus and scope, not exclusive ownership of particular tools or files.

Responsibilities become deliverables

A responsibility describes the work someone is expected to do. A deliverable is an output that helps a team understand, evaluate, build, or maintain a decision. For example, “understand why checkout is confusing” is a responsibility; documented research findings or a tested prototype could be deliverables. A polished screen alone would not establish why a particular checkout change was chosen.

The Interaction Design Foundation’s role guide gives concrete examples. Read the UX and UI sections with particular attention to the task and deliverable lists.

For the checkout example, the differences might look like this:

These are examples, not mandatory checklists. A deliverable is useful when it answers a question for the team. A task flow can reveal where a shopper must choose an option; a component specification tells an engineer how that option should appear and behave. Both matter, but they solve different parts of the problem.

The “Product Design: Where UX, Visual Design, and Business Meet” diagram is a useful reminder that business considerations do not replace user-centred design. UX designers also consider business goals; product designers commonly have more explicit involvement in weighing them against user needs and longer-term product direction.

How ownership works in a cross-functional team

A designer does not solve the checkout problem in isolation. A product manager helps establish priorities and product goals. Engineers assess technical possibilities and build the change. A UX researcher, where a team has one, may lead or support user research. Designers collaborate with these partners rather than claiming all their responsibilities.

Suppose customers say the delivery cost appears too late. A UX designer could help establish what customers expected and test whether an earlier estimate improves understanding. A UI designer could make the estimate readable and design what appears when the cost is not yet available. A product designer could help compare that option with alternatives, considering customer benefit, commercial impact, and engineering effort. The product manager and engineers would be involved in deciding what the team can prioritise and deliver.

Who performs the activity is not always the same as who makes the final decision. One team’s product designer may run interviews; another team’s researcher may run them while designers help plan and interpret the work. A roadmap may be developed with a product manager rather than owned by a designer. The Nielsen Norman Group reading makes this variability explicit.

This is why a strong interview answer starts with scope, not a rigid definition. When a job description says “UX designer” or “product designer,” look for the activities it actually names: Will you conduct research or partner with a researcher? Own visual design or work alongside a UI specialist? Contribute to priorities and success measures? The title gives you a clue; the responsibilities tell you more.

Describing your transition accurately

Your UI experience may already include valuable UX-adjacent work: making content easier to scan, resolving accessibility issues, designing states for complex interactions, or discussing implementation with engineers. You can describe those contributions confidently without presenting them as research or product ownership if they were not.

A concise interview explanation could sound like this:

“My professional experience is primarily in UI design, including interface detail and design delivery. I’m expanding my UX practice so I can investigate the problem behind a screen, explore flows before visual refinement, and test whether a solution works for users. I understand that a product-design role may also require me to explain trade-offs involving user needs, business goals, and technical constraints.”

That answer connects existing experience to the new scope while remaining precise about what is still developing. As you gain practice-project evidence later in the course, you can replace general intentions with specific examples of methods you used and decisions you made.

Key takeaways

UI design focuses on the quality and behaviour of the interface. UX design addresses the broader journey from understanding a user problem to testing a possible solution. Product design commonly includes UX/UI work and greater involvement in product priorities and trade-offs. Their deliverables overlap, and their boundaries depend on the team.

Most importantly for interviews, do not rely on titles alone. Explain the problem you were addressing, your actual contribution, the evidence or constraints you considered, and who you worked with. In the next lesson, we’ll use a familiar e-commerce feature to walk through a human-centred design process from problem to tested improvement.