Even at a company as committed to human-centered design and healthy UX practices as Raft, running Design Sprints among Agile evangelists can be a daunting task. The tension between Agile and UX has a long documentation history, and I have no added value to that conversation right now, only to acknowledge the challenges are real and many. So, in addition to this design challenge, we were running a meta-challenge for Raft.
How Might We
- Model a Design Sprint that delivers a technically feasible MVP in six days?
- Experiment with Expanded Cross-Functionality?
These ideas guided us along the way
1. Agile principles do not lie in rituals and rules.
2. To be Agile, we must remain nimble and adapt to what projects demand.
3. It is evident that HCD and healthy UX practices are in demand in almost every project.
4. Design Sprint collaboration must be owned cross-functionally. No silos.
A preface: “Design Sprint” is confusing. The word “design” evokes images of people in nerd glasses and skinny jeans swooning over Helvetica, palettes, and obsessing over pixels. The term “sprint” evokes images of high-velocity software development, rapid iterating code, stand-ups, reviews, and finely accounted for time and progress. When these two stereotypes collide, you can meet with a combination of anxiety and dread. To add to this: even the most cross-functional environments still rely on silos to get things done. Like adjusting to new time zones and languages after a trans-oceanic plane trip, it takes time to decompress from organizational silos and hierarchies. I will return to this at the end of this post to deliver some learnings gleaned from our decompression process.
For us, these equations are necessary.
Let "Design" = thinking strategically about harmony within complex systems.
Let "Sprint" = moving iteratively through a rapid cycle of discovery and ideation.
Our roadmap reflected Raft’s design thinking process: empathize, define, ideate, prototype, and test.
Some unusual conditions in this sprint are worth noting. We had an internal product manager act as a PO. The product was well-scoped for us as the product owner had conducted a thorough discovery process before our invitation. Conversely, we arranged for volunteer users throughout, which we leveraged maximally, involving users in ideation and validation all the way throughout.
The Itinerary
Day 1 to early Day 2: Defining
We conducted a timeboxed secondary research lit review, a problem framing workshop, and iterated personas and a journey map, laid out a research plan, and validated our sprint plan. In our research plan was an artifact inventory. Artifacts are essential to our process, not only for documentation in visual terms but for having concrete deliverables that allow us to design cumulatively, which is to say, to build from one day to the next. In our sprint plan, we listed an artifact inventory that would be the measurable outcomes for each step of our collaboration. Usually, we start with empathizing so that we can understand the problem space. We pivoted from this plan because the compressed time frame, well-scoped challenge, and initial discovery meant that we could use day one differently. We chose to use it to define and scope our empathizing, so we focused on the things most essential to the experience we wanted to deliver for our users.
Day 2: Empathizing
On Day 2, we started empathizing with our users in a collaborative workshop. In a more drawn-out process, we would move from 1:1 interviews and ethnographic studies to workshops. In this sprint context, we combined the two in one Collaborative Design Workshop. We gathered insights and affinity mapped in part one. We validated our journey map and personas with the users from that work. In the second half of the workshop, the facilitator, lead designer, and lead researcher solicited our users’ participation in developing an initial user-flow. To be clear, readers, on what was key to this project: we empowered the users to design the user flow themselves. We did this before stakeholder input. At this point, our tech lead began diagramming data maps and state maps as a guide on technical feasibility and as a way of stimulating a high-level software design process to precede coding. Their participation was critical in instituting an early state cross-functional dialogue that could infuse the development process.
Day 3: Ideation and Testing
Our creative team spent almost a full day on wireframe ideation with three designers developing multiple iterations on our validated user flows. The end of this process was a user workshop that selected our best ideas from a batch to refine them to a prototype for testing. We used both qualitative and quantitative testing and discussion to select.
Day 4: Prototyping and Testing
The team then began prototyping in Figma and came up with a clickable prototype for testing with users. We ran testing, identified areas for refinement and improvement, and left with strong direction on our final prototype.
Day 5: Refinement and Final Testing
On Day 5, we prioritized refinements and ran accessibility tests. We ran a final user test for feedback and minor improvements and set about the process of creating an annotated delivery of all artifacts and wireframes. Our annotations included a design rationale, service blueprint notes, and areas we identified for further testing and UX improvements.
Day 6: Delivery
On Day 6, we performed a Demo of our process and our clickable prototype, an annotated artifact review, our design rationale, and recommended next steps for building. We also performed a retro on our process to distill learnings which we list here.
Learnings for Continuous Improvement
-
We cannot rely on a tacit understanding of roles in a Design Sprint.
We need to do a much better job defining Facilitator and Decision Maker and who becomes the Decision Maker in various conditions. Some conditions require the Decision Maker position to rotate. -
Approach each sprint with a Beginner’s Mind.
Beginner’s mind requires an orientation pre-sprint in which the team defines roles and ground rules not generically but specific to the conditions of this particular sprint. Among those conditions are each team member’s time commitment, decision goalposts, and specific responsibilities concordant with authority. -
Once we scope the project, post the parameters of the problem space visually on each whiteboard.
One mistake we made was to assume that the problem-solving workshop had adequately aligned us. When conflicts arose, we needed to leave our current board and return to that one. In the future, we’d begin each section with a reminder of the scope and the goals of the project and post it visibly, with easy access. -
Keep Developers in the room.
The tech lead needs to be a part of every step of the process and produce parallel artifacts and diagrams. We provided a somewhat parallel state map along with our artifacts, but we believe this process can go much further and are excited to continue developing that model. We had several epiphany moments and look forward to our next discovery or design sprint. -
Conduct a brief refresher course in giving and receiving input and feedback.
This is critical. We failed to do this, and it caused unnecessary frictions and miscommunication that slowed our process down. While we still delivered what we consider an outstanding product, we realize that had these frictions not bled time and energy from the process, we could have achieved even more.
Consequently, we are already planning and look forward to more design, discovery, and service sprints with our collaborative partners. Continuous improvement is what gets us out of bed in the morning at Raft, where learning is constant.
