How to Hire UX Designers: What Works and What Doesn’t (A Designer’s Perspective)

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.

Let’s face it, leading a distributed design team with no possibility to quickly look over your employees’ shoulders to check whether their designs are fine is challenging, if not hard.

Thanks to the big remote shift due to the world pandemic, many businesses adjusted and went to work fully online, but for many companies, hidden problems remain. We can group typical challenges for remote teams into three categories: broken communication in the teams, a silos mindset, and weak ties. 

In Eleken UX design company, we believe in a collaborative approach to design. Our design is not created in a vacuum, but in constant communication and collaboration with stakeholders, product managers, users, and development teams. So the infamous three we mentioned above would just impair our work.

In this article, we share the best practices for distributed teams that actually work. Here’s how we defeated the most common challenges of remote work.

Challenge #1. Broken communication 

If you want to manage a remote design team easily and effectively, first of all pay attention to how the communication is happening. 

In remote design teams, spontaneous communication is absent and text format leaves a lot of room for confusion. As a result, colleagues communicate less, and miscommunication often happens.

As it’s been said many times, communication is the key and you don’t want to let it become chaotic in your distributed design team. Here’s what you should do:

• Keep the number of video calls limited as they are the most tiresome form of communication. Incorporate the culture of follow-ups after online meetings. 
• Organize the rest of the communication channels: messengers, design tools, and calls should not duplicate one another but work as a structured communication system.
• Ask for feedback from your team members about the communication. If people in the team are frustrated with something, they might (consciously or not) sabotage the comunication.  

After implementing these tips, your communication with the team will become more on-point and effective, people will proactively approach each other with specific questions, and it will get easier to lead a remote design team. 

But there are other pitfalls waiting for you on the way. 

Challenge #2. Silos mindset

There’s a chance that you have never heard of silos. Or heard about it in an agricultural context. You are not alone, silos is a rather new term in business language. It describes a situation when departments of the company work isolated from each other. Instead of sharing their expertise, teams store it like grain is stored in actual silos. 

Covid-19 was a big test for remote teams and it caught many companies off guard. Some teams simply did not know how to work remotely and it deepened the problem of silos, so departments started growing apart. 

Silos mindset is a serious problem, especially for product companies. When there’s no strong cooperation, knowledge sharing and such, the success of your product is at risk.

Imagine the situation: your designers and developers work as two independent departments that contact each other only when it’s time to hand off the design. As a result, the design team creates layouts without consulting with developers about technical possibilities for implementation. 

As a minimum, developers will have many questions for designers, and the work will be slow. But scenarios can be even worse, up to the need to create a new design to meet the development possibilities. This is a silos problem in action. 

The good news is that it is possible to deal with silos: 

1. First of all, educate your team, explaining the importance of sharing expertise with each other and working towards a common goal as one organism. 
2. The next step is creating easy ways to communicate and share the company's knowledge base. 
3. Build cross-functional teams and effective collaboration processes. 

But even when all the processes are done right, the human factor still remains. And for the teams that are distributed around the world, it can be a serious challenge. 

Challenge #3. Weak ties

It might sound a little weird, but weak ties are the biggest problem for distributed teams. Broken communication and lack of collaboration can be solved with the right processes. But how to make people cultivate friendly relationships if they rarely see each other and spend work days apart?

• Implement the culture of getting to know each other across the team. There are great ice-breaking tools like Donut Slack bot for random and casual one-on-one meetings.

• Know your team members and organize outstanding online activities that people will actually love. Having fun online is possible. Think outside the box and be creative as a team. You can try a Wonder platform for online creative collaboration and building the feeling of togetherness in the distributed team.
• Corporate off-sites are a must. At least once a year bring your people together to eat, play and connect. 

Even if your distributed team belongs to different companies that work independently, the ideas we mentioned above will only improve your remote work. 

How Eleken leads a distributed team of designers

Eleken was among those companies that effectively worked online before it was cool. Actually, since the company was founded in 2015, we have been working in a hybrid format. Our clients are around the world, and with each of our projects, we prove that long-distance relationships do work. 

Our design team leader Maksym recently shared the advice that basically sums up Eleken leadership:

• Don’t be afraid to give people freedom of action and responsibility.
• Don’t micromanage, but trust your designers. 
• Apply product management best practices, even if you are not a product manager.
• Surround yourself with smart people eager to learn new things.

How do we manage our remote design team and implement these principles? 

First of all, we keep our design, marketing, sales processes, and documentation tidy. We mostly use Notion for that.

‍
Our team is growing and onboarding new people is important. Our onboarding document for new designers makes the start of remote work with the design team quick and simple. 

A new colleague can come back to it or study our design processes there anytime. The same approach we have to our collective expertise- we preserve and share it through design systems and inner design workshops. 

Every week we have design feedback sessions and collective brainstorming for the design team.

We recommend this practice to all remote design teams, as it brings the team together, and it’s a great and fun way to learn together.

War in Ukraine became a huge stress and emotional challenge for all Ukrainians, including our team. But thanks to great processes and motivated people who love what they do, we did not interrupt our work. Our clients were actually amazed to see how our team completed tasks in the first days of the war, sometimes from bomb shelters.

We all felt that clients and the rest of the team rely on us and continued to work not out of pressure from management, but from our own feeling of responsibility. My teammates say that the stability of our work helped them stay sane in that madness, and was the source of calm and security. All thanks to the great people and culture in the team. 

We hope you will never have to experience what we did with war. But here’s the lesson we learned, and you can benefit from it in any other extraordinary situation. The disaster seemed unrealistic until the very last moment, but we were prepared thanks to: 

• Clear inner and external communications 
• Well-established processes 
• Strong team spirit 

This strong base was not built in one day. But in times of crisis, the investment in a team and processes returned fully. We did not lose a single client or employee and our business keeps scaling despite the war.

Final words

We don’t know how the world will change in the next five years and what challenges it will bring to businesses. But we are sure that transparent and frequent communication, as well as strong leadership and positive team culture, will help distributed design teams to overcome any challenges. 

Manage your distributed team with confidence, invest in your people and their well-being and it will result in outstanding design productivity and portfolio. And if you are looking for a skilled design team that works remotely around the world, you came to the right place. Drop us a line and let’s discuss how we can help you. 

‍