Sometimes people ask what it’s like to be a Code for America Fellow and work on things like LocalData. By my expression, they quickly garner that it’s hard work. But as demonstrated by the tale of LocalData user research, it’s also exciting times.
LocalData is a toolkit that helps groups collect place-based data. For example, you could note the condition of all the houses in a neighborhood. Or you could record which houses have elephants outside. Then you could create outreach strategies for your neighborhood, or you could study connections between vacant structures and elephants. Tremendous!
Creating LocalData has been both hard work and exciting times. Imagine something that tastes like Pepsi but looks like 7Up. Incredible! (As an oldie-locks, I don’t have to imagine such a magnificent unicorn. I was there.) But what activity could make the fellowship so wild and yet so sophisticated, so dangerous yet fortifying? User research, literally on the streets of Detroit.
An urban planning class at Wayne State University wanted to use LocalData to assist their capstone project. They planned to survey all the commercial properties in Detroit and record oh so much information. We hadn’t targeted such detailed surveys nor tackled the subtleties of commercial properties. But these poor souls needed to collect a whole mess of data, and they were going to let me follow them around, creepily staring and taking notes. Cha-ching.
I arrived in Detroit, ready to walk slightly too close to some data collectors and trip over things while writing. Then arrived my first user revelation: they were not going to walk. These students needed to survey miles of units, all over the city. Of course they would drive around.
They had divided into teams of one driver and two data collectors. One collector would look out the right-side windows, the other the left. It was a pretty effective system, which we hadn’t considered when designing the mobile app. I found a team that would let me ride along, thinking, these guys will look out for me, and it’ll be fun, safe times.
I’m only superficially familiar with Detroit’s geography. I got to the meeting point okay, but I didn’t know the area. The team assured me that my car would almost probably be there after our session. Detroit gets a bad rap, but every big city has rough parts of town. The trick is, if you don’t know a city well, you could end up in a rough part of town, crammed into someone’s car, with the top down, driving real slow, trying to take notes, clinging to a laptop bag, while everyone else in the car is staring into a shiny smartphone. That’s what you want to avoid.
Overall, the ride was not really too bad. But there were specifically three moments of worry, here in ascending order of concern:
- Early on, while I dug around for my fountain pen, the team informed me that we were at maybe the worst intersection in Detroit. Then they pulled over and started discussing the condition and use of the adjacent parcel. Cools.
- Some of the commercial units had long since stopped being corner stores or sandwich shops. A few had hasty paint jobs, blacked out windows, metal doors, and cameras pointed at the entrance. Okay, guys, let’s mark that as “unknown” and move on.
- At some point, we were stopped in a turn lane while the team was surveying. A police car pulled up and was not too happy with us. This was the worst situation, because at that moment I thought, oh no, I might not finish my user research. Luckily, after I explained our work and affiliation with the City, the officers got bored with us. Being boring has never worked so well for me!
Even with the worry-spectrum covered, I wouldn’t trade that trip. First of all, it was pretty exciting. Also, it was totally invaluable to see our work out in the field, and it’s great to work on so many pieces of the product development cycle. Because you’ve powered through this serpentine tale, I’ll share some of what we learned.
- Phones run on batteries. The teams learned to bring car chargers and plug in, but we also tried to reduce GPS usage and network activity, to help with battery life.
- Some parcels of land are super narrow. We try to visually differentiate parcels, so you can enter data about the right one. We realized that we need another level of zoom.
- Sometimes the users would pan around the map, but then they had trouble returning to their current location. Instead of constantly tracking location, which was restrictive and battery-draining, we provide a Locate Me button.
- The technical descriptions of a building’s use or condition are not always the most helpful in the field. Plain-language explanations help the user determine if a building is “good” or “fair” and what it means to be “institutional.”
- If you’re going to be suspicious, you should also be conspicuous. Not much our mobile app can do, but teams doing this work often have name tags or some display of affiliation with a reasonable organization.
Leave a Reply
You must be logged in to post a comment.