Recently, several Rebooters took part in PDF:Applied, a hackathon leading up to the Personal Democracy Forum’s inspiring annual Gov 2.0 conference.
Now, at first blush, Reboot’s process might seem contrary to that followed at hackathons. As a service design firm, we focus on researching, designing, and building with the users of any solution. How much in-depth ethnography can be accomplished over a weekend, especially with time left for coding? How can we understand and build for people who are typically absent from hackathons?
While their pitfalls are well-established, there is something important that happens at hackathons which underscores a second pillar of our thinking here at Reboot: prototyping and fast iteration. Hackathons allow us to quickly, easily experiment, a luxury that our client work doesn’t always allow. The best hackathons mix problem-solving with a spirit of play, and provoke intense bouts of creativity under severe time constraints. With this momentum––and the support of talented, civic-minded developers in attendance––we can get a testable minimum viable product in hours, not months.
The most successful hackathons include passionate ‘problem owners’, participants who champion a particular issue at the event and who provide a unique view into the processes they seek to improve. To this event’s credit, representatives from organizations such as the MTA, NYC DOITT, Common Cause, and the Public Advocate’s Office participated in PDF Applied. These organizations demonstrated an eagerness to engage the technology and design communities beyond their walls, and are to be commended for their willingness to go outside and experiment.
Here’s a window into the process by which two teams that Reboot participated in went from idea to demo-ready prototype in 12 hours.
PDF:Applied allowed anyone to post problems online that they’d like to see tackled in the days leading up to the hackathon. These were voted on, and the ideas were recounted soon after the event began. Participants then chose which ideas they found compelling and quickly built teams around them.
Choosing which project to work on is always very difficult for me; I tend to be torn between a couple of options. In the end, I chose to work on an effort to address election day obstacles to voting by crowd-sourcing real-time reports from voters. This project, which we christened PollWatch, was compelling because the problem owners were at the table and were committed to support what we helped them build (specifically, Susan Lerner and Sam Massol of Common Cause NY Kathryn Peters of TurboVote). My Reboot colleagues Mollie and Panthea hit on the same strategy, and focused on working with a representative of the Public Advocate’s Office on an app to make FOIA requests easier for both citizen requesters and the government officers who process them.
At a hackathon, the process of deciding what to build tends to be messy; even rough consensus can be an elusive task. Process-wise, we started by framing the problem, determining the constraints (of time, technology, and know-how), and brainstorming what can and should be done.
With a good deal of guidance from our problem owner teammate, my team worked to scope the problem into something that could conceivably be built in a single weekend. This ultimately meant developing a first version that is less inclusive than we would have liked. The current app works on any phone that can browse the web; an SMS-based app planned as a next step, for those that don’t have mobile internet.
After thinking at a high level about the system’s goals, we put ourselves in our users’ shoes, and thought about ways in which they might interact with the system. This is, of course, no substitute for real user research, and both teams plan on doing just that in the coming weeks.
Thankfully, the PollWatch team had several voter engagement experts (from organizations such as Common Cause, TurboVote, and Rock the Vote), who understood potential user scenarios: how a voter might discover our service, how they might go from seeing a problem to reporting it, and how election monitors could take action. Simplicity was valued above all else for the tool, both for the sake of the voters, monitors and (of course) for the developers working on a tight hackathon timeline.
The OpenUp NYC team had subject matter experts as well. Representatives from the NY Public Advocate’s Office and from Reinvent Albany had deep expertise in the workings of FOIA request system: the types of information citizens seek, how they can file successful requests (and what may prevent their request from getting process), and how a NYC Request Access Officer may process––or be incentivized to process––the requests he or she receives.
With the basic system mapped, we launched into design and development. For the development, this entailed finding data sources (and some scraping) and building an app with Ruby on Rails, HTML, and jQuery. On the design side, Mollie did a bang up job creating a visual style for her team’s app by doing a quick survey of leading design trends in successful user-friendly web tools, then whipping together a clean, fun and eye-popping look.
Our teams were blessed with substantial talent on this front: John Yung (a winner of NYC BigApps) and Volkan Unsal (rockstar Rubyist at a TechStars start-up) on my team, and Eddie Tejada (a fellow CfA’er!) and Adam Becker (creator of GovHub) on the OpenUp NYC team.
The rest went like this: Code code code. Build build build. Have a beer or two. Sleep a bit. Code code code. (Shoot, we need a presentation!) Demo!
The downside of hackathons are by now well-known. While the best organizers try to diffuse these, some are simply part of hackathons’ inherent structure: loosely affiliated groups are building to demo, so the incentives are not aligned towards fully realized apps or elegant, maintainable code. After the event, coordination problems around finding times to meet or work on the project are the norm, and sink many a good project.
Yet, there is something beautiful about the time constraints hackathons introduce. At their best, they push designers and developers to work hand-in-hand to uncover what a truly minimum viable product really looks like. This frame pushes us to be creative in how we examine and develop possible solutions and can inform work far removed from those scant, heady hours in which the hackathon runs.
Our teams won first and second place and presented the projects on the main stage at PDF, and are both continuing to work on their projects. Look for more news on PollWatch and OpenUpNYC.
