Gimbal Product Design Process

How We Completed a 5 Day Design Sprint in 3 (and Avoided Near Disaster)

by | Oct 29, 2015

At Gimbal, we help brands gain exposure through mobile advertising.

As most of us know, the mobile advertising industry is growing fast. Running a single mobile campaign today will have you working with up to 12 different vendors, and managing all of them is a time consuming and exhausting process. In a nutshell, it takes a lot of pieces to make one campaign go.

Fortunately, for us, we have been able to build a single platform to accomplish all this. To that end, our platform needs to be robust, but also maintain a simplistic and intuitive process. Ensuring this keeps our Product, UX, and Engineering teams on our toes as we figure out how to seamlessly integrate new features into our platform.

The Problem

During our user research, we discovered that we need to give our users a simple way to generate highly customizable reports for forecasting mobile ad campaigns.

In other words, we needed a tool that will allow our users to determine how much it would cost to run a mobile ad campaign with specific targeting parameters.

For example, if a brand like Nike spent $5,000 on a mobile campaign targeting females that live in Washington that are interested in a healthy lifestyle, how many impressions will the brand get over a 1 month period? 500K? 1M? This type of tool is crucial in generating business and is used by a sales team to tell potential clients what they can expect in a campaign.

The Process

So, to shake things up a bit and try to find a solution, we decided to run a design sprint inspired by the Google Ventures Design Sprint (their entire process can be found here). They basically solve design problems in 5 days.

However, we couldn’t even allocate an entire 5 days to this, so, we had to fit it into 3 days, for only 2 hours each day. I was able to get our Head of Product, an intern, two engineers, an Ad Operations personnel and myself to join in on this three-day design sprint.

You can see our agenda below:

  • Day 1 – Find User Problem & Common Understanding
  • Day 2 – Explore, Explore, Explore
  • Day 3 – User Study


DAY 1 – Find User Problem & Common Understanding
On the first day we needed to dig into the problem, find the user’s needs and come to a common understanding.

The following exercises only took us an hour as I was strict on the time for each exercise to make sure we kept on track.

We were first lead by our Head of Product, Marcos Escalante, on the business opportunity. Then were lead by our Ad Ops person, Alex Steady, and intern Chris Cohen to review competitor tools, and begin team interviews to understand the context of this tool we needed to create.

While listening to everyone, we were all writing down questions on post it notes. These questions were “How Might We” questions, questions specifically phrased to inspire creativity rather than inhibit it, and would be used for a later exercise.

We then finished the first day by drawing out a complete storyboard and determining exactly what part of the story to tackle. Looking back, we should have chosen a smaller part to focus on.

We also scheduled two users to test on Thursday (in two days), which was crazy because we didn’t have any designs yet. (Five user testings is ideal, but we had to shorten it based on our time and resources.)


DAY 2 – Explore, Explore, Explore
This was the fun day, but it did take three hours. At the end I was exhausted. The purpose of day two was to find every conceivable way we could design our product from all the different perspectives involved in the design sprint.

We also emphasized our desire to test out-of-the-box ideas as this design sprint was the best opportunity to do so. We didn’t necessarily want to test ideas we knew would work, but try to find something innovative that could really help our users.

In order to get as many new concepts out on the table, we did all the following in day 2 (just like Google!).

  • We reviewed the previous day’s work as a refresher
  • We each created a mind map to assist us in our design explorations
  • Crazy eights drawing exercise (twice)
  • We each created our own story board on paper
  • Each design was silently critiqued
  • Then each design was critiqued out loud

After all these exercises it was time to decide on which design to prototype for user testing. After reviewing the critiques and having a short discussion, we knew which concept to prototype.

I spent the following afternoon, late evening and next morning creating a prototype from sketch + invision. Luckily, we have a pattern library so coming up with new components and styles was not hard.


DAY 3 – User Study
Sooo, this day started off badly. The night before our prototype was erased, and I had to start over at 2AM and finish up the morning of user testing! Yeah, I know, I also wonder how people can erase files with computers that have auto-save and redundancies, but trust me, it can happen.

Despite staying up late and hustling to get the prototype done (again) on the morning of the user study sessions, the Internet in our office went down and it gave us a little more time to refine the prototype.

Startup life.

The next day we completed our user testing. remotely. We had users call in from SF, Ohio, and Los Angeles and we recorded the audio and the users’ screen via Zoom. We had approximately 5 observers for each call, who were taking notes as I led the session. They would then send me their notes and feedback for me to consolidate.



After reviewing our consolidated notes we made some final conclusions from this design sprint such as…

  • We learned that next time we should focus on a smaller section of the user story. Based on our bandwidth and resources this will help us get more done in less time.
  • We learned that our users understood the flow of our concept very well. This means we can keep the overall flow and focus on other parts like the interactions of certain components work.
  • We learned that most of the time our users knew exactly what kind of report they wanted and exactly what they are going to target. This means we don’t need to give them a browsing experience, but a searching experience.
  • We learned that our users trusted our smart suggestions. We discovered this process was not an exact science, but that the users had to use their best judgement most of the time. If we can execute on creating smart suggestions that are seriously helpful, then we will be onto something big.

Based on these finding we decided we are going to explore a forecasting tool focused more on a smart search feature with smart suggestions. This is different than the average report builder made up of checkboxes and form fields.

So, we know what we came up with has potential and that the users understood the main flow and were able to accomplish their tasks during the user study. If we decide to implement such a tool into our current platform, another design sprint might give us that last bit of feedback to determine if this is something we build or put on the side.