We designed a design process.
We used Design Thinking to design how stakeholders could collaborate in agile. Meta, right?
Roles:
Experience Design / Product Management
THE PROBLEM
Design as a concept and Design Thinking was still pretty new in our portfolio and on our product, so the existing development cycle hadn’t really accounted for how designers fit into the process. We needed something that could work for all stakeholders. My co-designer and I needed to figure out how we could fit the design process into the existing agile development cycle and to collaborate with the traditionally development-oriented mindset of stakeholders.
We began reworking the process to build a more effective one. First, we had to define what our respective roles were. For example, was it the offering manager who was solely responsible for setting up the requirements? What about requirements that come out of technical necessity? What about requirements that may come about from feedback during user research? So that we didn’t have confusion each iteration, we needed to decide which stakeholder was responsible for what, and where there was shared responsibility.
A preliminary sketch of what the end-to-end process would look like.
We needed to determine who was doing what and how our roles would interact with each other.
We then mapped out our as-is scenario, and what fixes we would like to see in our to-be scenario.
From there, we drafted what we believed each iteration would look like. Then we presented our idea to the team.
ROLES
PAIN POINTS
Like we would with any other project, we started with our pain points.
Designers:
We found that we were designing reactively. We were designing features iteration by iteration, with no time or space to take a step back and look at the overall big picture. This was no way to deliver a sound user experience.
We struggled with not having enough time to ideate or time enough to set up and conduct user research for vital feedback.
And we weren’t able to get user feedback before getting feedback from internal stakeholders, which was hugely problematic.
Developers:
Felt like the designs could change at the last minute.
Felt like they had to wait too long for Design to finish before starting coding, wasting valuable coding time.
Often felt surprised at the scope of our designs.
QA Developers:
Felt like they didn’t have enough time complete audits.
Product Management
Needed both Design and Development’s input on requirements simultaneously and ahead of time.
Worried about the immutability of details they saw in our designs
UX Writers:
Felt like they were working on Development’s schedule, so they didn’t have time to look at the overall big picture.
Didn’t feel like they were working step-in-step with Design as they should.
THE PROPOSED SOLUTION
I-1
We set up what we called an i-1 system. Our deliverables would be due one iteration ahead of the development team’s. This way, we had an entire iteration to focus on our work, instead of trying to complete design work in a few days’ time for developers to code within the same iteration. Our work would be set and ready to go when it came time for coding. There wouldn’t be any waiting or any fear of changing details, because all of our research and ideation would have already been completed, and the other stakeholders would have been privy to everything throughout the entire process.
Each iteration we budgeted time to:
Conduct design audits and collect feedback for the previous iteration’s work.
Hold a commit meeting with Product Management and Development in order to confirm which stories we would commit to implementing that iteration.
Conduct research and design and for the next iteration
We created an iteration calendar with the i-1 system and posted it on an easy to access internal wiki so that the team would have something to refer to. With some occasional adjustments, the calendar was quickly accepted by the team and became a valuable resource in our collaboration.
80% / 20% DESIGN
We would first design to 80%. This would include research and informal ad-hoc playbacks with the team. We would conduct a formal playback with all the stakeholders and afterwards design the remaining 20%. We could focus on the overall concept without anyone being distracted by visual details until the final playback near the end of the iteration. Also, there would be no chance of scope creep from the Design team, since all the stakeholders would be involved in the design process and aware from the beginning.
DESIGN ONLY STORIES
We would need to include “design only” stories in our sizing estimates at the beginning of the iteration cycle. This would reduce feeling like we were designing reactively. It allowed us to take a step back and focus on updates holistically as part of a cohesive experience, instead of feature by feature.
STORY HAND-OFF
After a few iterations, we found we needed something more structured than ad-hoc playbacks with the team. Loosely inspired by the "squad" method of application development used at Spotify, I thought that we could follow that example with something I called “story squads”. "Story squads" would be the team of people working on a particular story. At both the start of the iteration and in the middle, the squad would meet to hold a working session where the requirements and aspects of the story were hashed out by the people directly working on them. The idea was tempered with my co-designer’s idea of holding individual hand-offs between the designer and the developer of each story. We implemented the "story hand-off" meetings and it was unanimously positively received by the team.
the RESULT
While there were still some bumps, the process we devised was a definite improvement on the previous one. It cut down on the communication issues we had and made our iterations run more smoothly. It also gave the Design team a little bit of breathing room in order to design holistically. We received a lot of great feedback from our stakeholders, that the new process eased a lot of stress. They felt like they had more time to complete work, even though we were working within the same timeframe because we were using that time more efficiently.
Personally, I would have liked to see how this system worked for several more iterations, to really gauge the efficacy of our solution, and the opportunity to iterate and improve on it more.