Hacking Design Sprints: from Hack Day to launch in just 6 weeks

Over the last decade Design Sprints have been embraced by organisations looking to make rapid progress on a design challenge. In five days, a multi-disciplinary team moves from defining the problem at hand to developing, testing and iterating a prototype solution.

But what if even five days is too much time? This is the story of how we hacked Design Sprints and the lessons we learnt along the way.

Every challenge is an opportunity

Formed in the early 2000s, DSP-Explorer (formerly DSP) are specialists in enterprise database management for both Oracle and Microsoft SQL Server. A couple of years ago, Director of Innovation, Dev Nayak, asked us to support the company in developing a new version of their Oracle Cloud Calculator.

At the time, DSP already had an online tool for estimating the cost of moving an Oracle database deployment to the cloud. However, despite being the second most viewed page on their website, prospects still needed support from the DSP team, and as a standalone tool it was failing to convert.

Dev believed there was an opportunity for DSP to differentiate themselves from the competition but the timeline for delivery was tight. DSP wanted to launch a new version of their Oracle Cloud Calculator, together with a compelling cloud offering, at the Oracle OpenWorld Europe conference — just six weeks away.

For Dev, this was an opportunity to try out the latest innovation techniques and methodologies while learning new skills on the way.

We wanted to stay first in the space with innovation, stay ahead of the competition … I wanted to use some of the innovation techniques that I’d heard about — Design Sprint, Lean Startup, getting more efficient at bringing in customer feedback. I also wanted more confidence in what we were doing. I wanted to work with someone who had been round the block a few times and could provide real experience.
– Dev Nayak, Director of Innovation, DSP-Explorer

Designing a Hack Sprint

As we talked through the requirements with Dev, it became apparent that the DSP team wanted to be more sure of the exact challenges their prospects were facing in the move from on-premises to cloud. They also had multiple internal stakeholders that needed to be brought on board.

Before we could help the team design a solution, we needed to build a shared understanding of customer needs and define the actual problem to be solved. However, DSP were reluctant to commit to a full week of workshops, even though the challenge appeared well suited to a Design Sprint.

With innovation you never know what you’re going to get so you don’t want to invest too much … As our confidence grew we’d invest more, but at that stage we didn’t want to invest six people’s time in something quite new to us. I told Matt and Debbie, “We can get all the senior leaders together for one day; what can you do?” – Dev Nayak

We decided to squeeze as much of a Design Sprint as we could into a single in-person ‘Hack Day’. Our aim was to set the team up with the decisions and stakeholder buy-in they would need to be able to launch a solution six weeks later.

While the timetable was incredibly tight — most sessions were less than an hour — we knew from experience that the time constraint is part of a Design Sprint’s value. It creates a momentum that forces participants to keep moving forwards.

Slowing down to speed up

Despite the time pressure, we felt it was essential for the DSP team to spend time listening to customers and reflecting on their needs. In advance of the day, we ran a number of customer research interviews and usability tests of the existing calculator and then brought the recordings to the Hack Sprint.

Participants spent the first hour listening to these sessions and making notes about their customers’ goals, motivations and concerns, as well as the vocabulary they used to express them. The exercise provided crucial insight into what their customers liked about DSP and what they could do better, as well as the precise problems they were looking to solve in the move to the cloud.

Next, the team continued building empathy by brainstorming “how might we…” type questions. This exercise encourages participants to explore the problem space and identify opportunities to add value while remaining human-centred, rather than going straight for a solution. Ideas ranged from “How might we create a rich landing page experience?” to “How might we embrace the hybrid cloud environment of our customers?”

For Dev, this phase of the day was critical:

Innovation isn’t about finding my best idea, it’s about finding the best idea in the company or even the industry. [You need] to widen the funnel before narrowing it down. A lot of entrepreneurs want to sprint in a direction and just get it done, but there’s a time to bring in new ideas, you need to slosh it around, slow down and let it happen. – Dev Nayak

The final step in the research phase involved incorporating the “how might we…” questions into a customer journey map. We had put the map together in advance using information from the customer interviews and it was a worthwhile investment. The map proved invaluable in helping the team to visualise what prompted a move to the cloud and identify where they should focus their efforts to deliver on their goal: a measurable step change in the number of people engaging with DSP about Oracle Cloud.

Accelerated ideation

