XAOP is a creative B2B software solutions company with clients primarily in the life-sciences sector. XAOP’s main asset is that we create custom web applications and tools rather than out-of-the-box solutions for our clients. We’re ready to jump in at any stage of the software creation process, whether the client has just an idea or already has an existing application that they want to improve.

The challenge

For this particular project, one of our clients came to us with the idea of improving the internal process of getting project ideas approved by certain committees within the company. The process is currently too elaborate and time-consuming for nearly all parties involved. Together with the client, we felt that a design Sprint could provide an idea for a solution that could quickly be designed and tested. XAOP was more than happy to run this design Sprint with them as both participant and facilitator.

The setup

Save for a few alterations, we decided to follow the book for running a design Sprint by design Sprint pioneers Jake Knapp, John Zeratsky and Braden Kowitz called Sprint: how to solve big problems and test new ideas in just five days. One of these alterations, for example, was deciding to condense the Sprint to three days instead of five, as outlined in the Sprint book. Also, rather than a tested prototype, our final deliverables would be mockups of the Sprint solution and a blueprint of how we would proceed with implementation after the Sprint. The main reason for these changes was that the concept and mockups were needed to present to a committee within our client’s company before any real prototyping and testing could be done. (Yes, this was in fact exactly the process we were trying to facilitate and speed up.) Naturally, if the solution was accepted, we would continue our design process with prototyping and user testing.

And so, as facilitators, our work started a few weeks before the Sprint in terms of preparation. (For a full list of things to prepare, check out this video by the Google Ventures team.) Our client arranged a suitable venue for the design Sprint while we gathered the needed materials (pens, whiteboard markers, a time timer, paper, etc.). We cleared our schedule, read and reread the chapters from Sprint: how to solve big problems and test new ideas in just five days (a.k.a. the Sprint book) and created a presentation to guide everyone throughout the Sprint. You can find the presentation we created for this design Sprint here: [insert pdf download link].

Our core team consisted of the company’s head of Innovation, the risk and process manager, a business manager, a data analyst, XAOP’s CEO Stijn Van Vreckem and myself as the Facilitator. In order to understand the full extend of the client’s problem, we invited a financial expert, a second risk manager, and one of the committees’ members to join us on Monday and Tuesday. In the Sprint book, the authors recommend a team of about seven people, preferably all experts in their own field pertinent to the business as well as the end product. Counting myself as both designer and Facilitator, we reached that number exactly with our core team. However, due to busy schedules and other obligations, there were a few extra people (including the experts) who came and went throughout the Sprint. This was a disruption to the Sprint flow and, as is also mentioned in the Sprint book, we recommend avoiding this situation if possible. However, by using the slides and the materials we had created during the Sprint, we were able to bring the people who jumped in up to speed relatively easily.

The Sprint

Our venue (OFF) was located in Wavre, to the southeast of Brussels. The venue felt peaceful and luxurious, with sunlight streaming in from all sides and potted plants in every corner. OFF features a number of meeting spaces, each with their own style and character. Our client chose the space just at the front of the building, with a long table in the middle and a couple of flip charts.

Monday

As Stijn and I set up the room on Monday, the other Sprint members chatted amicably over snacks and coffee, getting to know each other. Everyone was feeling positive and excited about the Sprint. We kicked off with the presentation I had prepared that would guide us through the Sprint process. With the help of the presentation, I was able to clearly lay out the next few days and explain the different roles in the team — the normal participants; the Facilitator, who would explain the Sprint and keep everything on track; and the Deciders, who would make the final decisions during the voting. In order to make quick decisions and keep the Sprint going, some parts of the Sprint would require the team to cast votes. The Deciders would each get two Supervotes, votes that would trump all others no matter how many regular votes were already placed.

Everyone was feeling positive and excited about the Sprint.

