You can also view this post on Medium.
There’s a moment when you hit a wall as a designer and realize that your design can only make so much of an impact. You have to look at the way you work with the people in your team, many of whom are not designers. You have to examine your process.
I asked at UXSG Meetup #22, “What is your team’s UX process? How does it fit with your Agile development Process?”
“It’s a people problem,” one scrum master sums it up. We exchanged stories about problems working in multidisciplinary teams: developers who are skeptical of design decisions, stakeholders who think of UX as the icing on the cake, etc.
It helps when you have T-shaped people — developers who understand design, designers who know business, product owners with technical know-how, for example. In an ideal world, we would all have a good product manager who can smooth out communication and streamline design and development. In any case, we can all benefit from analyzing and refining our collaborative process.
I have a conceptual model from my research on various design and development processes. It’s a patchwork of human-centered design, scrum, this and that UX model — and I’m trying to understand how they fit with each other.
One way I try to make sense of it all is to see them through the lens of deliverables. I’ll use a simplified selection for illustration.
- The product owner has a vision and business constraints.
- The designer produces user research findings, user personas, journey maps, prototypes, the information architecture and wireframes.
- The developer needs a list of requirements.
Finally, there’s the product and sprint backlogs, which ties in the business, design and development aspects of the project.
A good process allows us to understand the problem, identify constraints, and generate an abundance of ideas before narrowing down on the best ones through reiterative prototyping. When we think about these deliverables in terms of their dependencies, we begin to see a kind of flow.
- The product vision and business constraints sets the focus of the user research.
- User research allows us to identify user needs and contexts which help us form our user personas.
- The user personas frame the way we design and how we discuss design.
- Journey maps, storyboards and other design aids give focus to design work, brainstorming and discussion.
- The product backlog is a list of epics and user stories, which are generated from our research and brainstorming sessions. The user personas and other design aids help us prioritize our stories.
- At this point, the user stories are still abstract enough to allow for different solutions. We can prototype and test ideas to find out what works.
- High level wireframes show how different features work together in a single product. We also design the information architecture.
- The sprint backlog contains a prioritized list of requirements based on the prototypes and wireframes.
The process is seemingly linear but there’s actually a fair amount of going back and forth. For example, before conducting my user interviews, I would draft user persona sketches based on data analytics and user feedback. I can then screen for suitable participants based on these initial user segments. The user research can then be used to refine the user personas.
There’s a gap between the UX deliverables and the product backlog. The user stories we create from our user research goes into the product backlog with no meaningful structure. By using a story map, we can group the stories by epics and map out any dependencies. This helps us convey a meaningful narrative to the team which helps us do better prioritization.
Two great articles I’ve come across in my research:
The story map, created by Jeff Paton, bridges UX and the agile process. See also It’s All in How You Slice to learn how to prioritize user stories in your story map.
This post does a great job of describing different roles in an UX team. It details how we can evolve the scrum model to include UX sprints.
How does your team structure work between designers and developers? What methods do you practice to improve team communication?
Do you have a particular method of translating UX research into user stories for your product backlog? Are there parts of the agile process where it’s challenging for your team to integrate the UX process?
(Thanks to Soh Ping Ting for her advice and pointing me to some great resources.)