This project, created initially at a weekend hackathon, is about rapid user needs discovery, rapid empathy, rapid prototyping, and a passionate mission.
SNAPMAPPER: "A YELP FOR FOOD ASSISTANCE"
The problem: As uncovered by my partner on this project, Angela Woodall (then of the Oakland Tribune), many people on food assistance (CalFresh, the California implementation of the nationwide Supplemental Nutrition Assistance Program) had real trouble locating CalFresh-accepting stores that also offered fresh, healthy food at a fair price with respectful service. Though the Federal SNAP web site (which was not at the time mobile-friendly) could show name and address of participating stores, there was no qualitative or quality information. Which left many people, who often worked at job sites that varied day to day and traveled on public transit, to have to resort to a hit-or-miss method; too often, with their limited time, they'd only be able to get to one store, which was often a bodega, a liquor store, or a gas station – and their kids wouldn't have healthy food. And even if they eventually locate a reliable, fairly priced, and healthy store, that information remains in their own mental silo.
As a process story, this is a story about collaboration and speed. We took this idea – that people need a way to post and share honest evaluations of CalFresh-accepting stores – to the Alameda County Hackathon. We were lucky to find a few people to join our team who could handle server management and database creation, and we went to work.
I began by leading a design exercise in which we distilled Angela's reporting to personas, scenarios, and user needs. For this app, it was fairly simple, and we wanted to keep it constrained; the story I opened with is true for many, many people. So the question was: How can we help people who have to get from A to B to C, usually on public transit, see where they can shop, and find which is the fairest and best place? This suggested a map and transit interface, as location was everything to our users.
Team members went to download the public data from the Federal SNAP web site, clean it for Alameda county, and set up a server we could serve the app from (we'd learned from various research that the plurality of our target user base had web-enabled smart phones, though not predictably any particular OS, so we made the choice to build this as a web app). I began sketching and building the front end using jQuery Mobile, which I was just learning. This allowed us to rapidly create a live and responsive interface using standard Web technologies.
I was able to incorporate the Google Maps API and Alameda County's public API for public transit, enabling a real interactive map with transit routing (please don't ask for details; I'm not sure how I did it back then).
Given the very constrained timeframe – two incomplete days – I also focused on leading development coordination, keeping track of what needed to be done in what order, what was holding things up, and helping our team collaborate when we could. We were able to get it running live with enough time to do some actual testing with volunteers from other hackathon teams and Alameda County officials; though we only won Second Prize for the day, the county's Department of Social Services asked if we could develop it fully for their office. (Long story about our handing off development to another group which went nowhere – but I'm glad to see we inspired a similar project at Code for America.)
In Conclusion
What does this illustrate? Not my best visual design, that's for sure. But it shows I can work closely in a more-startup-than-startup environment with a range of team members, learn and experiment with new things on the fly, and deliver.