The Warrington-based flood digital team recently organised its first hack. Over two days #Floodhack2018 aimed to develop, build and test a product concept that could sit within the flood information service.
If you’ve not heard of hacks, they’re dedicated problem-solving and design events in which a development team has free rein to collaborate intensively on a project with a specific goal.
With 4m users, our service caters for a huge variety of needs and provides vital guidance about what to do before, during and after flooding in England. We also generate timely flood warnings and likely impact information, as well as river level forecasts and long term flood risk estimates.
We conduct a lot of research with users to learn about and validate their needs. Many prefer to ‘pull’ their information from the service proactively. Others choose to have it ‘pushed’ to them in the form of automated alerts.
Deciding on a goal
We’d been researching and prototyping personalised alerts for a while and the hack presented an excellent opportunity to explore
how we might integrate them into the main service in order to reach more users and provide richer experiences.
The team agreed to explore a feature that might allow users to set up their own localised river level warning thresholds. They could then be notified when these thresholds were reached, or forecast. This would, the team hypothesised, enable users to customise an aspect of their flood risk and take meaningful action earlier.
Eyes on the prize
Productive hacks require discipline and belief. It’s important for participants to avoid distractions and book time away from ‘business as usual’. There’s no fixed template - anything that contributes to a spirit of enterprise and ingenuity is useful. For instance our hack was opened with guest speaker Terence Eden who helped set the tone with an upbeat vision of hack culture. He also reminded us to set realistic goals, stay focused on a single objective and avoid getting sidetracked.
We had about 20 attendees - from product owners and subject matter experts to software developers, analysts and designers - so there was always a lot of energy in the room. The trick was to harness it all in a structured way and retain focus. The team naturally split into specialist groups to develop different parts of the overall solution - a minimum viable product (MVP) that could form the basis of a fully developed product.
Planning was important so that attendees would hit the ground running. Not only in determining the focus of the event and our practical needs, but also how we organised ourselves; which tools we’d need (a development environment, for example) and a communications plan for sharing our progress and learnings with interested parties.
We’re already familiar with Agile as a delivery methodology so we were comfortable using time-limited bursts of effort, regular reviews, and progress updates to validate the project’s viability and move it forward.
Ideas becoming things
It didn’t take long for user needs to morph into prototypes; scribbles on a wall became low-fidelity wireframes, which in turn evolved into developed pages online. Halfway through the morning of day 2 we had a fully working user journey ready to put in front of some users we’d asked to help us out.
In a side room our researchers contextualised these users’ real-life experience of flooding before probing their typical behaviours and responses to what we’d built. We even sent them a simulated text message we’d mocked up.
Drawing on our wider experience of user research methods, we:
- controlled the user research environment
- broadcast live audio and video to the whole team next door using screen share software
- recorded video files for scrutiny later
- set up two-way messaging with the team during the sessions
As always, the users provided a wealth of vital feedback about online discoverability, product usefulness and overall usability.
Learning at pace
Once underway, the event’s momentum swept us up - we reached consensus and made decisions quickly, with no time for close scrutiny and detail - just a broad brush approach to test and validate concepts and ideas.
We built stuff, we broke stuff, we scribbled, we prototyped, we threw stuff away, we user tested and more than once ran into a dead-end.
A retrospective at the end of our hack revealed a strong sense of accomplishment - being part of something that could benefit users was seen as enormously rewarding. Yes, it was intense and all-consuming, but it was also democratic: everybody had a voice. And, above all, it was fun.
We took a lot away from those two days - the prototypes we created have been banked and reused in more user research sessions. And the insights we gained will help us prioritise and plan our product development portfolio. We’ve also fed back the lessons learned to our wider team, spread word of the hack’s benefits across our organisation and raised our profile in the communities we serve.
Why not give it a go?
Our hack was not only a chance to create something special, but it was a focused, team-building pursuit in its own right. If you’re considering it, here are some pointers:
- Visit the venue: check it’s big enough and is accessible
- Tailor the space to your activities
- Agree the event size - just your team? Or a wider group of stakeholders?
- Share the wifi password - is the network sufficient for the team’s needs?
- Set up online communications that enable those offsite to follow and contribute (Twitter, Periscope, polling apps, such as sli.do)
- Prepare any data or other structural information you’ll need, and make sure it’s accessible
- Plan how you’re going to test the usability of your prototype or outputs - will you pre-invite users to the hack? Remotely moderate them via screenshare? Or can you source nearby users on an ad hoc basis?
We’d be happy to share our experience if you have any questions. Feedback on any of the screens pictured is welcome, too. Use the comments section below, or email us at: floodresearch@environment-agency.gov.uk
You can also follow our progress on Twitter (@FloodDigitalEA)
