As a team, we’re committed to carving-out time in our schedules for incubation; digging deeply into problems and arriving at creative solutions. With this commitment in mind, I decided it was time to book in a Hack Day.  

The benefits of internal hack days are well documented. Dedicated time to problem solving as a team does wonders for team spirit, collaboration, innovation and creative thinking. We knew that if we set-up our hack day like a Design Sprint, we could also tap into skills and tools that we can use with our clients and invest back into the business. 

The team is busy, it’s peak time for project work, and so we agreed to host the hack on a Friday afternoon in our studio. It’s no secret that an afternoon is no time at all so we had to be focused, aligned and strategic about how we spent five hours. The ability to work well within constraints of any kind from time to technical is key to great design. A sprint, afterall, is built for speed – we wanted good solutions in limited time.

What is a success?

We set out to spend time away from our project work, to collaborate with different team members, and to hone our creative problem solving skills – and that is exactly what we did. So, yes, it was a success.

Structuring the day 

Step 1: Introduce the problem (15 mins)

To kick-off the day, we needed a problem to solve. I wanted it to be something that the team cared about, so I let them choose our hack day theme. After a few discussions our sustainability conscious team arrived at:  

How might we encourage people to make more environmentally-friendly food choices?

Introducing the concept is an important stage for exciting the team, bringing the problem home, and getting their creative juices flowing. I kicked-off with the story: the facts about this problem, the shocking statistics and the work that is being done so far.

I shared the brief, which we kept fairly simple: create a digital tool that solves this problem. It was also important at this stage to share what success looks like, of course. In the time that we had, success was ‘a clear user journey, a couple of screens, and a story that gets your audience emotionally hooked’. 

There would also be judging criteria. The teams would be assessed on the quality of their product:

Step 2: Meet the team (5 mins)

Collaboration was key. We wanted the team to work with different teammates and in new roles; a break from their day-to-day. Each team member was assigned their role, based on their strengths and our capability frameworks. 

We are a team of nine people. We knew we wanted two teams of four, one facilitator and each team member to have a specific role. In each team, I came up with four different Hack Day Roles:

Lead: responsible for making decisions, sticking to the schedule, and ensuring everyone was using their time efficiently 

Researcher: responsible for gathering insights, imagery, and useful information to inform design

Maker: responsible for creating the sketches, the screen and any other component that helps convey the message

Storyteller: responsible for delivering a clear, concise and compelling narrative of the finished product

Each role was designed to spotlight skills that transcend our job descriptions; they are integral to every role at 100 Shapes across disciplines. We focused on leadership and guidance, communicating design decisions, and collaboration. And, of course, working within constraints. So it was important to set aside time for the team to introduce themselves and share their main responsibilities. 

Step 3: Understand the problem (10 mins)

The team needed to understand the problem they were solving for themselves. It wasn’t enough for me to just relay the facts. The team needed to empathise; they needed to do the research, gather the facts, put their assumptions aside and learn about the challenges of poor diets and the catastrophic effects on the environment. They needed the insights that would fuel better decisions and stronger solutions. Their research began. 

Step 4: Define the problem (20 mins)

Once the team had a better understanding of the problem, they needed to ensure they were asking the right questions and so they turned to a well rehearsed method called How Might We. Developed by Procter & Gamble in the 70s but widely publicised by IDEO, this technique involved taking notes in the form of a questions beginning with “How might we…’ The results are more open-ended, optimistic phrasing that forces you to look for opportunity and challenges rather than getting distracted by problems, or worse jumping to solutions too soon. The HMW method captures problems and converts them into opportunities. 

These are the HMW statement that the two teams arrived at:

How might we encourage people to change eating habits together? 

How might we help well-intentioned but weak-willed London commuters transition to a plant based, local and seasonal diet?

Step 5: Generate ideas (60 mins)

Time to explore! The purpose of this stage was to think of every possible way we could design a solution to the problem. It is important here to remember that not every idea needs to work — the priority is quantity and not necessarily quality. Weird and impractical ideas often give way to truly inspired ones.

