The Design Sprint at Red Badger

At Red Badger, we typically start projects by gathering insights and working out initial concepts. This allows us to understand the users, identify a scope for the project with clients and prepare design assets for development. Also known as ‘sprint zero’, it is an intensive week of absorbing as much as possible and coming up with a plan with the client working with us. 

 

Project Brief

We were approached to design and develop a multichannel touch screen that would go in a retail store. Unlike most e-commerce projects, this one didn’t want more sale conversion or higher profits. The goal was to improve in-store experience and increase customer engagement. Handed over a presentation as the project brief we could almost see the open-ended solution sea in front of us. Just as we were daydreaming about virtual shopping assistants, personalised product recommendations, we were hit by the expected launch date and resource plan allowing only 4 weeks of development and an expected launch in 6 weeks. This was going to be a very short pilot project with possibly many to come. We needed a tangible starting point to validate the concept and iterate as quickly as possible. 

 

Our Approach

We decided to run a design sprint to kickstart the project. We wanted to come up with a concept we could test and validate before our developer joined the team. 

The design sprint is an intensive week-long process of problem solving. Google Ventures runs Design Sprints for their portfolio companies to be able to make fast and predictable product design decisions. It doesn’t matter if the product/service is brand new, or is looking for a make-over; the whole point of a design sprint is to explore the problem in hand and come up with testable solutions quickly.  

The design sprint combines design thinking principles with the lean methodology. Based on iterations and fast paced decision making and prototyping, the outcomes try to find the sweet spot between the three forces desirability (user), availability (technology), and the viability (marketplace/project scope). 

The one hour planning meeting quickly turned into rapid sketching sessions and before we knew it we were already busy sketching out our ideas.

 

Day 1 

designsprint1

We started with the project brief and went through any material we had available. We looked into the best examples of multichannel implementations in-store, discussed the results from previous user research on customers and mapped out a high level user journey. By the end of the day we had defining keywords for the experience, dozens of bookmarked examples and the rough sketches of our Crazy Eights sketching session.

 

Day 2

designsprint3

We spent the morning working on the sketches and refining the user journey. The official kickoff with our clients was in the afternoon, which would let us get an initial feedback on everything we had and the direction we were taking.

 

Day 3

By Day 3, we had quite a few sketches so we started to put in a digital format. To get initial feedback on some of our assumptions we used the projector in the office to see how the other Badgers reacted. We grabbed a few developers by the kettle and asked if any of the elements might cause headaches when it came it implementation. UX and Design worked closely at this stage, the transition from sketch to wireframe and then to design was almost at lightning speed. 

 

Day 4

designsprint4

Day 4 was testing day. We had been itching for some feedback to see if our assumptions were somewhat valid. We went over the wireframes before it was ready for testing. We mocked up a prototype by sticking an iPad and the homepage design on a piece of cardboard and went out for some user testing. 

 

Day 5

designsprint5

By Day 5, the meeting room looked more like a ‘war room’ than anything. We iterated on the wireframes for the 4th time based on the user tests and flagged our technical requirements.

We had a clickable prototype that linked all screens for our first progress meeting. The meeting went well with positive feedback. Having a clickable prototype helped us discuss features that would have potential development risks. 

By the end of the week we had enough information from users, the client and developers to put together a backlog of epics and list our technical requirements. The overall impact of the design sprint is still to be seen but for now it’s fair to say that it will stick with the Badgers for a while.