Summary

This was Deputy’s first ever Design Sprint. Since we had a clearly defined problem with what we believed was a bounded scope, we decided to put this methodology to the test.

In 5 days, we managed to fully unpack the problem with internal stakeholders, design and test a prototype with our users, and scope the development with the engineering team.

Unfortunately (as though it’s bound to happen occasionally) the Product Roadmap changed right across the end of the workshop, so the project didn’t see the light of day for 5 months.

However, when a new team picked up the project, they were able to go straight to building the feature. A testament to the process and the team having achieved the desired outcome.

Problem

Deputy is a workforce management system for hourly workforce. The platform’s core features revolve around the digitisation and management of hourly shifts. At a high level, workers can clock in and out of their shifts, and perform basic HR tasks (e.g. request leave), while managers have more advanced features available (e.g. rostering, forecasting, reporting).

Amongst our feature requests, the most frequent turned out to be giving employers the ability to approve leave on mobile. Given the clarity of our objective that emerged from thorough research, we decided to solve the problem using Google Venture’s (GV) Design Sprint methodology. A 5 days set of activities aiming to crack a specific problem.

What is a GV Design Sprint?

A GV Design Sprint is a proven methodology for solving problems through designing, prototyping, and testing ideas with users. A shortcut to learning without building and launching. After the experience, we could summarise it as 5 people and 5 days of madness.

Team

The team was composed by 2 Product managers, 2 UX designers, and 1 iOS developer.

One of the things I found to be most functional for the workshop was the clarity about roles (spoiler alert) defined as Tech expert I was the Design resource for the project, taking care of the prototype as well as the user testing sessions.

Process

Day 1: Interview the experts

On day 1 we started our journey by interviewing the experts on the subject matter. We included stakeholders from most varied departments, both to receive diverse perspectives on the problem, and to enhance inter-department collaboration. We thus interviewed:

• SMB Sales manager
• Product Marketing Manager
• Chief Product Officer
• Head of Mobile Engineering
• Senior Software Engineer

Together with them, we worked out a series of questions we needed to address in order to reach our goal, and worked out the user journey map.

Day 2: Sketching session

With all this fresh information in mind, we were able to move on to the next set of activities, starting off with a sketching session, and culminating with a critique and synthesis. The highlight for the day for me was the so called museum.

• 

• 

• 

• 

• 

The museum is a play where participants expose their sketches and silently look at them in complete silence, thus avoiding a bunch biases that would be likely to interfere with good decision making practices. I also wrote about some of them in this medium article for the UX collective.

Day 3: Decision making

Day 3 was dedicated to thorough decision making. We reviewed the sketches and combined what we believed to be the best elements of each solution into one big idea. Fundamental for this process was having clear decision making power given both by the initial role definition, as well as by a points system.

Once we all agreed about the way forward, we moved on to sketch a storyboard of what the prototype would look like for the user testing session on day 5.

As the design expert, my role was to drive this process to ensure its feasibility.

• 

• 

Day 4: Prototyping

Day 4 was the longest of them all for me. We had a very ambitious prototype to test as our initial assumptions changed while mapping the storyboard.

While I started organising my Sketch file, two members of our gang were collecting and organising useful data for the prototype and designing precise scenarios. Meanwhile the other two were organising interview guidelines and lab equipment for day 5.

Here is what the prototype looked like at the end of the day 👇

• 

• 

• 

• 

Day 5: User testing

Everything we do is for our users, and day 5 was the culmination of that. Starting in the morning, we had 5 hours of interviews setup with 5 users we identified as suitable for the experience. That was managers of SMB or franchise who would be the approving leave.

The setup for the interview was quite simple: 2 of us were interviewing users, the other 3 taking organised notes. This allowed everyone in our group to experience both sides and avoid interview fatigue, while learning a ton from feedback.

• 

• 

Results

After the user testing session we were able to quickly iterate towards a very refined prototype. You can see it below. In this scenario you are a manager, and you received a notification, your goal is to do what you do.

⚠ No swiping allowed on this prototype!

Continuous improvement

So that was an awesome beginning to upcoming Deputy feature. As tradition, we always see ourself far from perfection and always able to improve upon our work. Yet this experience has been beyond phenomenal in regards to both process and achievements.