When I joined Berkadia, design and research were a new concept. Developers had been asking for insight into user behavior and needs, and help establishing a consistent look and feel across the product interfaces. They were glad we had arrived! But a question I kept hearing from engineering, delivery, and product was, “How do design and research fit into an agile sprint cycle?”
We didn’t know.
First Attempt
In the spirit of testing, my PM and I built a separate design and research backlog and a sprint cycle that would run a little offset to the developers’ cycle. The idea was this:
Research would uncover opportunities and pain points, articulate them clearly, and give data-driven recommendations for solutions, filed neatly in the design backlog.
Product would organize the tickets according to priority based on the product roadmap.
Designers would come in and pull the next project to scope and plan, and when it was done, it would fall neatly into the top of the product backlog so dev could scope and plan too.
Sounded great!
In practicality, nothing is ever that linear. As the researcher, I was both attempting to map current state, advise product on the roadmap future state, and dig into immediate usability questions that were holding development up. The designers were working on implementing some kind of design library across the product so everything was consistent as well as designing the next round of features and updates, and the development team was way ahead of us, asking for help on things we hadn’t had time to get to yet. It felt a lot like this:
Second Attempt
We decided to try embedding the designers in their dedicated scrum team’s sprint and having them split their time between updates and new features. That way, new pieces were being built in the consistent design library style and the rest of the product was being brought up to speed a chunk at a time.
In this scenario, research took a big step back from sprints and backlogs and focused on mapping:
Where is the product currently (in actual state, in user sentiment and engagement, in flows and journey maps)?
Where is the product roadmap headed? Is that in line with business goals and expectations? What about user needs and expectations? Where are the gaps?
What are other teams, companies, industries doing to solve these problems? What can we borrow or learn from or copy?
In light of all this, what should future state look like? What’s the experience vision? Where should we be driving to serve our customers and the business alike?
Outcomes
We were pretty happy with this flow, once everyone got a handle on it (that took maybe four full sprint cycles or eight weeks). We saw research gain a lot of space and time back and start making impressive headway on mapping end-to-end experiences, collaborating across product lines, and winning over user groups. And design and development were able to simultaneously provide consistent releases for the product and contribute significant chunks to the new design system the company was building.
I still think there is room for improvement in our model, and a lot of these decisions depend on your team: how they think, communicate, and prefer to work. But that’s one agile principle I really love: try something, and if it doesn’t work, try another thing. Keep moving. (Just be sure to communicate what’s happening to the team and make sure they’re on board with an experimental couple of months!)
Photo by Braden Collum on Unsplash