Monday morning flew by and we made a lot of progress setting the stage by coming up with the Sprint Questions and Long-Term Goals. These would provide a clear path and focus for everyone to keep in mind throughout the Sprint. (For more information about the different stages and terms of the Design Sprint, check out the Sprint book or visit http://www.gv.com/sprint/) As everyone was familiar with the internal process to be redesigned, coming up with key questions and “mapping the challenge” was not that difficult.

The afternoon, however, proved to be a bit more challenging. Aside from the habitual after-lunch lull, the Ask the Experts session went on a bit longer than expected and the concept of How Might We notes proved difficult. Ask the Experts is fairly self-explanatory — we and/or the client invite a number of field experts to answer pertinent questions about their field and possible issues or aspects about the Sprint topic. During these ‘interview’ sessions, everyone is asked to take individual notes. But rather than just summing up a list of bullet points, they’re asked to pose it as a “How might we…” question. For example, if the expert mentions a number of approval rounds needed to approve an idea, the question on the note could be “How might we decrease the number of and time spent on approval rounds?” The idea here is to force Sprint participants to focus on solutions rather than problems. However, this way of note taking proved to be difficult to adopt for nearly everyone – we were asking them to perform two tasks at the same time, both quite unfamiliar to them. On the one hand, they were asked to act as interviewers, almost investigators. On the other hand, they needed to rethink and rephrase every note they took into a “How might we…” question rather than just writing it down. Still, the group managed to generate a lot of notes and questions that were put up on one of the glass displays in the meeting room. Our next step was organising these How Might We notes and voting on the best ones.

We ended Monday with a quick overview of the Lightning Demos scheduled for the next day. For reference, Lightning Demos are a kind of blitz research on existing solutions to draw inspiration from and generate ideas for functionalities, medium, format, etc. We wanted to make sure everyone understood the concept and had some time on Monday evening to do some research beforehand, hopefully saving us some valuable time during the Sprint the next day.

Tuesday

This proved both advantageous and not so on Tuesday morning — though we needed less time to explain the concept behind the Lightning Demos, allowing everyone to do some research beforehand resulted in far too many examples to cover. This resulted in a bit of a backfire in terms of time management. Overall, however, the team managed to cover a lot of different tools and consider functionalities. As everyone presented their research, I drew quick sketches and wireframes of the most interesting functionalities on the board for later reference.

…once everyone got into the process of thinking, drawing and doodling, the room went quiet save for the sound of pen scratches and concentration.

Tuesday afternoon covered one of the most creative and fun parts of the Sprint - Sketching. Everyone in the room had all of Tuesday afternoon to sketch their ideas for a solution based on everything we had discussed and all the materials that were up in the meeting room — the Sprint Questions, Long-term Goals, the How-Might-We notes, etc. As we handed out the papers and pens, sceptical glances were thrown around the room by those who considered themselves non-creative (which was nearly everyone in the Sprint) and there was some muttering of protest in the beginning. But once everyone got into the process of thinking, drawing and doodling, the room went quiet save for the sound of pen scratches and concentration. Keeping the sketches as private as possible before the decision process on Wednesday morning proved to be an excellent way to prevent possible bias.

Tuesday afternoon gave us a lot of good, viable ideas from everyone in the room. Everyone had a chance to illustrate their vision of the solution and the functionalities they felt were most important. Having this many possible solutions also posed a problem, of course. How would we choose the best one and which specific functionalities?

Wednesday

This is where the decision process and the Deciders played a key role on Wednesday morning by using the Sticky Decision method. This is a five-step process where

• all of the solutions are put up on the wall
• everyone goes around the room and looks at all the solutions in silence, using dot stickers to mark interesting parts
• the Facilitator narrates each sketch to the group; the highlights are discussed and written down on sticky notes placed on the sketches
• each person votes on their preferred solutions in silence with a dot sticker and then explains why they chose that solution
• the Deciders cast the final vote by considering all the solutions, highlights and group votes and placing their Supervotes

Since we had two Deciders instead of just one, we also ended up with more than one final solution. Ordinarily, this would mean a possible Rumble — pitting the solutions up against each other. However, we found that the solutions ultimately chosen could be merged perfectly into one master solution.

Our final step together as a team was drafting the Storyboard on Wednesday afternoon. Using sticky notes, we laid out the part of the process we wanted to focus on and ultimately turn into wireframes and mockups. Then, through discussing and combining the final sketches and functionalities, I sketched out the process in rough wireframes so I’d already have a head-start for drawing out the final designs.

Lessons learned:

• Some parts of the Sprint might have worked better with some concrete examples already set up, like for the How-Might-We notes. Also, placing a limit on the number of HMW-notes people want to put up might reduce the time spent organising them later.
• Keeping everyone in check and within the given time frames proved more challenging than expected. Here again, it’s up to the Facilitator to not be afraid to maintain control of the process and jump in when necessary.
• Being the busy business men and women that they are, getting everyone to stay off their phone during the Sprint proved a bit challenging the first day. As Facilitator, you sometimes need to be assertive and firm (while remaining polite, of course) about this rule to really get the point across.
• Though not running the full five days may have been lighter on everyone’s schedule, it proved to be a much greater challenge for the designer later on to come up with the design solutions. Not having the team and experts there to ask questions and provide valuable input was a big disadvantage.
• The Sketching on Tuesday went a lot better than we had anticipated. Though everyone was a bit reluctant in the beginning, they really enjoyed themselves once they got into getting their ideas onto the page. Eventually, they didn’t even care so much about their drawing skills (or their perceived lack thereof) anymore.
• The slides I had prepared proved to be extremely useful. Since my laptop was the only one allowed in use during the Sprint (except during the Lightning Demos), we were able to use the slides as constant reference and reminder.

Conclusion

Overall, it was a very enjoyable and valuable experience, both for our client and for ourselves. At the very least, everyone got a break from their regular work routine. We learned a lot about our client, the project and what it takes to run a Design Sprint. We’re already looking forward to the next one, where we’ll (hopefully) be able to run the full Sprint.

A special thanks to Jake Knapp, John Zeratsky and Braden Kowitz for writing the Sprint book and providing us with such a rich tool for running our own Design Sprint. And, of course, to our client, who gave us the trust and opportunity to run this Sprint with them.