In our previous blog post, we talked about the first 2 days of the design sprint. In this post we will be discussing the latter half of the design sprint, and conclude by sharing what we achieved.
The third day of the DS is focused on voting and decision-making.
All of the final sketches that were turned in were pinned up on the wall in an empty meeting room. The voting process was the same as described in the sketching session. Team members silently examined the sketches and placed small circle stickers near the portions they liked.
When the voting was over, we invited our deciders, our designer, and one of our recruiters to select the designs that would make it to prototyping. We tried presenting portions of some of the sketches, but it became evident that too many pain points were being targeted with these sketches. Even when we limited our goal to solving the scheduling pain point, our scope was too big. Most of the ideas presented were unreasonable to deliver given our deadline.
The session quickly pivoted to asking ourselves, what can we reasonably deliver by our deadline? What is the main pain point that we can solve? And what is our minimum viable product? By the end of the session, we came to a final decision – the scope of our project was no longer solving the scheduling pain point for all scenarios and parties involved. Instead, the scope became solving the candidate scheduling pain point specifically for campus recruitment.
This is the part in which we deviated from the standard DS process in a significant way. We decided to hold another sketching session. This time, we had our designer with us. With our designer guiding us, we began sketching as a group. We walked through the happy paths of our user types in the space of our new scope: recruiter and candidate. We made sure to stick to conversations within our constraints, any conversations outside of our scope’s happy path were quickly parked. The session ended with two completed flows, one for each user type.
The fourth day of the DS is when the group works together to create the prototype.
We did not create the prototype as a group. Instead, we used the time that was meant for prototyping to complete the second round of sketching described above. Our designer then took away the sketches we made as a group and worked on the prototype and sent us the first version for review before the user interviews. Ultimately, we depended on our designer’s judgement and experience to make the final design decisions for the prototype. The user interviews will show that this decision led to a great first design.
The fifth and final day of the DS is set aside for user interviews.
We scheduled two interviews for each user type: two recruiters, and two campus candidates. For the interviews, we had one of our developers in the room walking the user through the prototype. The rest of the team watched through a screen share and took notes about important insights. These interviews turned out to be extremely fruitful. We were able to uncover many relevant insights.
The user interviews were a flawless success, which is DS lingo meaning our design proved itself well done with a few holes that need patching. The interviews also left us with a sense of assurance that we were solving a problem that indeed was a pain point for both user types. Our designer ended up using insights from the user interviews to patch the holes in the designs.
Here are examples of two insights that were brought up in both interviews for each user type:
- Candidate user types: In the interviews, participants commented that one of our pages had too much information jumbled up together. They wanted different sections to be clearly distinguishable from one another.
- Recruiter user types: In the interviews, participants asked if there could be a way to indicate lunch hours.
The photos below show the before and after designs resulting from the interview insights:
|Role||Before Feedback||After Feedback|
The design sprint: What we achieved
While we had many wins from using the DS process, there are three major successes that are most important to share.
First, the requirements have become much clearer. We’re still discussing minor details, but the fundamental problem we are trying to solve and the minimum viable product (MVP) we are building are no longer ambiguous. Second, we received constructive feedback from our end users early. Feedback like page layout preferences or suggestions for missing key features. Before even a single line of code was written and we have in our hands priceless reviews from our users. Third, we have a proof of concept prototype ready. We can start development with confidence that what we are building is useful to our end users because they have told us so.
As you ponder these successes above, keep in mind that the combined effort of the DS works out to about a week.
Problems and Recommendations
While the DS had a lot of successes, there were quite a few challenges and learning opportunities we ran into along the way. We have compiled a list of the problems we had with implementing the DS process and some of our recommendations for future design sprints. Check it out:
|Debate over features took up a lot of time in meetings because the MVP wasn't clearly defined.||Explain clearly and concisely the MVP before design discussions. Update MVP goal with the team as the requirements change.|
|Team members often felt they did not understand the procedure or rationale behind the portion of the DS they were participating in. This was mostly felt for the sketching and voting portions.||Organize a session dedicated to helping members understand the DS process, make sure everyone can explain the what and the why for each step of the DS process.
Outline any prerequisites that need to be done before each session of the DS (like a refresher of the user journeys for the sketching portion, or watching the Google Design Sprint videos). Have examples of what you are expecting from the designs/sketches.
|Only developers contributed to the sketching portion of the DS. As a result, we weren't able to address good design practices or new stakeholder requirements we ended up facing later on.||One of many key benefits of doing the workshop components of a DS is that you to compile a list of ideas from multiple viewpoints. Balance the sketching exercise by inviting designers, stakeholders and others to participate as well.|
We want to bring real value to our customers, whether they’re internal customers like our recruiters, or external customers like our cardholders. Bringing real value involves understanding the problem space well and delivering solutions in a timely matter. We want to be confident that these solutions solve a problem that’s relevant to our customer’s needs, and that comes from collecting all the greatest ideas from our diverse pool of associates.
We want design sprints to be used more often at Capital One. They empower us to accomplish all of our goals by abiding by one key idea: “learn early, learn often”.
Ealona Shmoel, Matthew Cabral, Mahtab Sabet, Sarmad Ali