How to Design

Bomb-Proof Products

in 5 Days

Using Google Venture’s Product Design Sprint in an existing business

OVO Energy’s product team has a different take on design sprints based on Google Venture’s Product Design Sprint as a tool to involve stakeholders and quickly explore design solutions for products in need.

Being in an existing business, we had to find a way to make the most of the limited time we were given with senior stakeholders and therefore applied a leaner way to run Product Design Sprints. In the end, we learned that through good planning and focus a product can be re-imagined, designed and tested in only 5 days, requiring just one working day of stakeholder time.

Google Venture is using and promoting a design process they call the Product Design Sprint. It’s a process that takes a product or feature from discovery all the way to a tested prototype in 5 intense days. The beauty of the process is that you get everyone involved in finding a solution. Stakeholders and decision makers take part in the ideation as much as designers and developers, and in the end you have a solution that everyone has agreed on — no sign offs or misunderstood briefs.

At OVO we were curious to try this out as a way to quickly generate and validate new designs. At Google Ventures they gather all the stakeholders, including the CEO and work with them for the whole sprint. Having senior stakeholders onboard from the beginning and in the evaluation of the ideas generated is crucial for the Product Design Sprint to work. If we don’t get the product vision, business needs and expectations right we’d easily go down the wrong path with the designs and would have to correct it at a later stage.

We didn’t have the luxury of having directors leaving their business-as-usual activities to join us for 5 whole days, so we came up with a structure where in total each senior stakeholder would commit to 1 day’s worth of participation, spread across the 3 initial days.

It was going to be tight, but we felt that limited time with everyone involved was better than a lot of time with only a subset of the stakeholders. By asking for 3 hours in day 1 and 2, and 2 hours in day 3 we managed to get everyone in a room and agree on both scope and solution.

The Product

The product we chose to try the Product Design Sprint on was OVO’s Quote & Switch flow. This is OVO’s most cost-effective acquisition channel and getting more people to sign up this way would have a direct impact on the business. As we were in the process of taking the development in-house we also had the opportunity to take a look at the user experience and see how we could increase the conversion rate. The size of the product also seemed to be the right size for a Product Design Sprint.

Day 1 — Understand

We started on a Monday to avoid having the weekend interrupt the sprint. We had dedicated 3 hours to share insights and requirements, and set the scope for the sprint. We were 5 members from the product and design team, 2 from the commercial part of the business and 1 from testing. Prior to the sprint we had also met with a marketing senior who unfortunately couldn’t take part but shared valuable insights with us.

Day 1 is all about understanding the current product and what we want to do with it. Performance metrics were mixed with regulatory requirements and future roadmaps. We stuck to Google’s agenda pretty closely and at the end of the session decided on the user story and key concepts (keywords and values that could guide our ideation in day 2). Getting the user story right is crucial. This is the user journey we will generate ideas for in day 2 and it’s going to define what’s being designed and tested later. Too many steps in the journey will also be too much to handle in one day so it’s important to get the scope right.

It was a lot of information to take in but after 3 hours of sharing knowledge, wading through governmental requirements, looking at the competitive landscape and discussing values we had a good understanding for what areas of Quote & Switch we wanted to address in next day’s activities.

Day 2 — Diverge

The most creative and intense day. Due to the busy schedules of the participants we had replaced some stakeholders for other ones. We still had people representing product, design and business but we added a developer to get a technical point of view. We had a quick recap from day 1 and introduced our process to our 2 new participants. Our user story had 3 steps to design: Get a quote, Present the plans and Sign up. There was also a final step — Follow up, that we left out because of time constraints and because it was borderline of being outside the scope of the core service. Although our current Quote & Switch is desktop only, the new version will be responsive and we went mobile first in order to focus on the most important features.

Again we followed Google’s method and did mind mapping, crazy eights, and storyboarding to generate ideas. Everything was strictly timed to keep the flow going and we were happily surprised to see that everyone in the room took part in the sketching and storyboarding with lots of energy and enthusiasm. Everyone even stayed a bit longer to be able to squeeze in the Sign up step of the user story. The storyboards that were produced took the viewer through a user interface, but you don’t need to be a designer to create these. The limited time given for each storyboard forces you to focus on what’s important and take a step away from picture perfect drawings. In all honesty some of the stakeholder’s storyboards were better looking than the designers’.

The storyboards were inspected, discussed and rated by the whole group before we moved onto the next step of the user story. Generally each step took about 40 min from sketching to rating, but we got quicker each time we did it. We left day 2 with 8 storyboards per user story, overlaid with colourful stickers to indicate the ideas that stood out. In the rating process everyone in the group were given 4 stickers to place on the ideas they felt strongly for. This way a heat map was created and we could easily filter out design elements and concepts that had great potential. We would come back on day 3 to create order in this creative chaos and pick the ideas that would form the basis for our prototype.

