It’s a couple of weeks after our second Hack Day at Which? and, as always, I am amazed and humbled by what our teams can design and build in just 8 hours. Hack Days, if you’re unfamiliar with the format, bring experts together to solve problems, try out new ideas or technologies, and build something that might inspire a new feature or product. It gives teams the opportunity to ask the question “What if?” and build something innovative…and it’s not just for the big tech players like Netflix or Spotify. The value of Hacks are recognised cross-sector and by many organisations, such as the NHS ”Making NHS IT less bad”, TfL and healthcare charities. There are many “Hack for good” initiatives so lots of opportunities to get involved. So how did we organise the day and what did we produce?
“Innovation in Campaigns”
For this Hack, the winning theme came from our Campaigns and Communications team. Which? have been successfully campaigning to improve the lot of consumers for many years. Did you know, for example, that Which? successfully influenced legislation for the mandatory use of child car seats, rear seat belts for adults and the freedom to view your medical records? We were asked to focus on three current campaigns; scam emails, nuisance telephone calls and train delays. The brief specifically excluded traditional campaigning methods:
Digital campaign hacks that reach new audiences, make an impact, empower consumers to help themselves…NOT traditional campaign tools – no petitions, no pledges, no emails to target…
There were lots of ideas ranging from mobile games to an Amazon Alexa skill to complete your rail delay form. I submitted an idea for a mobile app focusing on “reach new audiences”. I should say at this point, that I am not a front-end developer, and these days I only code at home…so a weekend later, after playing with React Native and a native camera plug-in, I settled on using the Google In Vision API to analyse a photograph of the train platform arrivals/departures screen. Extracting information such as expected departure time and delay reason would afford some witty way to either share on social media (with or without the photograph), or maybe keeping a running total in the app, ditto the same purpose… #MyTrainHell.
I was surprised that the API’s Optical Character Recognition (OCR) service could retrieve the relevant information as well as it did, however, it did need a fairly precise photograph without any background noise like other signs, commuter’s heads, umbrellas, etc. Of course, a station besieged by commuters yearning to get home is just brimming with background noise. In fact, the process of trying to obtain a suitable photograph convinced me that the effort required would outweigh anything that my powers of humour could muster for that social media share!
So my idea didn’t make the cut…but thankfully Danni, in our UX team, had a similar idea which did. It wasn’t reliant on fighting to get the ideal camera angle on a busy platform but did focus on reaching and engaging new audiences in a playful way. Ideal. I signed up and found myself on team “WE DON’T HAVE TIME FOR THIS” alongside four eager team mates. Our idea was to build an app that would keep a running total of train delays with a call to action to share on Social Media and/or provide a “I’m running late” email function.
The white board sessions were good for getting to know everyone and Erin, our Campaigns team rep and expert, furnished us with lots of valuable information from user feedback and the types of apps out there in the wild. It also meant the original idea had morphed from a quirky social media engagement app plus rail compensation using the National Rail Darwin API. Hmm…all in a day? Jamaine, the only front end developer on our team, looked worried. We had the API work covered with Rubyist Slavka on the team but I began to think that a weekend beginner’s course in React Native hadn’t furnished me with the front end skills required for this endeavour.
Thankfully, a second whiteboard session resulted in some hasty scope negotiation, and we decided to re-focus on the original idea. Afterall, other teams were building rail compensation apps and there are several in the marketplace already. Maybe a dose of gamification would distinguish us from other teams at demo time? Well, that and a little touch of gamesmanship! At a previous Hack Day, a team had built a React Native app in a day for both iOS and Android. I like to think that in this case “borrowing code” constitutes “learning from best practise”! So, furnished with some borrowed React components, we began our day hopeful that we could be the winning team.
So did we? Well, we got an honourable mention from the judging panel but were pipped to the post by the “Rail Fail” team; a mobile app that prompts and monitors rail delay compensation claims. The sheer weight of front end work meant that we didn’t complete as much as we’d have liked, and the only part of the app we could claim technically worked was the station and route look-up.
Although it would have been nice to have a fully working app, it’s all in the demo, and we craftily loaded Lisa and Danni’s design and UX work into the app as images. It looked great and gave the judging panel a really good flavour of what we were trying to achieve. On the day, we expanded the idea to include badges and screen backgrounds driven by weather data on the day of travel, and a much more comprehensive leaderboard and gaming idea…”turning train delay misery into fun”.
It was great to be part of a team on the day, rather than as a facilitator, and I loved learning more about React Native; you can’t beat that “Hello World” moment! If you’ve been the “Most wasted this week” why not find out about your compensation rights and Demand a better rail service?
Organising the Hack
We stage at least two Hacks a year timed to fit in with our budgeting and project initiation lifecycle. The timing is important; we don’t want to lose brilliant ideas…our hope is to take innovation forward into production.
As an organisation we can’t support a full Hack week (or more than a day) so it’s important to allow enough time in the run up to the day for teams to meet, discuss and plan. It’s also a good opportunity to publicise the event within the organisation and build some anticipation. We allow 5-6 weeks before the actual day and the schedule looks a bit like this:
- Week 1-2: Themes
- By inviting other departments to submit a theme, we can solve new problems and showcase our innovation. It’s also a good way to bring teams together.
- Week 3-4: Idea generation
- Anyone can submit as many ideas as they like against the theme. Anything goes as long as it falls within the theme.
- Week 4: Dotmocracy voting
- Each voter distributes x number of votes across as many of the ideas as they like. The ideas with the most votes are taken forward to build.
Week 5: Team up & whiteboarding
- We ask the team to choose something that they would want to work on and sign up to an idea. We encourage people to think about cross functional teams so each team has the skills it needs to be able to deliver a working demo. One day isn’t long so we allow each team 2 x 1 hour whiteboard sessions to formulate a plan of attack and clear any blockers e.g. great time to sign-up for API keys. We encourage our experts to attend these sessions and support the team providing much needed user feedback and domain knowledge.
- On the day
- Coding starts at 8 and finishes at 4 with demos shortly after. A sumptuous breakfast, lunch and as much coffee as required is provided…hopefully it makes up for the earlier than usual start! Demos are strictly 5 minutes long, including any questions, and are judged by representatives from the corporate leadership team. When the duck quacks it’s all over! (It helps to have an amusing timer sound)
Future Hacks
I was interested to read about how Spotify have hacked their Hack Week and added “Fix it week”. The reason for the change; to acknowledge that fixing existing bugs and improving user experience holds as much value as innovation. Every organisation has those user stories that just don’t seem to make the cut for Sprint but nevertheless would add value. Or maybe focussing on improving tooling and the delivery pipeline would reap rewards for your team? Another angle might be to work with another organisation which would be good for cross-pollination of skills and could lead to some interesting collaborative projects. I think these ideas have potential but having the freedom to experiment – especially if it’s one day rather than a week – is very liberating and makes it feel less like work and more like self-development and team building. And dare I say fun?!
