DWP Sheffield is a young hub. We just hosted our first hack. And with all the unearned confidence of youth, I'm going to tell you how to host your own, based on our limited experience.
I'm James, a content designer in DWP Digital.
We tried to solve an issue that emerged from a real project - though one that is currently outside of our remit. By getting talent together from across the government and digital scenes, we hoped to get a head start on something we’d inevitably be tackling.
We were trying to help jobseekers identify things - by themselves - that could help them find a job.
This is what we learnt.
Don’t just invite digital folk
Cross-government means everyone across government.
We purposefully invited work coaches, as subject matter experts. But we also invited people from policy, strategy and any other discipline that would listen. Why? Not only do they get to see what we do, they get to do it. It makes our work less mysterious and turns them into collaborators. People often complain of the gulf between policy and digital. It was the policy people who, arguably, enjoyed the hack most. Events like this help to bridge the gulf between policy and digital.
Plan to improvise
Hacks may seem chaotic, but that chaos is ring-fenced. There are so many issues you won’t consider till the 11th hour. How many power sockets are there? Is this a competition or not? Do we let people choose their own teams, divide them up or assign them by role? There will always be issues you can’t plan for in advance either, so you’ll need to make sure there are some good improvisers on hand at all times.
If you’re going to test, provide research
We’d roped in some people from our building as mock-users, for usability testing. However, we routinely referred to this as ‘user research’. Some teams ended up trying to work out user needs from people who weren’t actually users, rather than testing if their ideas/prototypes were workable.
This hack operated as if the attendees had arrived in the midst of a project. We should’ve provided some concrete research (users needs, personas etc.) for the team to build on. If you’re testing a user interface, fake users could work well. But make that clear to the attendees.
Set a clear objective, with a bit of scope
What kind of hack is it? Are you trying to get a functioning thing or a good idea? Specific problems tend to produce specific prototypes; broader issues produce a broad variety of approaches.
Both are great. But make sure you know what you want. Narrow - but unclear - objectives lead to frustrated teams.
Don’t obfuscate
This subheading is terrible content design (I mean, who uses ‘obfuscate’ in everyday conversation?). But using project specific terms - or the many, department specific acronyms we love to hate so much - isn’t much better.
Your hack’s problem statement should be a sentence or two at most. In plain English. You should also get to the point, rather than forcing attendees to wade through multiple paragraphs.
Don’t take feedback personally (unless it’s great)
At our hack, there were many ways attendees could leave feedback. Almost all of it was positive. Everyone had a good time. But we respected the people who told us about the areas we could improve too.
Despite the few things that went wrong, a lot went right. And in the true spirit of iterative design, we’ll be planning more hacks and incorporating that feedback. There were even murmurs of other Sheffield departments holding them too.
Do host your own
Show us how it’s done. But make sure you invite us. Hacks are a great way of bringing talent together to solve a problem. And a great excuse for pizza.
DWP Digital is recruiting. To find out more visit our DWP Digital Careers website and have a look at our LinkedIn page. You can also subscribe to this blog and following us on Twitter @DWPDigital and @DWPDigitalJobs.