I WON A HACKATHON

I took part in my first hackathon, one that was hosted by General Assembly and Socrata. We had 2 UX designers, 2 data science guys and, 2 UX designers. The goal was to create an actual application or a functional site that performed a public service for the city of Seattle. 

By the way, Socrata is a baller organization. That's not just lip service. They help local governments and communities compile large sets of data and format all that data so that it's openly available to any developer that wants to take a crack at doing something with it. So they've got data on healthcare, on street signs, on number of evictions, on pretty much everything from the departments of a city. And the city pays Socrata to compile it in an easily importable and searchable format. In turn, Socrata charges nothing to developers, with the hope that they'll turn all those data sets into some sort of a civic game changer. 

I don't know if there's any money in that model, but if there is, it's just about the best way to make money of which I've ever heard.

After an hour snow delay, we had to build this thing in five hours. The first 30 or 40 minutes was spent haggling about the nature of the site. Basically, we knew we had to use some of Socrata's data but didn't have a great understanding of everything contained therein.

So we thought, 1) We could make a topographical map that allows bicyclists to find the flattest (or steepest) routes. 2) We could find city complaints against landlords to find the most vulnerable pockets of folks in Seattle. 3) We wondered about mapping food deserts. 4) We thought about using parking data to make an app that displays open parking garages. 5) We pondered doing a real estate app but figured that it would make for much of a social good. 

So we settled on creating a website that calculated the number of car accidents that happened in any given intersection in Seattle. We called it "Sketchy-section." 

The weird thing was that, from a UX perspective, the whole process seemed backward. We looked through the datasets and found one that was robust enough with which to work. Then we figured out who the users of that information would be and how to present that information to them. Then we figured out what the user's problem would be. So, unlike the standard UX process, we only had enough time to start with the solution and work our way back to the problem. 

Agile process is so fast that I imagine this to often be the case. The rapidity and volume of agile is both its great strength and its weakness. Actually, artists also cheat this same way all the time. An artist is told (over and over) that the process and the story of their art is what is most important by that same artist is shown (over and over) that was is most important and valuable is the finished product. So usually what happens is this: An artist turns off their brains, whips out some wilding splash of human originality, and then, retroactively, figures out how to explain what they were thinking, phrasing it as though they had been high-mindedly philosophizing the whole time. 

Oh, and even though I'm overthinking it, we won. Our team won the hackathon. Thought I should just slip that in there. We killed it. 

We found a juicy dataset, which was traffic collisions in Seattle. We found that accidents are reported to the city via closest intersection, the cross streets of which could be mapped (and even heat mapped) to specific intersections. The idea was that, if you thought there was a sketchy intersection in your neighborhood, you could type in the cross streets and see the actual statistics of accidents there. That seems like a pretty straightforward piece of information that should be available to citizens but that data is almost impossible to find.

Originally, we wanted to compare accidents to locations of stoplights to see if we could find spots where a ton of accidents were happening that didn't have signage but should. That didn't really work out. The data wasn't super clean and we found out that we couldn't access some of it more than 2000 times in one go without paying a fee. Ultimately the Data Science guys wrestled with the set for four hours or so and ultimately found a corollary, but not one that made for a good story or application. Which is one of the problems of data science. It takes a lot of work sometimes to test a theory, to scrub a dataset, and after a ton of math and programming, the answer is "there's nothing compelling here." Which is a perfectly valid and acceptable result of an experiment. It just doesn't work well in an agile sprint or hackathon. 

So we were left without a second vector to compare to. We just had a big list of the locations of car crashes. The development guys sweated for hours on how to translate that set of coordinates onto a Google map. It took forever and, in the meantime, us UX designers were left sitting around. Eventually, we decided to start working as though the project had already been completed. Ramon, the other UX fellow is flabbergastingly good with visual design, so I started him on designing the assets for the very simplistic page, as well as for the powerpoint presentation.

I went around, surveying everyone in the room about something I already knew was true. I asked them if 1) they knew of a sketchy intersection, 2) if they actually knew how many accidents had happened in that supposedly sketchy intersection and, 3) where they would try to find that info if they needed it. The predictable answers proved true. Everyone knew of a dangerous intersection, no one actually knew how dangerous it was, and no one had any idea how to find that information other than a Google search, which was fruitless. So even though we couldn't compare a second dataset to a first, just by laying it on Google Maps, we were created a fairly basic service that the City of Seattle had never provided. In less than five hours. 

Okay. Actually, that's pretty neat. Click the image to check out Socrata.