What we learned from our first Build Week

What’s a build week, and how does it work?

As a team, one of our objectives for 2018 is to create a variety of new products, separate from the company’s traditional portfolio of client work. This objective has been driven in no small part by the success of The Higher Lower Game, which we released in 2016, and has to date been played more than 750 million times.

Homepage carousel 3

For the past few months, the team have been working on a couple of ideas that build upon the lessons learned from The Higher Lower Game. However, one of our main challenges has been fitting in this work around our other priorities. So, at the start of the year, we decided to try something a little different: ring-fencing a short period of time – a ‘Build Week’ – for us to focus solely on developing a new product.

To ensure this worked, we blocked the time out in our diaries two months in advance and made sure this was communicated to the entire agency and our clients well in advance. We also all agreed on some basic ground rules to ensure we gave ourselves the best shot at success. Build Week was to be:

  • Focused – with a clear aim, agreed upon in advance.
  • Inclusive – with the whole team involved and able to contribute.
  • About building something – obvious, perhaps, but worth stressing. Our aim was to produce something shippable; not start something we might then struggle to find the time to complete.

Build Week also provided us with an opportunity to learn about new tech and new tools, about how we work together as a team, and about whether this was a good approach to apply to new product development in general.

The process

We started a week or two before, running a couple of sessions to generate and refine ideas.

ux designer

At this stage we were open to any idea, but it soon became apparent that a game of some sort was our best option due to our experience with the Higher Lower Game, our collective interests, and the constraint of only having five days to design, generate content, and develop.

On the Friday before we started, we settled on an idea: ‘Event Horizon’, a simple (we hoped) game loosely based on the boundary that marks the limits of a black hole, and even more loosely based on the critically-acclaimed film of the same name.

On Monday morning, we regrouped to review the idea and to complete some competitor research. The remainder of the first day was then spent storyboarding, looking into the overall art direction, and setting up the basic game mechanic.

For the rest of the week the focus was on build. Arguably, the biggest challenge we faced was reigning in all our ideas; in no time at all we had a wealth of ideas for a very sophisticated game, but one that was way beyond what could be achieved in a week.

Similarly, by the middle of the week we realised that what we’d originally thought of as a fairly low effort piece of work wasn’t going to be quite as easy as predicted. As such, we had to reduce the scope - for example, focusing only on desktop - to ensure we met our target of having something shippable by the end of the week. Although it was a challenge, and at times we felt up against it, by Friday afternoon we had a v.1 of what we were now calling Horizon.

Horizon-compressor

What we learned

The week provided us with some useful learnings that will be important going forward:

1) Focus. It’s very easy to get over-excited about new ideas and new directions you could take. However, doing so means it’s also very easy for the scope to quickly grow beyond what can realistically be achieved in a week. Maintaining focus isn’t just about setting a target at the start of the week; it’s important to revisit it regularly, questioning priorities and making sure you’re not straying too far from your core objective.

2) Efficiency. Although we thought having a dedicated week for the whole team to work together would be the most efficient way of creating a new product, this didn’t turn out to be entirely true. It was great to be able to collectively focus on new product development, but there were challenges: it was sometimes difficult to split development tasks and so we occasionally trod on each other’s toes and duplicated effort, whilst with design there was an uneven spread over the week with lots to do early on, but less and less as the week progressed.

3) The balance between learning and doing. Although we’d gained much experience from the Higher Lower Game, that was a very different beast - both technically and conceptually - to Horizon. Whilst this difference provided us with a great opportunity to learn (and use Phaser for the first time) it also made the task of producing something in one week very challenging. There is definitely a balance to be struck between learning and building something shippable.

What’s next?

We’re all keen to see where we can take Horizon, so we’re going to continue to iterate on it over the next couple of months. We’re also reviewing the Build Week process with a view to running another later in the year.

Although this first Build Week had its challenges, we feel that with some further refinement it can be a really useful tool, if not for building a new product from scratch, then at least for providing us with a good platform on which to iterate in the future.


What we’ve learned from the 100,000 people who’ve completed our ‘What kind of designer are you?’ quiz