Day 3 — Decide / Start designing

In day 3 we reviewed the ideas that had received most votes and looked at how we could bring them together into one seamless experience. Again it was important to have all stakeholders represented since this is what we’re going forward with. Together we created a complete user journey in wireframes on the whiteboard, based on the top ideas populated in the original user story. This is a group exercise and it requires you to accept that your favourite idea might not make it, but everyone is free to make a case for the ideas that aren’t immediately agreed on including. If the group can’t agree on what solution to pick it’s ok to include both as long as you have resources to test both. If not, it has to come down to one voice, on our case the product director. We got away without too many disagreements but we kept a few ideas for separate A/B testing outside the scope of the sprint.

This was the end of our 2 hour session with all the stakeholders, but it obviously didn’t end there. The designers then took the wireframes to the computer and started to build the UI to be used in the prototype. We used Sketch for it’s ease of use and ability to reuse elements. It’s also easy to add visual detail, so you can start with a rough wireframe and then refine it without changing software.

Day 4 — Designing & Prototyping

Google Ventures include a parallel 4 day research sprint with a dedicated researcher in their design sprint. We didn’t have the luxury of having a dedicated researcher so one of the UX designers played this part while also taking part in the normal activities. This worked since we were recruiting test participants in the office which could be done in an informal way with short lead time, but it was still hard to fit in both test planning, booking in participants and designing at the same time.

At this stage we still hadn’t decided whether to test on a mobile device or on a desktop with a smartphone simulator. Ideally we wanted to try it on the real device, but the user interactions would be harder to capture for later analysis. The benefit of using a desktop was the ability to track the cursor as well as the user’s voice and facial expression. We exported the screens in Sketch to Invision and created a mobile prototype that we could use on either mobile or desktop.

Day 5 — Validate

We still had some tweaks to make to the prototype in the morning, and with 7 test sessions scheduled between 11am and 4pm Friday was going to be a busy day. Given that we weren’t looking for feedback on mobile specific interactions, or how a mobile context would affect the user’s choices we chose to do the validation on a desktop. We used InVision for the prototype and captured the session with an application called Silverback that runs in the background. Each session took about 15 to 20 minutes and was a combination of a usability test and a discussion about the user’s personal needs and preference around signing up to a new energy supplier. Since we tested on people in the office it was important to take them out of the mindset of looking at an OVO product, and rather do the exercise as an individual exploring the options for a new energy supplier.

At the end of the day we were pretty drained, having listened to and observed all the users. But we also had a list of really useful insights and areas where we could improve the user interface.

What to do after the sprint

The sprint was over, and we were left with a prototype and a list of improvements. There were a few things left to be able to wrap it up for this time, including evaluating the Product Design Sprint as a process for our team.

The following week we had a retrospective session to evaluate the sprint and see how things could be improved for next time. Overall both the product team and the stakeholders were very positive to the process, but we also had a number of items to consider for our next sprint:

• Fine tune the agenda and content for day 1. Some parts were rushed, and it would have been good to have more insight into existing user behaviour and attitude.
• Decide with the group on assumptions that should be verified in the test of the prototype. This should be done in day 3 with everyone involved, but due to time constraints it was left out. Without having guidance on what we wanted to test it came down to the designers to make the call.
• Share the prototype at end of day 4 to keep everyone in the loop and get feedback. Despite that it wasn’t 100% ready, we should have shared the prototype with everyone.
• Send out a summary of the day and the agenda for next day at the end of each day. With participants across different teams communication becomes more important than ever. A quick summary email at the end of the day is a nice way to keep everyone informed and engaged.
• Debrief the following Monday showing prototype and test results. With a process this intensive it begs for a clear ending so everyone leaves with a feeling of closure and a sense of ‘We did it!’.
• Decide on what happens after the sprint. Equally important to the debrief are the next steps. There should be a way forward thought out even before the sprint ends. Ideally shared in the debriefing session.

To conclude we can say that our first Product Design Sprint was successful and generated a lot of value in a short period. Having the stakeholders taking part and sharing their knowledge and angle on the product helped decision making and made sure that we weren’t missing important information and requirements. We all came away from the experience energised, focussed, and wanting to do it again.

For the actual product this was a kick start for the redesign, and since the sprint we have iterated the design, added tablet and desktop views and started development.

We are now looking at other products and features that can benefit from this process and are setting aside design sprints into our regular planning so that we do a set number of sprints per quarter.

We are hiring! We are looking for digital designers to join our team in central London. Apply here.