Handoff headaches: Creating design processes that sync up with agile development
There is no one correct way to do it.
It takes communication and collaboration
When it comes to marrying UX practices with agile product development, there is no one-size-fits-all approach. Agile methodologies are development-centric, requiring UX designers to adapt their toolset to their team’s work patterns in a way that will deliver value without slowing velocity.
One common way to mold user experience practices to agile development is by completing design work on a cadence. By establishing a recurring, predictable set of design activities you can better align your work as a designer to the work your team’s engineers are completing.
Designing a sprint ahead
When your team’s work is organized into sprints, it provides a natural framework and timeline to align UX deliverables with. If you thrive on predictability and organization, working this way may work for you and help bring some order to the chaos that product development can be.
Pro: a smooth handoff with development
The biggest benefit to working this way is a tighter alignment between design and engineering streamlining the dev handoff process. By working only a sprint or two ahead, designers can spend time working on stories that have a very high probability of getting implemented soon.
Cons: the risks of designing too far ahead
To complete work aligned with development sprints and ensure a smooth handoff, you need to align with your product manager on what stories are anticipated to be in the coming sprints. Doing so requires a degree of organization and foresight your team may not have.
Depending on how your team works, how volatile your roadmap is, and the maturity of your product, you may not feel comfortable dedicating work to stories that aren’t written or may not be a priority in the next sprint or two.
This can also be a challenge when seeking user engagement for feedback or other research. If you can’t align user availability with your sprint-based work, you will have to decide how to proceed and risk creating design debt with unvalidated design work.
Weekly design sprints
If your team doesn’t work in sprints, or if you simply don’t want to be bound by development cycles, you might try working in a cadence based off of what’s on the roadmap for research and design. By creating a repeating cadence, you can bring some order without being tied directly to the immediate user stories being engineered.
On one team I was a part of, we experimented working in a modified design sprint every week. Each week, an item was chosen off of the roadmap to ideate solutions for, prototype those solutions, and get user feedback every Friday. Here are some of the pros and cons of working this way.
Pro: Design momentum
Working this way allowed us to build up considerable momentum on design work. By having a consistent weekly approach we were better able to forecast what would get done when and maintain a consistent pace of validated design work.
Con: Too far ahead of engineering
However, the speed and momentum we created pushed us too far ahead of our engineers. This isn’t the worst problem to have, but we saw our prototypes slowly diverge more and more from what was being released to production.
By getting too far ahead we were working with more risk as roadmaps are prone to shift and the design work we were completing had a greater chance of being re-prioritized in the backlog.
Pro: User buy-in
At the beginning of this design sprint experiment, we got a commitment from three of our users to meet with us for 30 minutes each every Friday. Having this dedicated time set aside every week was a huge win for us and enabled us to have predictable user feedback with users who were familiar with our growing app.
This is an advantage to other designers like myself who work on internal software tools. By working in the same building as all of our users, the access we have to them can make it much easier to get recurring time like this.
Con: Stale feedback
The best feedback we got was at the beginning of this process when everything we were working on was new to our users. As time went on, the quality of feedback declined (which is in no way a reflection on our users). We attributed this decline to user fatigue and a varying level of scope in what we were soliciting feedback on.
Pro: Repeatable process for each story or feature
In working this way we were able to essentially perform the same due diligence for each feature or story we ran through this sprint process. This ensured that each item was thoroughly tested and validated before a story was handed off by design to our engineers.
Con: Varying level of scope
We found ourselves having issues determining what features or stories to run through these design sprints. While it was a repeatable process in general, certain elements felt too small or insignificant to devote a full week to designing.
Key takeaways
My team did not keep working as tightly in this sprint framework as we had been. We got too far ahead of engineering, but the momentum it gave us helped jumpstart a greenfield application.
Going forward we will still apply this sprint mentality, but only for larger efforts. While having dedicated time with our users every week made scheduling very easy, we will work to mix in more diverse perspectives going forward to ensure a variety of feedback from fresh eyes.
Take what works for your team and move on
There is no magic bullet when it comes to establishing a regular process and cadence for completing design work. One of the inherent principles of design is always leaving room to be proved wrong, and this should apply to the way we work as well. Constantly revisit the ceremonies, activities, and processes you complete with your team and asses what is working and what isn’t.
