Sun, Sea & Design Sprints
8 minute read
James Fox profile photo
James Fox
Day 1 - Unpacking the problem

We unashamedly cheated on this for our own sprint, having spent time up front working through how we might approach a 5 day sprint in Ibiza. But was it really cheating, or just a sensible way to approach our sprint?

If you’re building on an existing product, or living and breathing a problem that you’ve decided to solve, then you could conceivably start a sprint ‘cold’. But you’d already have a degree of definition, and probably some initial ideas, which we lacked. To offset this we decided that we’d tackle a large problem with a specific piece of technology ‘How can we bring people together using Apple TV?’. We knew that we could generate good ideas around this and that the technology could lend itself well to the problem - televisions have been in the corner of most living rooms for decades.

Keeping things simple at this stage helps - firstly, what are the problems you could solve and then what are the potential solutions? This helps keep things focussed on users but also at a macro level so that you don’t end up down too many dead ends.

After kicking around our problems and solutions we spent the rest of Monday completing our business model canvas. Once you’ve got a potential solution, and have the skeleton of an idea, then a lean business model canvas can really help bring things into focus.

What did we learn?

Make sure you prepare - even a tight and experienced team is going to take time to get up to speed, so preparation is everything.

Keep it simple - first determine the problems you’re seeking to solve, and try not to move too deep into solutions until you’ve got a good spread of them

Business model canvas - focus and work through your ideas at this level before you go any further

Competitor research - don’t scrimp on uncovering as many potential competitors as possible, but also don’t be discouraged from pursuing your idea in the face of them

Don’t be hungover - it’s not big and it’s not clever

Day 2 - Focus on the user

Creating a high-level user journey for your product is essential - it gives you a sense of the scale of the task at hand, and helps focus your energies on the most important points to test. We’re able to draw on experience across the team, but especially from Chris (Design) and Iain (Product) which is invaluable in making rapid progress.

The late summer mosquitoes kept us indoors for the second part of the day, but it was still a lot of fun working on our idea. Crazy Eights - where the whole team sketches user interface designs - provided us with some great solutions. And, as with most parts of the sprint, there are a ton of other processes/canvasses and documents out there you can use to keep things going.

What did we learn?

User journey - getting this up on the wall can make a great contribution to making the product more solid and identify the big questions early

Look before you leap - there’s usually a process e.g. Crazy Eights somewhere you can use to draw on, and don’t be afraid to experiment. More recently we’ve used established canvasses for everything from surveys to determining social impact. Experiment on what works for your team.

Day 3 - Keep calm, and get building

You can’t build and test everything, sadly. It’s at this point that we needed to wave goodbye to solutions and features that weren’t going to make it into our prototype - we wanted an MVP that would test our assumptions, and be feasible to build in the time we had. We’re lucky to have the skills in-house to design and develop a front and back end system, but it’s also entirely worthwhile or feasible to build a brochure site quickly and easily to test your assumptions.

At this point the team also started to divide its responsibilities into a ‘problem’ and ‘solution’ team. The problem team started to think about how best to test our prototype - (who to ask, what to ask and how). Meanwhile the solution team got on with finalising features and the build itself

What did we learn?

Kill your babies - or at least put them on hold for a while. Someone needs to make a call, and you need to find any areas where there’s a lack of agreement and get a decision made

Break up the team - let people focus on what they’re best at, and don’t let yourselves ‘groupthink’

Silent voting - can help with all of the above

Day 4 - Come together

The problem team mainly kept out of the way as the ruthless solution team did what they do best - designed and built. It’s astonishing what the right mix of people can accomplish in one day, and by the end of Thursday beers were cracked to celebrate a new prototype having been born.

Of course, the solution team didn’t get the day off. It was important to keep working on how best to test, building out a survey and getting into the finer details of how the product might one day become a business.

What did we learn?

Planning wins out - if you’ve got the first three days right, and been mindful of the time throughout then it should make for a smoother delivery of the prototype. And keeping the time invested focussed should be one of your major priorities while you’re still looking to test ideas

Prototyping - not every prototype needs to be a functioning build, we could equally have smoke tested as part of our user research. It just wasn’t the plan this time as we wanted to get ours hands dirty with the tech

Day 5 - Testing times

Or at least they should be. As we were in Ibiza, and using prototype equipment, our opportunities to user test were limited, but that didn’t stop us from surveying as far as we could around the product and its potential business model.

Meanwhile, the prototype itself could be finished up - tweaked and polished to make it as representative for testing as we could. But all in time for a few final beers as the sun set on our adventure in Ibiza.

What did we learn?

Surveys - we love typeform, it’s quick and easy to get a user-friendly survey up and running.

User feedback - hindsight is a wonderful thing, but if we could have had more direct access to users for testing it would have been useful.

There’s always next year...