Using UX Research to Learn About Your Team
A framework for asking questions to get up to speed as a new designer on an Agile Scrum team
When I joined the team at FreshBooks a couple months ago, I arrived equipped with lots of questions. I’m a naturally curious person and I was eager to understand how the other designers kept up with our fast-paced sprint schedule.
I wasn’t just working with other designers, though—I’m part of an Agile Scrum team, which includes a product owner, scrum master, developers and QA analysts. This was all new to me, as I had never worked on an Agile team before.
In our first few meetings, I felt like my teammates were speaking a different language. So I put my ethnographic research skills to work to better understand my teammates.
There were some key things I needed to proactively learn to get up to speed with the team. Let’s call these my research objectives:
- Context: Understand what’s worked and what hasn’t in the past working with other designers.
- Objectives: Define our mandate and how it impacts the team.
- Practice: Identify ways I can add value in the team’s day-to-day activities.
Using this framework, here are some questions I asked the team to better understand how I could contribute as a new designer.
What is your previous experience working with designers?
Just like you might ask users to reflect on previous experiences to recall their workflows, I asked my teammates to reflect on previous experiences working with designers. This allowed me to set context for my role on the team.
One developer on my team told me she was concerned about designers getting bogged down in technical jargon in the past.
I could see what she meant—for my first few weeks, I wondered whether I even needed to be in the room in Agile rituals like sprint planning and backlog grooming, given the focus on development work.
But my teammate told me that she wanted designers to be included in those conversations to share learnings from user research and advocate for design considerations.
I learned that my teammates don’t expect me to perfectly understand their development-oriented discussions, but rather, to bring my specific knowledge forward and to learn about technical constraints by being present.
What are we trying to accomplish?
Next, I wanted to understand the why — the spark that keeps the team motivated.
When I started my first project on the team, I dove right in, trying to catch up as fast as I could. But I soon realized that I wasn’t sure of the motivation behind the project—why are we doing this exactly? I needed to understand our business objectives.
By talking to my team and my PO in particular, I started to build my understanding of our mandate, and how the project fit into the broader product vision. Through these conversations, I also learned the value of the mandate for the team, as it provides them with a sense of the importance of their work for our customers.
Being able to connect our objectives to the project helped me to focus my conversations with the team around these goals, so that everyone felt grounded in the “why” behind our designs.
How can I add value to our day-to-day work?
By now, I had gained an understanding of the team’s workflow with designers and the problems they’re trying to solve through some informal desk-side “interviews”. The next step was to start test driving some solutions for how I could bring value to our day-to-day work.
My two key learnings from my initial research were what I outlined above:
- My teammates want the designer to be actively engaged in Agile rituals so that user research insights and design considerations are shared.
- My teammates want to clearly understand the “why” behind our designs so that they can connect their work to the value it brings to FreshBooks.
With these insights, I could start trying out some solutions, like bringing more detailed design updates to daily stand-up and posting a synthesis of our weekly research learnings in our team’s Slack channel.
And conveniently, Agile Scrum has a great feedback mechanism built in through retros, so I’ll be able to collect qualitative data from my teammates to inform iteration on these solutions every two weeks.
Building shared understanding
By applying UX research methods to learn about my team, I empathized with my teammates and discovered that there’s a need for a strong design advocate on an Agile scrum team.
I’m still finding new questions to ask of my team to help me understand how I can best work with them. In turn, I’m often responding to their questions as they build out designs.
Asking questions and finding answers collaboratively builds shared understanding and empathy, the currency of UX that propels Agile teams to work faster and better together.
This post was inspired by Jason Cashdollar’s post on “Questions to ask as a new designer on the team.” Read it!
