Looking for something?

How We Used a Design Sprint to Reimagine Our Chartering Process

We're very excited to share a recap from our Lead Designer this week of the Design Sprint process he introduced to the team in January in hopes to expedite our product design cycle. Some amazing things came out of this three-day process and we're hoping to roll those out all our users very soon! You can check out a bit more about the sprint process here.


I had the opportunity to travel down to Austin, TX to attend a workshop put on by Jake Knapp, formerly of Google Ventures. Jake had been traveling the world doing workshops training people to utilize the sprint method that he wrote about in his book 'Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days'. The sprint method is a five-day divergent thinking process that allows a diverse group to tackle a large scale problem in a few days, and ultimately test your solution with real users.

After the workshop, I wanted to take what I learned down in Austin back to Skedaddle as a new way to take on product updates and new features. The first thing we wanted to tackle with the sprint process was the ability for our users to book a private, charter bus on our web platform. We hadn't given our private route product the necessary attention for quite a while, so it was time to re-examine it.

I prepared a team from across the company including; the Chief Product Officer, who also happened to be the decider in our sprint, the CSO, an engineer, two marketing associates, an operators manager and another designer. I was going to fill the facilitator role. I felt prepared for this — I had been living and breathing sprint material for the past month or so.


We convened on Wednesday morning of a short week, prepared with snacks and the largest table in our office that was still not quite large enough for our needs. With our team ready to go and time already ticking, we decided on our goal for the sprint. To accompany our goal we developed multiple sprint questions which are questions we continuously ask ourselves in order to make sure our goal has been achieved:

Goal: To allow our users to simply and confidently book a bus

  1. Will users be confident we understand their needs?
  2. How do we convey our expertise?
  3. Will users trust us?
  4. Will users be overwhelmed?

One of our whiteboards was completely devoted to our goal and sprint questions so they stayed top of mind for the entirety of the sprint.

In a condensed three day sprint, day one was exhausting because there were a lot of big questions about the workflow needed to be answered. We set our goal and sprint questions and moved into interviews with 'experts'. These experts were our CEO, our CTO, and our Customer Experience Manager; people and viewpoints we couldn’t get on our sprint team, but couldn’t afford to leave out because of how valuable their insights are.

While the interviews were taking place our team was acting as investigators trying to get at the heart of our goals and sprint questions. We did this using the framework of 'how might we' questions. 'How might we' is a bit awkward the first time you use it, but it frames problems and questions in an optimistic fashion that leads to favorable new discussion paths. If our CTO says that we can't provide step by step driving instructions for buses, we could phrase that as 'How might we give a better sense of direction?’.

Once we finished our interviews, we took our 'how might we' notes and posted them all over the walls of the conference room. Then we looked for commonalities and utilized affinity mapping to figure out where our big opportunities were.

All of us looking for trends in our "how might we" questions.

Probably the biggest undertaking during day one of any sprint is mapping out the current product workflow from start to finish. We followed our users' journey from their first interaction with our platform all the way to them eventually booking a route. We identified multiple, unnecessary feedback loops between our users and our Customer Experience team regarding everything from finalizing trip itineraries to setting up a Skedaddle account.

This was all still on Wednesday! We spent our last hour researching patterns and features of other websites that we thought could inspire some of our sketching exercises for day two. The thing about sprints I really really love is the prevalence of divergent thinking. We avoid brainstorming in this process; we think and write by ourselves in a group, post our thoughts and solutions to the wall and then let people silently go around and vote on what solutions they like the most. This allowed the best ideas to shine through without bias and allowed us to solve a problem in only three days.

Here you can see our current product workflow that we built out (all those back and forth arrows are what we wanted to get rid of in this new process) and at the bottom there are some of the other website features we got inspiration from.


To kick off day two we jumped right into sketching. The three main exercises were a loose sketching exercise, crazy 8s and solution sketches. The point of loose sketching was to capture all of our notes and ideas and convert them into sketch form. Once we finished with our loose sketches we moved on to crazy 8s. During crazy 8s, you take one idea and create eight different versions in one-minute continuous segments. Lastly, we each took everything we had and made solution sketches. A solution sketch is where you take your favorite idea from crazy 8s and map it out in its entirety... maybe not quite in entirety, but enough such that people walking around the room can read your sketch and understand what you are attempting to accomplish.