Having zeroed in on the problem, it was time to start exploring solutions. We had asked participants to prepare for the day by finding good examples of online configurators, roadmaps to the cloud, and cloud packages. Examples ranged from Lamborghini’s Car Configurator to Backblaze’s Cloud Storage Pricing Calculator. Each participant presented their findings in a quick-fire series of lightning demos, designed to kick-start the ideation process, benchmark against best practice and set the pace for the next phase of work.

We gave the team just one hour to collate key information and start designing solutions. Armed with clipboards, paper and markers, individuals used the agreed goal, “how might we” questions, and inspiration from the lightning demos to generate ideas using a ‘crazy fours’ template. They then moved on to sketching out a solution to one of the three problem areas: the roadmap to the cloud, a package for customers new to the cloud, and the Oracle Cloud Calculator. The team then took it in turns to present their ideas to the rest of the group, before using coloured stickers to vote on their favourite elements from each solution.

In search of congruence

The advantage of this process is that individuals can both develop their own ideas and express their opinions without feeling swayed or pressured by others. Encouraging independent thinking results in more ideas being brought to the table while the dot voting exercise creates a heatmap of the elements that participants consider to be most effective. The group can then pull these elements together to create a design brief and use it to shape the prototyping stage of the Design Sprint.

Sometimes, however, dot voting can expose an underlying issue. In the case of the Cloud Calculator sketches, we could see there was considerable variation when the ideas were presented back. Rather than revealing a general preference for one direction over the other, the dot voting confirmed that these differences in opinion were firmly held.

This design dilemma is a classic chicken-and-egg problem: it was only when they began designing solutions that the team recognised all the decisions that needed to be made, but they needed agreement on those points before starting to prototype to avoid pulling in different directions.

To help the team articulate their assumptions, Matt drew a series of attribute sliding scales on a flip chart. These included whether the calculator should provide an estimate or an accurate quotation, whether the target audience were experienced systems architects or non-technical managers, and whether it should offer pre-populated scenarios or a fully bespoke setup.

We then asked the group to use dot votes again to indicate where they thought the balance should be struck. The results illustrated the areas of contention clearly; the group were divided on the target audience and the scope of the calculator, but they agreed on the need for a simple, self-service interface.

Rinse and repeat as needed

With their assumptions laid bare and supported by the insights gleaned during the morning sessions the team were able to work through the key design decisions for the calculator. The finalised brief included the single page design, choice of environments, personalisation options, AWS price comparison and a clear call to action.

For the penultimate session, we split into separate groups to progress the different streams in parallel. Matt worked with the technical experts to understand the work required to deliver the calculations — information that proved vital to planning the work that would follow the Hack Sprint. Meanwhile, I worked with Dev and the other participants to develop messaging for the marketing collateral and define the elements of what would become DSP’s Oracle Cloud Bitesize offering, ready for sharing with other DSP staff after the event.

Ten hours and several hundred sticky notes later

For Matt and me, the Hack Sprint reinforced something we’d already seen with Design Sprints: preparation is key. The aim is not to do all the work in five days (or one!), but to bring the right people together and create enough momentum for tangible, meaningful progress. Without the customer interviews, usability tests and customer journey map, we would not have had solid basis for the design decisions that were made on the day.

Equally, such an exercise is only the beginning of the road. Even with a full Design Sprint, the outcome is only a tested prototype. With a single day, you need to be realistic about what you can expect to achieve. It was important for us to manage the DSP team’s expectations carefully while wringing every drop of creative energy from them. Although such an intense timetable isn’t necessarily ideal, the Hack Day demonstrated just how much progress you can make if you bring the right people together and combine deep technical and product knowledge with facilitation, ideation and design expertise.

The Hack Sprint brought together people from around the company who know their remit really well and got their input to the larger project. Without it, it would have taken us a year to get to the solution. In one attempt we got it down. – Jonathan Cowling, Director of Marketing, DSP-Explorer

The event concluded with planning for the next phase of work. With less than six weeks left until the launch at Oracle OpenWorld, time was of the essence. You can find out how we did it in Part 2.

Huge thanks and big shout out to the incredible team who made this happen and without whom none of this would have been possible — from everyone who contributed at DSP-Explorer to Heather James of sugarzoo for her incredible coding skills and Stina Jones for her creativity and design expertise.