This is a post I have been sat on for some time. In fact the date of the day in question was 01/02/2016 so some details are going to be a little inaccurate but hopefully the essence is maintained.

Once upon a time I participated in a hack day where not a single line of code was written. “Hang on”, I hear you cry. How can you have a hack day without doing any hacking? Indeed, this is exactly what I was wondering. Looking around the Internet for definitions and details of hack days, the vast majority of them talk about technology and software as a core part of the day. However, there are a number of information sources where hack days are discussed in the context of no software hacking being involved. I think in these instances it is better to think of the day as a product ideation day which is exactly what it turned out to be. Not quite as snappy a title as ‘hack day’ though 😉!

With that cleared up, what was the day like?

What did we do during the day?

  • Met new people
  • Selected a user need (from a pre-defined list)
  • Fleshed out the user need (with a micro-persona and acceptance criteria)
  • Expanded on the solution/need
  • Refined the solution
  • Created a (paper based) prototype
  • Carried out user research (with members of the other groups)
  • Iterated the solution based on feedback
  • Replayed it all to the group (providing everybody a chance to see each others prototype and gain some insight into each group’s thinking)

Outputs from the day

Beyond the opportunity to meet and work with (potentially) an entirely new group of people, thinking from a number of different POVs is a really refreshing exercise. Empathising is an underused skill by most people and this day really requires people to empathise. A lot. From thinking about how a person/people within a set scenario might actually be feeling and how that translates into generating their ’needs’ to thinking about what the future might look like for them individually and society as a whole. From understanding the new people you are working with in double quick time in order to combine to form a productive group to thinking about how other groups saw the challenge and solved it. The process is much more important than the outcome in days like this.

Changes I would make for future days

  • Name the day more clearly (it helps to set expectations early)
  • Ensure the constraints being worked within are well understood by participants e.g. it needs to be something possible to build tomorrow vs something that might be possible in 5 years time. This helps prototypes to be of a similar ‘feel’ rather than having some being current period solutions and others being far-future Sci-Fi dreams! Unless that is what you want in which case go for it.

Summary

I enjoyed the day and will look to participate in future days. I highly recommend others getting involved given the chance. And if not given the chance it is reasonably easy to set something up yourself.