On Monday last week, Nayeema, Benji and I took part in a hack day with colleagues in Leeds.
We’ve used hack days to develop ideas and focus on a user needs led approach. Although it’s called a hack day we tend to avoid writing any code because paper prototypes allow the whole team to be involved in ideas.
One of the most important features of a hack day is putting known constraints to one side. Many of us have years of experience of why things are done in a certain way or cannot be done in another. Hack days are about understanding user needs and seeing what could be done to meet them.
This post is about how we set up and run our hack days.
First things first
It requires planning. You shouldn’t expect people to just turn up and start having ideas. The day needs to be grounded in solving something or meeting a user need. These are the things we organise before the day to make sure it runs smoothly:
Prior to the hack day you should have a list of user needs you want to try and meet. This can come from lab or pop-up sessions and it doesn’t have to be definitive. Having real needs helps keep the teams focused. We’ve written about how we’ve identified and defined user needs – this might help you. It also makes creating a persona and writing acceptance criteria much easier.
Make sure you have a room all day with plenty of wall space. People will want to stick stuff up and see what others are up to. Have plenty of pens, paper and post-its ready.
We’ve found a good size team is about 4-5 people. Have your teams planned before the day and where possible cross functional so that you get a range of perspectives. It saves a lot of time not having to sort this on the day.
It might seem a lot, but get everyone who is coming to commit to the whole day. Having to pop out for an hour here or there means people miss big sections of the day. As there is so much to do, it often means it is hard to catch up.
On the day
Where possible, have some examples of the things you are expecting people to create, i.e. personas. For people new to agile and the hack day idea it might help to have a practical example. This is the outline agenda we use for our hack days.
Clarify the challenge (1 hour)
Understand the user need. Create a persona, write acceptance criteria for what a good solution would do. Think about the who, what and why. It’s much like a very short inception.
Idea generation (1.5 hours)
Come up with as many ideas as possible. These don’t need to be in detail at this point. Avoid being constrained by what you know and think about what would best meet users needs. This could be a list of bullet points, a sketch or a flow diagram.
Have a break (1 hour)
It’s important to step back and have some time away to come back ready to work on the ideas in detail.
Review ideas and go into detail (2.5 hours)
Go through the ideas as a team and pick the best three. Then spend 15-20 minutes going into detail. Once done, review again and pick one to turn into a product ready for user research. (This is a great chance to create a hybrid, picking the best parts of multiple ideas.)
User research (1 hour)
One person from each team goes to another team to test the idea. This person takes on the persona created by the team in the first session. They then use the product while the team observe them making notes of where it does and doesn’t work. The team can then use this feedback to iterate what they have made.
Tinker time and prep for show and tell (1 hour – sometimes the next morning)
An hour to iterate based on the feedback from user research before getting ready to present back in a show and tell. Each team has about 10 minutes to tell what they did, why they did it and what they learnt from the testing.
Our day in Leeds was primarily about working together, however there were some great ideas to test with users in the future.
If you do anything similar we’d love to hear about what works for you.