A UX technique that our team began with here was Crazy 8s — a core Design Sprint method. It is a fast sketching exercise that encourages people to sketch eight distinct ideas in eight minutes. The goal being to generate a wide variety of solutions. 

You don’t need to be a designer to do this either — these sketches are quick and rough — they just need to communicate the idea. 

Step 6: Refine Ideas (60 mins)

Equipped with solutions, it was time to refine and refocus; time to make ideas tangible. Time was of the essence. The teams had to critique each solution and decide on which one best solved the problem and could be achieved in the remaining time. 

The focus was then on bringing the ideas to life; finding the most accurate way to describe the solution.

Fidelity didn’t matter. What mattered was a succinct story. 

Step 7: Create Elevator Pitch (30 mins)

Time was really tight here, there were many requests for more time — time that we didn’t have.  The teams solution had to be wrapped up in a presentation deck and tied together by a compelling story. 

I chose storytelling as a success metric because, as a team, it is a capability we are all constantly trying to refine. Storytelling is a powerful tool for a designer so it was important for us to make this another opportunity to flex this muscle and have a bit of fun with it. 

Step 8: Share the story (5 mins each)

The final step. This is where everything came together; the culmination of all the hard work: it was hilarious, dramatic and it was emotional. 

The first team to present was team LowCo2. They created an app that encourages people to create pledges to change eating habits together.  Through integration with Monzo and other banking apps LowCo2 tracks purchasing habits and encourages users to set targets such as “No beef for 1 week”. The app is also linked to social media to encourage users to invite friends to pledges to make changing eating habits more of a social movement. 

The second team then showcased their app MunchWell. Targeting busy London commuters, this app offered different meal options for different moods and price ranges, then offers one meal six ways depending on how environmentally conscious you want to be. This shopping companion finishes off by summarising how green and sustainable your purchases have been. 

For us, it was less about who won and more about seeing the teams come together, introducing an element of competition, and being proud of what can be achieved in such a short amount of time. 

The Learnings

After the day was done, I reflected on a few things that we learned. Here is what I will keep in mind and change for next time:

People weren’t happy being assigned roles

Despite the careful consideration that went into assigning people to new roles based on their strengths and our instinct, for the most part, people were not happy with their new roles. Some didn’t feel excited by research, some didn’t feel confident enough to lead, some people wanted to make and not speak. Next time? Let the people choose! 

People felt limited by a digital product

There were a few worries that focussing on a digital product limited the creative capacity of being able to solve this problem. Why not broaden the scope to the end-to-end service? Why did it need to be digital? Why did it need to be product? It’s all about managing expectations and following a design process. With limited time and limited resources, refining the problem down and scoping out the work was important to ensure that a tangible outcome could be achieved by all.

Time

There wasn’t a lot of it but that was kind of the point. However, when time is tight and a problem is presented, the natural reaction for some people is to jump to a solution right away, which I saw this happen here. It’s natural but it is important to slow down. It is normal for solutions to be popping into everyone’s mind. At this point it’s crucial to follow a process; share what each person knows, prioritise the information, and unpack the problem. Otherwise, time will be wasted on the wrong part of the problem. 

Is it playful enough?

The brief was a digital solution, just like most of our work. If we really wanted to shake things up, maybe next time we could play with physical prototypes. We could encourage the team to use their hands, give them more art and craft material to play with. Perhaps the successful outcome criteria restricted creativity too much. Next time? Be more flexible.

There was no time to create the elevator pitch

Really, there needed to be two makers not one. Next time? Have one visual designer make the screens while another is working on the deck. 

The assessment criteria needs improvement. 

I found it tricky to assess a product in 5 short minutes that was both fun, fair and informative enough to withstand interrogation. It became clear quite quickly that the criteria needed a bit of work too. Next time? Introduce teamwork, innovation, and clarity of concept. Maybe use a checklist?

That’s it

…for now. The real success is knowing that the team want to do this again. So next time maybe we’ll tackle a business problem? Or a problem with a digital product that already exists? Or a specific interaction? Most importantly, we’ll continue to follow through on our commitment to incubation and get the next Hack Day in the diary.