We spent 90 minutes working individually creating our scene, took a quick break to clear our heads, and posted them on the walls for the team to vote on. Voting happened in two phases. The team posts small blue dot stickers to represent anything the group finds interesting. Do you like a graph? Blue dot. Like a navigation style? Blue dot. Love an idea overall? 5 blue dots, 20 blue dots- all of the blue dots you believe it takes to communicate your love for that idea. These blue dots create a heat map of ideas and elements that the team likes. Then we get to the real meat of the issue. The decider and their more imposing red dot stickers. To prevent arguing and for the purpose of saving time, the decider can choose which solution sketches to move forward with.

You can see blue and red dots on the chosen solution sketches.

We ended up with solution sketches that were very similar in execution. They all broke up our process into granular elements and utilized our institutional knowledge to help our users through booking their bus. With the solution sketches chosen we applied those to the whiteboard and created a storyboard which would be the template for our prototype. While our solution sketches didn't cover every single step of our process they created an outline that allowed us to look at the new process and figure out what was missing and fill in the holes.

We used the elements from the chosen solution sketches on the post-its for most of the storyboard and then filled in pieces we missed to create a logical flow.

The final step on Thursday was creating our prototype. This needed to be convincingly real so that we could get meaningful results during user testing, but not so extensive that we couldn't put it together in about five hours. With the clock ticking I assigned each team member a different role, those being 'the maker' of the prototype, 'the creators' of language/copy, 'the gatherers' of assets for the makers, 'the stitchers' who made sure all the language/copy/information was the same across the prototype, and finally a user interviewer who needed to craft a script for our user testing sessions the next day. We spent the remaining hours on Thursday making sure the prototype was in a good place for the user testing sessions on Friday. I circulated around the room making sure everyone was on task and answering questions where I could.


We started off the final day the same way we had ended the previous, by continuing to work on our prototype. We needed a few hours to put the finishing touches on it, as well as doing a test run to make sure it would function flawlessly when we had actual users we were paying to come in to test. At 11am we took a new employee in our office and had her test the prototype while the rest of us watched and took notes from another room.

One of the elements of the sprint I wish I could have re-done was scheduling our user testing sessions. I booked all 5 of our users in 30-minute increments back to back. There was so little time in between to refresh, organize our notes or accomplish anything of value.

Here we are furiously scribbling notes while we had a user in the other room with notes from previous user testing sessions on the window that we didn't have a chance to organize yet.

After we finished all five of our user testing sessions, we were able to organize and place our notes on our map. Our map was sorted by our original sprint questions to make sure we were standing by our original goals of the sprint. Positive observations were marked in green, opportunities to improve in red:

We did a pretty good job of not overwhelming our users with this new flow, but we definitely had room for improvement in the other categories.


As you can see from our map above we had a lot that worked in our prototype, but we had equally as many opportunities to improve it. The fact that in a three-day span we were able to identify a problem, hone in on that problem, come up with an idea and test that idea was incredibly impactful. Because the prototype tested so well in our user testing session, we wanted to use that as a real base moving forward so I copied the Keynote prototype into Sketch and began to make changes based on the opportunities we identified.

Since writing this I have taken our sprint prototype, made multiple rounds of changes and created a full UX workflow. After conducting our first set of user testing interviews we averaged a score of 9.6/10 with five users. I think that score lends itself favorably towards the sprint process. We had gotten good UX scores in the past during user testing, but the average was typically 8.5/10. The fact that we got a 9.6 meant that all five of our users had only minimal issues. No issues were repeated by multiple users and this was all great news for us.

The sprint format allowed us to come together as a company and do multiple things; decide on what our goal was, form a hypothesis on how to accomplish that goal and ultimately test that hypothesis all in three days. Before we introduced the sprint process that same set of events would have taken weeks at the very least and some issues would probably never be recognized.

For us, at Skedaddle it accomplished something else that was great to see and that is complete buy-in from all departments of the company. I had always tried to make sure that what I was working on was clear to everyone, but facilitating this process allowed everyone to have their voices heard and even more than that allowed everyone to take an active role in developing the product. It really was amazing to see.

I was curious and excited about the sprint process before, but now I truly believe this is something we are going to utilize far more often moving forward.

0 Comments 30 March 2018
Garin Bulger

Garin Bulger

I'm the Lead Designer here at Skedaddle. I also like to run around, play/watch basketball and put cool stuff on my feet.

Related Post

Comments powered by Disqus