Product Designer vs UX Designer: Who to Hire?
mins to read
Product designer or UX designer? Employers that are searching for a design specialist to join their teams have trobles in understanding who they need to hire. Even people that are working in the design industry for quite a long can't reach a consensus when discussing the "Product Designer vs UX Designer" topic, as the responsibilities of these two roles overlap a lot.
Eleken is a team of product designers. Working in this profession means being able to do a lot of stuff. At some points, you have to be a visual designer, researcher, marketer, analytic, psychologist, and a bit product owner. In general, the distinctive feature of a product designer is they are business-oriented.
In its turn, a UX designer has more specific design responsibilities. They strive to create the best customer experience and that's why user needs are always at the forefront for them.
To decide whether you need to hire UX designer or Product designer, outline the tasks you want the designer to accomplish, then check which of the two professions meet your requirements better.
To help you with this challenging task, in this blog post, we will discuss:
- The essence of the job of a UX designer and of a product designer
- Сommon and distinctive features of both professions
- The responsibilities of both occupations
UX designer overview
To understand what is the difference between a UX designer and a product designer we should, first of all, understand the specifications of each occupation in particular. Let's start with the user experience designers.
From the job title itself, we can understand that a priority of a UX designer is creating an outstanding experience for customers. After all, the experience of the clients for whom we create products determines the success of the service and business in general.
UX designers strive to make a product usable and accessible for the end-customer. The scope of their work includes the research, the formation of ideas and concepts, creating wireframes, building prototypes, and conduct tests. To find a solution for the design problem a UX designer invests a lot of time in studying the customer, their motivation, and emotions.
Product designer overview
A product designer is a full-stack designer responsible for owning all aspects of product design including product ideation, building a design system, and UI/UX details.
This specialist identifies product problems with the help of analytics and research, develop effective solutions through prototyping, and implement changes taking into account the product's business strategy.
For those purposes, they combine the roles of a number of professions like UX designer, graphic designer, researcher, analyst, prototyper, marketer, and business strategist.
Product designers cooperate closely with developers, marketers, and other designers to understand, envision, and influence products and their strategy and as a result, create a market impact.
Product designers need to have a business sharpness to understand the pricing models and strategies, as well as the main metrics of the product viability to develop such design decisions that lead to the product's growth.
Сommon and distinctive features
At this point, you may understand that both UX designers and product designers have much in common and the duties they perform are very similar. Still, there should be a reason we use different words to describe these jobs, right?
Next, we will figure out the main similarities and differences between these professions.
Here are some clear similarities between both occupations:
Product design process
First of all, UX and product designers take the same steps when designing a product. That is, they use the same product design process with its main focus on customer needs.
When designing a product designers conduct market and user research to find the main problems of the product, develop various concepts, and visualize them through prototyping. Then both designers test prototypes to understand what works well and what requires improvements and refine the product if needed.
Since the product design process is the same for both occupations, the UX and product visual design methods and deliverables are also identical.
To gather all the needed data at the research phase both designers conduct market analysis, competitive audit, and user interviews. Then in a team, they brainstorm to create various ideas and visualize those ideas with the help of customer journey maps, user flows, mood boards, sketches, and wireframes. Finally, designers validate different concepts, build prototypes, and test them with the A/B testing method, usability testing, etc.
Consequently, the tools both professionals use for those methods also don't differ.
UX and product designers use MIRO for brainstorming and building user flows, Sketch or Balsamiq for wireframes, and Figma, Adobe XD, Invision, or Framer for prototypes.
To sum up, three main things that both designers have in common are the design process they go through, and the methods and tools they use to develop a product.
Despite all the things they have in common, here are key differences between these occupations:
UX designers and product designers differ in the priorities they have.
The main focus of a UX designer is the customer experience. This specialist cares about the usability, and the emotions it evokes in customers. UX designer strives to create a clear UI and a smooth UX that allows clients to reach their objectives as quickly and efficiently as possible.
In their turn, besides user needs, product designers have a deeper focus on business needs. They think about how to make the product suitable both for the client and current market requirements. The role of a designer in product development is to make it cost-effective. Product designers care about company goals as well as client needs.
As we've already stated a product designer is a versatile specialist and the responsibilities of a UX designer are more specific. That's the first one has a wider range of skills than the second.
The product designer is supposed to work with engineers and keep track if the developed product meets the concept created in the prototype. They cooperate with marketers to provide consistency between the brand and the product. That's why a product designer needs to know how to communicate with people from different departments.
Check the Product Designer Job Description to learn more about product designers' skillset.
UX designer has a deeper understanding of user research methods. They are more skillful in collecting and analyzing customer's feedback.
Both job positions offer high and competitive pay. Though, a more diverse skillset of a product designer leads to a more diverse list of responsibilities. Which results in a difference between salaries.
Glassdoor says that the average pay of a UX designer in the US is about $85,000 per year.
While the average base salary for a product designer in the US is almost $88,000 per year.
How much money does a product designer make? This sum vary from location, organization, and type of project but in general, product designers receive a bit higher payment because of higher demand.
With a general understanding of both jobs, their common and distinctive features, let's take a look at their responsibilities.
UX designer's duties
After analyzing job posts from LinkedIn we formulated the following duties of working as a UX designer:
- Create thoughtful sketches, comprehensive wireframes, and high-fidelity prototypes to present to key stakeholders throughout the product development process
- Conduct usability testing and research
- Identify and troubleshoot UX problems based on qualitative data and feedback
- Cooperate with other designers, researchers, product managers, engineering, and customers to design simple and elegant products
Product designer's responsibilities
Now let's take a look at what a product designer is supposed to do to perform their duties.
- Create beautiful, simple, and intuitive experiences, defining the needs of the customers
- Work with engineers and product managers to define both the long-term strategy and the short-term tactics for the products
- Give and solicit feedback from end-users to constantly raise the quality of the product
- Cooperate with Product and Engineering to supervise the user experience of a product from conception until launch
- Perform design reviews and confidently communicate decision-making rationale to team members and stakeholders at all levels of the organization
- Explore concepts, narrow to the best solution. Use the best formats and fidelities for the work.
As you can see, the key duties of a UX designer and a product designer prove that they have many commonalities. Both jobs certainly need a high level of design skill. Still, while the job of the product designer needs decision-making skills and marketing sharpness, the UX designer job requires more specific responsibilities like research and building wireframes.
We hope that now you have a clearer understanding of the essence of both professions and can see the difference between a UX designer and a product designer.
So, it's time to take a pen and a piece of paper and make a list of requirements for your project. Once you are ready compare this list with the key responsibilities of both types of designers and start your search!
After all, no matter whom you will choose, we believe that when a designer creates and improves the product according to user feedback and understand the needs of your specific business, formally it does not matter what job title they have in the resume.
If you are looking for designers that can both design a great experience for users and take into account your business needs, reach out to us for a free consultation.
Hiring a Design Agency? Learn How to Share UX Design Requirements
In July 1938, a small silver plane made a wide turn over a city and started down to the airport. The pilot landed his plane, stepped out, and exclaimed: “Where am I?”
It was Corrigan Douglas. He took off from New York, with plans to land in California, but the compass had malfunctioned, he lost his direction in the clouds and accidentally flew over the ocean. Due to a navigation mistake, Douglas “Wrong Way” Corrigan made a transatlantic flight from New York to Dublin.
Aviators will tell you that being off course by just one degree, after flying 60 miles, you'll miss your target by a mile. The further your road goes, the more remarkable your mistake gets. And harder to fix.
Designing a product doesn't happen overnight. Like with long-haul flights, going off course even a little will make a huge impact on the final result.
Initial requirements gathering is a preliminary phase of the design process that is crucial to setting the whole project off in the right direction by focusing on the right problems to solve and, consequently, building the right thing.
No other part of the conceptual work is harder than deciding on requirements. No other part of the work cripples the result so much if done wrong. No other part is as difficult to rectify later.
That's not hyperbole — 39% of failed projects fail due to inaccurate requirements gathering.
Seemingly both designers and clients are interested in getting the requirements right. So how is requirement gathering done and why does this process often go painfully wrong?
What makes UX design documentation difficult (and how to fix it)
So you have an app to build, and you’re looking for designers to help you with the UI/UX part. If you are lucky enough to have in-house design capabilities, you’ll explain to fellow colleagues what you want them to do and they'll be likely to understand. Those people have been sitting on hundreds of your weekly meetings, they’ve read miles and miles of your company’s Slack conversations. In other words, they understand the context.
But since you’re reading this article, you haven’t got enough in-house design capabilities. You're going to cooperate with a stranger who is a design and user experience expert but doesn’t know much about your context, your market, and your audience.
It’s like taking a taxi with a driver who has never been to your city and has no navigator on board. Before taking off, this guy will ask you about your destination and the best route. That's the same kind of thing any designer will ask you when getting to work.
The input information from clients usually sounds something like this:
“We need to design/redesign this MVP/app/website”
That’s not enough to open Figma and start wireframing. The designer needs to gather more information:
- To understand precisely what is required of the design. What is the idea of the product, its goals and objectives, its future functionality and competitors, its users and their needs;
- To decide on some basic schedule and roadmap for the design milestones;
- To agree on production control to ensure final prototypes satisfy the requirements.
The problem is that we have some obstacles that get in the way of making all the UI/UX requirements clear. The three C’s formula — Communication, Comprehension, Control — captures all the components capable of throwing any design project into chaos.
Communication: breaking barriers and building bridges
When you tell your designer you’re making a breakthrough decentralized P2P ecosystem, it’s quite the same as switching into the language of birds. What sounds just fine for you with your industry expertise sounds like white noise for a designer.
Software is complex, abstract, difficult to visualize and explain. That creates communication barriers you and your designers have to eliminate on the road to fruitful communication.
We at Eleken UX design agency believe that the ability to understand each other is key to a successful project. That’s why we literally built our working process around communication with clients.
- We don’t ask you to fill a brief — because no UX design specification document can explain customer needs better than a real conversation when you can ask what the heck “decentralized P2P ecosystem” is when you hear such kind of white noise.
- We arrange calls with clients, a lot of calls. In some cases, they are even meetings and workshops — all to discuss the product and clarify our next steps.
- We don’t have project managers in our agency — the person you talk to is the person who designs your app. Cutting out the middleman allows us to make sure the message always reaches the right person, and not in a Chinese whispers way.
What clients can do, for their part, is being responsive. If the designer has questions, try to answer them fast to optimize their time and your investments. A designer that doesn’t get timely feedback can either wait for your reply, thus being blocked, or continue working on assumptions that might lead the project down the wrong way (ending up somewhere in Dublin).
Comprehension: how to define requirements for a project
Maksym, a UI/UX designer at Eleken, provides a typology of projects based on the level of the customer’s comprehension:
- Smooth projects, when clients know what they want and how they want it to be done. Designers, in such cases, are not involved in any conceptual decisions, but simply work according to specifications given. Not the most creative stuff, but smooth sailing from day one. The result is usually assured and the customer is satisfied.
- Successful projects, when clients know what they want, and trust designers to define the best ways for things to be done. Clients’ knowledge and designers’ expertise unite for synergy and success.
- Fun projects, when clients don’t know what they want but trust designers to help them figure things out. Eleken specializes in designing apps for SaaS startups, so we basically specialize in fun projects.
For sure, it’s an ideal scenario when you come to a designer and clearly know how your app is going to work and look like — it just saves your time. However, our experience shows that clients rarely know what they want (until they see it). Not in the detail necessary for design specification, at least.
And it’s okay. Bring a vision, then let the agency figure out the details. Experienced designers can help you define requirements for a project. It just means that you’ll go all the way carefully testing the waters, and you’ll participate in communicating on a daily basis for the feedback exchange.
A designer will show you various types of products to understand your preferences. They’ll study all the existing written materials on the topic, and check their findings with you. They’ll do user experience research, and validate it with you. They’ll create user journeys, and show them to you to obtain your feedback. They’ll make wireframes and prototypes, and show them to you many, many times until the result satisfies you.
Deep comprehension can be replaced by the customer’s trust and active cooperation.
Control: navigating through the fog of uncertainty
The saying was that two things in life are certain: death and taxes. A design project plan is not on the list. Because the product design process is hard. It’s nuanced. It takes months (and sometimes years) to bear fruit.
Yet precision is what designers often asked for. Clients want to know exactly when the project will be done, how much time each step will take, and what the schedule is.
At the beginning of any project, we don’t know how long this is going to take. We can compare it to our previous experiences, but no two projects are the same. They never have the same requirements, the same people, the same priorities, the same UI/UX design tasks. Each is unique.
At first glance, we can say whether the UX scope of work is going to be large (6+ months), medium (2-5 months), or small (a couple of weeks).
As more research and development is done, more information is learned about the project, the uncertainty tends to decrease. After a couple of iterations, we can learn and create something, measure how long that takes, and then give you a much better sense of how big this thing is.
To make gathering customer requirements in the fog of uncertainty easier, we at Eleken provide you a 3-days trial free of charge. On the expiry of the trial week, you can make an informed decision on whether you want to go on working together, and we can make better estimations on the scope and schedule.
Wrapping up our little guide to UX design process & documentation
Product design for SaaS startups is where outsourcing never works, but collaboration always does. Collaboration is especially important at the initial phase of UX requirements gathering. If you give agency money and then sit around waiting for them to impress you, you’re risking ending up in Dublin instead of California.
But the effort is worth it. After all, we seek to create something that people love and have value from — this is the real magic of being either an entrepreneur or a product designer.
We’ve been talking about business requirements. If you want to read about how we elicit user requirements, read our piece about the UX research process.
And if you’re ready to discuss your design requirements with us, drop us a line.
Scrum Master vs Product Owner: Can It Be One Person?
Product management is a complex field that involves many roles and positions whose duties seem to overlap. This is especially true when it comes to Agile environment, where the pressure to complete product sprints can blur the lines between who is meant to do what. And when it comes to the Scrum Master vs Product Owner dilemma, some business executives are unable to distinguish the two roles and can’t decide whether they need a Product Owner, a Scrum Master, or both in their team.
So, what exactly is the difference between Scrum Master and Product Owner?
As a UI/UX design agency for SaaS that has had some luck to work with Scrum teams, in this article, we want to help you understand what tasks both people have to perform during the development process, so that you can decide who to hire.
Understanding the Product Owner's role
To start with, the Product Owner (PO) needs to have a strong product vision. They don’t dive into details of how the product is going to perform, but they have to understand why the product is being built, what problems it’s going to solve, and who’s going to use it.
For this purpose, POs communicate with stakeholders (customers, investors) and transform their needs/challenges into user stories, which are then implemented by the team of developers. Unfortunately, it’s impossible to satisfy all the stakeholders’ needs (otherwise the development team will be overloaded with loads of tasks), therefore user stories form a backlog — the list of features a product should contain.
The PO’s task is to collaborate with developers and stakeholders to prioritize the list of features in the backlog and
- estimate the value and size of each user story and define which are worth building and which are not
- decide which features are critical to build first, and which can be developed later
- define how long the product backlog should be.
So, product ownership is all about communication. POs should make sure everybody understands the product vision, the development team is in direct contact with the stakeholders, and there’s a short feedback loop in terms of frequent deliveries to real users.
Understanding the Scrum Master’s role
The Scrum Master (SM) bridges the development team and the Product Owner and is primarily in charge of empowering the team to accomplish the sprint goals. Their main objective is to make it easier for the development team to deliver the project’s outcomes timely.
SM heads the development team and ensures that everyone there adheres to the Scrum principles. By doing so these guys make sure that the entire team is familiar with the Scrum guide, methodology, and Scrum events and, as a result, can perform at their highest level.
Besides, SM is responsible for coordinating all the project activities aligned with business objectives and
- acts as a facilitator for both the Scrum Team and the Product Owner, managing them as a unit and removing obstacles that block sprint progress
- manages the process of information exchange between the team members
- facilitates meetings by questioning the team “What was done yesterday?”, “What will be done today?”, “Are there any obstacles in your way?”.
Scrum Masters work to increase team efficiency and recommend changes to the product vision, roadmap, and backlog.
To sum up, a Scrum Master has more of a supervisory role. They play their part by ensuring the Scrum approach is implemented during the product development process.
Product Owner responsibilities
Here are typical responsibilities that a product owner job description may include:
- Capture and write user stories, explain product vision and user stories to the team to ensure they understand requirements and customer needs.
- Create, manage, and priotirize product backlog, so that the development team can clearly understand what they are to build.
- Approve each feature and continuously communicate with the development and business teams to ensure adherence to product vision and to evaluate risks proactively.
- Collaborate with a product manager to develop the product vision and product roadmap.
- Work with the Scrum Master to make sure the product's development aligns with the original goal.
- Work with team members to ensure requirements, pain points, hidden needs, and expected outcomes are properly documented.
- Decide on project deadlines and determine the release date.
Scrum Master responsibilities
- Facilitate adoption of the Scrum framework.
- Assist the Scrum team in meeting sprint goals and delivering software solutions in an iterative manner.
- Support the Product Owner in creation, improvement, and prioritizing of the product backlog.
- Proactively eliminate barriers, instruct team members on optimal practices.
- Organize Scrum rituals (daily Scrum, sprint planning, sprint retrospectives) and make sure each team member attend them.
- Protect the team from any kind of distractions and allow them to stay tuned.
- Deliver activity and progress updates, mentioning all lingering obstacles and problems that influence team productivity and sprint efficiency.
- Make sure the project is completed on schedule and within the allocated budget.
Main differences between the Scrum Master and Product Owner
There are three key perspectives you need to keep in mind when working on project: build the right product, build the product right, and build the product fast. But, usually, it’s difficult to find the balance between the three. Therefore, there’s a healthy tension between the Scrum roles:
- The Product Owner focuses on building the right product.
- The Development Team focuses on building the product right.
- The Scrum Master focuses on shortening the feedback loop that accelerates learning, so that the team can quickly discover what the right product is and how to build it right.
So, let’s sum up key differences between the roles of Scrum Master and Product Owner.
- Scrum Master is focused on maximizing the value and potential of the Scrum team and extending eventual return on investment (ROI), while the PO is focused almost exclusively on building the best possible product for the customers.
- Product Owner forms a link between the Scrum Team and the customers. They are responsible for maximizing the value of the product after analyzing and prioritizing product features using sprint reviews and other similar methods. The role of the SM is more of the supervisor that coaches the team to ensure that everyone is aligned with the Agile process. They host daily stand-up meetings to sync with the development team's progress and note any obstacles that may keep the team from completing tasks.
- Product Owners are accountable for project completion and providing timely updates to clients, while the Scrum Master is accountable for the entire quality of the project, as well as keeping the team on track towards meeting project’s completion timelines.
Scrum Master salary
According to Glassdoor, the Scrum Master in the United States is a highly-paid professional that earns about $108,571/year, while the average salary in the US is $95,831/year.
Now, let’s take a look at the average SM salary around the world, according to Glassdoor.
Product Owner salary
The average salary of a Product Owner in the United States slightly differs from that of an SM and is around $107,478/year.
Still, when we look at the average PO salary around the world we see that the situation here is different: while SMs earn the most in the United States, Product Owners are better paid in Singapore.
Can PO and SM be one person?
If you asked whether a Product Owner and a Scrum Master can be one person the answer would be “Yes”. If you asked if they should be, the answer would be “No!”
Now, let’s get to a more detailed explanation.
In our practical experience of creating UI/UX design for various SaaS companies of different sizes and structures, we’ve encountered cases where one person performed the role of both PO and SM. Such a situation is most common for small startups at the early stages of product development. It works well for them, as usually their team consists of a CEO (who plays the role of PM/PO/SM), a developer, and a designer, so there’s no sense to build a strict organizational structure.
However, for bigger companies, we don’t think it’s right to hire one employee for two positions, unless it's just temporary while working with developers to "groom" someone into a Scrum Master.
This is because a competent SM will encourage the team to go an extra mile in terms of commitments while also ensuring that they are performing their tasks sustainably. While POs can handle this role, there may occasionally be situations when the Product Owner pushes for the maximum features, leading engineers to develop in an unsustainable and brittle way.
Besides, being a Product Owner is about having a vision and goals. It involves collecting information and, eventually, saying “No” to some ideas. Being a Scrum Master, on the other hand, involves identifying opportunities for growth, interacting with others, figuring out effective teamwork techniques, mentoring the Product Owner and the development team, acting as a good host for Scrum events, and setting an example for the rest of the team.
These two jobs call for quite distinct personalities, skills, and attitudes that are seldom found in one individual. It is against the fundamental nature of the roles to try to be both the PO and the SM at the same time.
Okay, seems like we’ve managed to dispel the confusion between PO and SM. However, these two are not the only roles that may cause you headaches when it comes to structuring a product team. Read our next article to learn about Product Owner vs Product Manager vs Project Manager.