Product Designer vs UX Designer: Who to Hire?

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.

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

After analyzing the Scrum master job descriptions on Linkedin and Upwork, we formed the following list of responsibilities for SM:

• 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.