A love story between a UX Designer & a PO in the edge of Scrum
This is a true story based on my own experience, working in a scrum environment.
Once upon a time, a UX designer joined an international company to work on inhouse apps, where she met a product owner sitting next to her. Ever since everything has changed for both of them. A complicated love story, full of passion, enthusiasm, ups, and downs was born.
How they are going to find compromises, make success stories, and create a productive work environment? This is what you are going to discover during this story.
But before we start let me introduce you to the main characters.
Who are our main characters?
Myself, the UX designer: My mission is to understand the user’s needs, intuition, and expectations. I created the user experience of the application based on that understanding.
My lover, the Product Owner: is the one in charge of the product roadmap, priority features, and planning sprints. He is the translator between two completely different worlds: the developers’ team that focuses on technical development and the client that expressed the need in the first place.
The Stakeholders: sometimes it is the client, the business partner, or the decision-maker: usually the one paying for it.
Where this story took place
In the wonderland of the scrum. The famous methodology that shook how the IT world works. The secret of its success is its focus on human value and teamwork mindset rather than technical issues.
Is this story for you?
“If you are a designer who will start a new experience in an agile work environment, or a scrum team member, who is wondering about what to expect from a UX designer who is putting big circular glasses and sitting next to you and you are wondering how you can collaborate”
Then yes, this story is made to inspire you and help you achieve better collaboration.
Chapter 1: Never give up
“You can’t just give up on someone because the situation isn’t perfect. Great relationships aren’t great because they have no problems. They’re great because both parts care enough about each other to find a way to make it work.”
What made our story outstanding is the multiple tasks that we had in common and we needed to work on together, such as benchmarking, user interviews… Which made it hard for us to figure out everyone’s limit.
Where should we work together and where should we stop?
This similarity in our tasks created conflicts and misunderstanding. That is why we had to work on our relationship and build a strong work process.
After a long road full of failure, crying and heartbreak, I concluded that it is a learning process; where you fail only when you stop trying. One of the most effective solutions I figured out, is to build good communication for the UX process applied in the scrum environment.
The diagram below presents an example of the process that combines both, the double UX diagram process and scrum events. It starts from the reception of the client’s needs until delivering the solution on prod.
Chapter 2: the beginning
“The best way to get a project done faster is to start sooner.” — Jim Highsmith
The adventure of developing a new feature usually starts with a client sending specifications to the PO or the product manager (depending on the organization).
A common mistake that the PO did, was ignoring me by making his research, starting the wireframe, and sending me a notice to prepare the mock-ups, only a few days before the sprint starts.
Also, it was so hard for me to collaborate when he only shared a briefing of the project that misses the minimum of essential information. For example, a clear description of the need received, the vision, target user, deadline, and sprint start date, information based on real data of tracking software.
Although I was frustrated by his behaviour, I knew it was not intentional and that’s why I had to stand up and make things clear between us since the beginning.
Design culture: As it was the first experience for the team to collaborate with a UX Designer. I had to Implement a solid design culture, raise awareness about my role and the added value that I can bring to the project. They ended up convinced that:
As soon as the UX Designer starts the user research the better his delivery can be.
Chapter 3: the UX work process
“The best way to predict the future is to create it” -Abraham lincoln
They often think that my role consists of delivering sexy mock-ups. I wish it was that easy!
During this project’s phase, which consists of creating an application adapted to the users’ needs and client recommendations, I will follow the double diamond UX process composed of 4 steps; discover, define, build, and validate.
During this process, the PO and myself are supposed to collaborate on several steps. The main issue is that sometimes everyone has a different approach of work which created some conflict of interest and slowed the evolution of our project.
I couldn’t let this problem stop us. I had to dig deep and make a lot of effort to find a solution to establish harmony in our collaboration.
You cannot clap with one hand: the way the designer and PO lead those events is different and lead to different outputs. Example: UX focus on the user needs when PO tends to focus on functionality.
Although it can be confusing in many cases, both of us had to find compromises to be complementary and support each other. The best way to start resolving these issues is getting to understand each other’s tasks and role.
Research plan: At the beginning of each new feature’s development, we prepare a UX plan with the list of all required steps and the estimated time. A very efficient solution that allows providing visibility, on-time delivery and avoids any confusion between us.
Unconvinced client: During the collaboration with the client, I usually take the role of a user advocate. Although I try to build a good relationship with the stakeholders and gain their trust, I always need the PO’s support when it comes to difficult clients. That is why I always make sure that we are always aligned on the same project’s vision.
Chapter 4: the development sprint
“Keep Calm and Start Coding”
Even if he always wanted me to be by his side. My PO was wondering to which scrum ceremonies he should expect me to assist.
In my opinion, my presence is not mandatory in all events, I only attend when I have something to present to the team: Sprint planning, daily scrum, and sprint review.
When it comes to presenting and explaining the mock-ups, the advice that I can give is that you always need to consider what are the developer’s capability and capacity for the upcoming sprint, to adjust the mock-ups according to the developers’ recommendations and to defend the users’ needs and expectations.
Chapter 5: end of our story
Agile Scrum methodology changed how our relationship works. We always have ups and downs, but what I love most about him: his good communication skills, sense of humour, and his solution-driven mindset. That brought more fun and fewer difficulties in our daily life at work.
The project is still in progress. We will keep experimenting, failing, and learning every day. We will be glad if you share with us your stories and let us get inspired by your experiences.
