Product designers in scrum teams — Part 1
A full guide on how product designers should work in a scrum team.
We can easily find resources about the design process and scrum framework. Unfortunately, none of them tells us how the design process fits in scrum framework.
The insights I am sharing might not be the best interpretation of scrum, but the handiest guides for designers who work in a scrum team.
Goal-Oriented Mindset
For a while, I’m obsessed with different process and tools, including names we always heard of, agile, lean, jira, invision etc.
In the end, they were not making my job easier. On the contrary, they got my hands tied. I realized that I forgot what I wanted to achieve in the first place.
Therefore, it’s always good to try things out as a starting point, but remember, everything should eventually work for our goals. Find out what we want to achieve before getting hands dirty. We can definitely hand pick the parts that work the best for our goals.
In this case, my goal is to create a workflow that increases the efficiency of me and the whole team.
Product Design as a Translator
Efficiency means we create the most value with the least cost. What is the value product designers create in scrum teams?
From my experience, product designers are translators. It means we:
- Translate users’ desires and pains for product owners. Product owners might be considering different aspects when defining how a product should be. Our job is to speak of users about how they want it to be.
- Translate features for our users. It means we create experiences and interfaces that users could use after development. In a word, how it actually works and what it looks like?
- Translate experiences and interfaces for engineers. We define UX requirements and UI specification for engineers to align the product increments with our expectations, from expected behavior, to the pixels of padding.
As we can see, it’s always about users. We are the voice of them.
The Quick Answer
As we talked about, there are 3 different parts of our job. So what do we actually do in each sprint?
I would like to divide my job into the below 3 parts:
- 10% Clarify requirements of stories in the current sprint
- 40% Define requirements of stories in the next sprint
- 50% Validate features for a longer-term future
The focus of product designers during a sprint is different from engineers.
Engineers focus on the current sprint goal. Product designers take care of the current sprint, the next sprint, and the longer-term future.
There are 2 reasons why we need to look forward more:
- Engineers are impossible to start working without details of requirements and assets.
- We can validate the direction before investing huge development cost.
If you ask me, are product designers still part of the dev team in this case? I would still say yes, because we are contributing to the current sprint goal as well.
Eco System of the Team
Last but not the least, each team has a unique eco system, affecting by countless.
I’ve worked in several scrum teams. In Team A, I join all daily stand ups. In Team B, I am not joining any. This variation is caused by the team project nature.
Team A works on one front-end product. Knowing what’s coming next helps with the system design. And more guidance about UX and UI is needed.
Team B is set up like a guerrilla. The sprint goals have could be totally independent and are more back-end related. The team does not need to know what happens next and my contributions are limited.
Each of the team will have a unique goal, and a unique way to achieve the goal. Don’t be afraid of breaking the bible as long as it meets the goal.
Take Away
- Define a goal before any move.
- Designers are translators. We speak for users.
- Focus on not only the current sprint, but also the future.
- Adjust the workflow according to the team’s eco system.
Next: Cheatsheet
In the next article, I will share a cheatsheet of full run down of my process.
I’ll start from the goals of each step, to some personal recommendations of tools I found helpful.
