Have you just been handed a blank canvas and asked to solve a critical business problem you know very little about?
Do you often find yourself scratching your head wondering if the way you are solving a problem is useful to your customer?
Is your deadline just around the corner?
A group of developers in our Software Studio recently conducted a Design Sprint (DS) to combat these exact issues. We managed to go from not knowing anything about the problem we were trying to solve to placing prototypes in front of our users and gaining valuable early feedback. And this all happened in a week. Here is our story.
If we were to do another project,
would we use a design sprint?
Simple answer: yes.
Our recruiting department is our driving force behind finding and coordinating with new talent. All of these prospective employees need to be scheduled for interviews. Unfortunately, at the moment, this process is all done manually. Our recruiters go back and forth with candidates, trying to come up with a schedule that works best for both sides. This process can seem tedious—and that’s just the regular scouting and hiring experience. It becomes overwhelming when you think about campus recruitment. Picture this method being done for 5+ schools with 75+ students each.
With Capital One Canada’s growth looking to only increase in speed, the recruiters knew they needed a better method. Realizing this was a problem that could be solved with technology, they reached out to the Canada Software Studio.
The questions presented above immediately came to mind. How do we even begin solving a problem for a process we know very little about apart from our own experience prior to joining the company? This is when one of our developers suggested we use a design sprint, since it’s a process that solves the concerns that each of the questions present.
What is a design sprint?
Essentially, a design sprint is a process that allows you to “…fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments”1.
Why did we choose a design sprint?
Since this project was volunteer-based (Toronto Software Studio leadership encourages side projects), we didn’t have a lot of resources to work with, but still needed to understand our users’ requirements, define an MVP and create a prototype. We decided to utilize everyone’s creative capabilities. Based on our observation, doing a DS seemed promising as it would be very helpful in the following ways:
- Tight deadline: The efficiency of a DS allowed our business problem to progress from an idea to a prototype and to receive critical customer feedback within a short timeframe.
- Understanding requirements: Because the DS involved most of the team, the process naturally evolved and members were more familiar with the project requirements.
- User feedback: A DS allows us to get user feedback early in the process. This helped to shape the product in a form which best satisfies the users requirements.
- The diversity of ideas: Design Sprints are very collaborative and use the voting process, which removes bias. This can help to promote an environment that leads to unique ideas.
In our next blog posts, we will outline what we did on each day of the design sprint, and what we achieved. Stay tuned!
Ealona Shmoel, Matthew Cabral, Mahtab Sabet, Sarmad Ali
1“The Design Sprint.” GV. Google Ventures, 2016. Web. July 16 2017. http://www.gv.com/sprint/