Skedaddle: Allowing our users to confidently and simply book a bus

This is a story about a GV style design sprint. If you’ve never heard of that, you can learn more here or read the book.

I have been leading design at Skedaddle for the better part of the last three years. Our goal as a company is to create an on-demand public bus transportation network that can take users from their neighborhood to anywhere. That is where we see our company’s future.

We also have another product line with a goal of revolutionizing the way people book buses for private events. No biggie, right? Think about typical charter bus companies; you call in, want to pull your hair out within 5 minutes and curse loudly in a room by yourself out of frustration. That process really hasn’t changed in the past 50 years. Our goal was to utilize the sprint process to rethink how we treated this product.

And a twist to this sprint. We did it in only 3 days.

Why were we doing the sprint? What did we want to accomplish?

Our long term goal, sprint questions and parts of our user journey we ended up changing

Skedaddle had been around for almost three years, and we were finally at a point to be able to put in more time and resources into helping people organize group transportation. With that ability, we needed to figure out where to start.

Because of that, our goal was simple. ‘To allow our users to confidently and simply book a bus’. This focused the scope of the project and got at the heart of our issue. With that goal, we listed out 4 sprint questions to further focus our goal.

  • Will users be confident we understand their needs?
  • How do we convey our expertise?
  • Will users trust us?
  • Will users be overwhelmed?

We believed that if we answered those four questions, we would be successful in our goal.

Who was on the Skedaddle super team?

On our Sprint Team I made sure to grab people from almost every department at Skedaddle. We had:

  • CSO of Skedaddle, Brad Werntz
  • CPO & Decider, Craig Nestler
  • Me as the Lead Designer and Facilitator, Garin Bulger
  • Back End Engineer, Greta Moserson
  • Product Designer, Dawnie Ngo
  • Operations Manager, Avery Kepple
  • 2 Community Engagement Managers, Kailee McArdle & Clint Ross
Ignore all the dour looks, I tend to just snap the photo without notice

How did you decide which problem to solve?

With us spending as much time in the problem space day one of our sprint as we did, we identified many problem areas that were worthy of their own solutions. Whether that was getting users signed up, how they find out about us in the first place or even the difference between our two product lines and how we communicate that. But it was clear to us that addressing this process of allowing our users to simply and confidently book buses needed attention.

After we had gone through our user journey, we as a team couldn’t agree on a specific area to target. There were three areas that we were divided on, and only after getting through solution sketches that in dawned on us that we were all working on addressing the same issue in three different ways.

The team examining solution sketches directing us to a singular place to lend our efforts
Our chosen solution sketches

Making our prototype in Keynote was a cinch.

Our multi step prototype for reserving bus trips online

With the end of day two of our three day sprint winding down, we had put the finishing touches on our storyboard and I assigned roles for our prototype. We only had realistically 4–5 hours of working time to create a passable process for booking a bus that solved our users issues.

With that timing in mind, we turned to Keynote to execute our prototype. We needed to include enough clarity that our users would understand our intent, while avoiding the pixel-pushing that you get in Sketch. We created a 17 frame process that took a user from getting an email introducing them to Skedaddle, take them through the appropriate forms, and ultimately ending with them reserving a bus.

We tested with 5 people after 2 days and found clear patterns in their responses

Half way through our tests we were already seeing clear patterns arise in how users were dealing with our prototype. We were successfully conveying our expertise by recommending pickup times and buses appropriate to their groups. We are also centering all of our copy around the user opposed to the bus trip. We were accomplishing some of our goals already, while revealing a clear path forward on the others.

Of course we had plenty of things that popped up from our users. They wanted to know more details about how their total cost was being split up between taxes, if tips were included, etc. What were the next steps once the bus had been booked? Could we provide further services to the user, such as providing groups with coffee or balloons if their needs were there? These are questions that we possibly never would have uncovered, or if we did it could have been weeks or months down the line. With the sprint process, all of this was discovered in a three day span and was addressed.

The team taking notes during a user testing session happening across our office
A sly picture of our user testing session going on
Our user testing notes being sorted by common themes before being placed on the whiteboard
Our final map with our original sprint questions and how our users behavior fell into them

Next steps for Skedaddle

We had wrapped up the sprint after 3 days. Since then, I have been working to take the prototype we had put together and get it into the development teams hands fully flushed out.

As of writing this, I’ve translated our sprint prototype into UX wires for both desktop web and mobile web use. I recently finished the first round of user testing for both of them, achieving higher scores from those users than any previous product update.

Sketch file for our mobile web UX which got an average score of 9.6 in user testing
Sketch file overview for mobile web UI, which got scores of 8.0 for simplicity and 8.4 for confidence in process

Did you make any modifications to the process?

I made one major modification and that was to reduce the time to three days. It was one made out of desperation, we are a company of only about 23 and taking eight employees for anything more would have been much more difficult.

However, three days did present a lot of problems. We had to cut time off of a lot of different exercises and move things around just to be able to fit the core of the process in. The biggest issues arose on the end of day two when we had to put in extra hours while creating the prototype, and the end of day three where we needed extra time to sort our notes from our user testing sessions.

Our plans for our next sprint

Earlier this month, in the middle of March, we ran our second sprint to reimagine how we handle our other major product line. Bus pooling has been a huge focus of ours for almost three years, and we believed utilizing the sprint method would allow us to figure out how to move forward with it.