Design sprints at Firefly

Sketching has always been essential part of what we do at Firefly. Thrashing out ideas with paper and pen is a great way of capturing early ideas quickly with the minimum of fuss. Together with user research, sketching is among the first steps we take whenever we’re designing a new feature.

We’re also constantly refining our processes, always on the lookout for more efficient ways to build better software that allow our users to perform the tasks they find most useful.

We’ve recently started using some ideas from a methodology called Design Sprints. Although its still early days, I wanted to share our experience of (what I’m calling) Firefly-flavoured Design Sprints.

The communications squad works on solutions for a more flexible navigation in Firefly
The communications squad works on solutions for a more flexible navigation in Firefly

What is a design sprint?

The design sprint was developed by Jake Knapp from Google Ventures. In its full form, its a five day process for answering business questions through design. Its a way to fail early meaning you, theoretically, deliver something that works first time.

Implicit in the process is the requirement to gather opinions from all areas of the business, not just the design team. Typically you might involve those with customer contact, for example the support or client-experience teams. You may also invite an expert from finance and marketing as well as members from the tech and design teams.

A plan for the week might look like this:

MondayUnderstanding the challenge and decide what problem you’re trying to solve
TuesdayA number of different sketching activities to fully explore potential solutions
WednesdayThe whole team presents and votes on solutions from Tuesday.
ThursdayCreating a prototype of a chosen solution.
FridayTesting your prototype with real users and gathering feedback.

What’s the benefit for Firefly?

We’ve been getting excited about Design Sprints for a while. The mantra of “fail early” is especially useful as it helps us to stay agile in a fast-paced market place.

We’ve always listened closely to what teachers, students and parents want, but understanding exactly what they’ll find genuinely useful is rather more difficult.

A process like Design Sprints helps us get our ideas in-front of customers at the earliest possible opportunity, and find out if what we think they want is actually useful, without going through the long process of design, build and QA first.

Our experience

We already had a very well defined problem, namely how to give schools greater flexibility in their Firefly navigation. In the sprint we’d set out to design both the updated navigation and the administration interface that would allow site administrators to customise the menu.

I ran the day, as the “facilitator”. Viviana, our product manager, was the “decider”. The Communications squad (a cross-discipline team who would be building the feature) were our sketching team.

We used a number of the activities from the Design Sprints book, together with a mix of activities from elsewhere that we thought would enable us to solve this problem in a day.

Jobs to be done

Before the sprint, Viv created a list of jobs to be done. Based directly from feedback, these are a way to think about tasks that users want to achieve. They’re written in a way so as the focus is on the task rather than a particular technology or solution, an example of this might be:

When organising the school’s Firefly pages, I want to be able to divide pages into highly visible sections, so I can make it easier to find content that is relevant for students, parents and teachers and show off the content we have.


We went through a number of sketching exercises, first creating quick low fidelity sketches to flesh-out some early ideas. Then we moved on to creating more detailed sketches that detailed a whole user journey.

Aegir creating some early ideas in the first sketching activity
Aegir creating some early ideas in the first sketching activity

Arriving at a solution

After each of the team had taken it in turns to present their sketch, we moved onto a round of heat mapping. Everyone was given a set of 10 sticky dots and we’re told to stick one or two next to features they particularly liked from the sketches. In this way, standout features were highlighted by clusters of dots.

Zannah casts her vote for a part of a solution she particularly likes.
Zannah casts her vote for a part of a solution she particularly likes.

Viv then lead a round of Q&A where we’d discuss the standout features. As the decider, she then made the call on which features would progress to design stage. I noted these down as a set of requirements.

Finally, we created a final set of sketches as a team (with one person designated as the “scribe”) that combined all the features into a coherent user journey.

What we learned

This type of small, well-defined problem is solvable in a day. What we didn’t do is square the circle, i.e., test our solution with users. That’s a definite problem. We plan on creating interactive prototypes during the design stage which we’ll test with teachers.

I predict this won’t turn-up too many surprises as we’ve not deviated too far from an established pattern. But this is definitely worth thinking about earlier for more complex problems or brand-new features.

On a practical level we were also able to refine the “short-sprint” process for the next time: Chopping out the bits that didn’t yield anything useful and providing better explanations around the bits that confused people.

We would’ve also liked to invite some guest experts from other areas of the business, we’ll definitely do this next time.

Where next?

Finding a balance between the full methodology as set out in the book, and a process we can use many times in quick succession is tricky. Cherry-picking is something the book suggests: You can remove day five, and do testing as a separate process without the need for the whole team. However, we deconstructed the sprint to its bare-bones, and I’m not convinced we didn’t loose… something.

But, Firefly-flavoured Design Sprints are definitely here to stay. We’ve already booked-in longer sprints to help us solve slightly bigger problems, and allow us to include more of the methodology. We’ll refine them over time, cherry-picking the bits that work best for us.

The culture of fail-early is one that we’re committed to. At the heart of this is getting features into the hands of clients as early as possible, listening to their feedback, and quickly delivering the next iteration. Design Sprints are just one way of doing this.