What is a “legible” city?

Presenting at NYU’s Rudin Center (slides here), I used the notion of “legibility” to frame our work building citizen/passenger-facing systems like MTA Bus Time, Shareabouts, and OpenTripPlanner here at OpenPlans.

I actually borrowed the notion from The Center for Urban Pedagogy, though I approach the process with a slightly different toolset. Legibility imagines the city as a text: what is left as a hermeneutic exercise is to understand and make concrete the semantics of the city, the hidden dimension (“intent”) of the city that is performed on top of the built physical infrastructure we probably more commonly think of as “the city”. And to bring in our friend Latour to complicate things even more, this performance of the city includes not just citizens and civil servants as actors but also the systems themselves: transit lines and schedules, land use policy and building codes to name a few examples.

A single subway trip, for instance, is literally a performance of the published schedule. The train operators, the train and stations themselves and we, the passengers, all engage in a dance of sorts that approximates, but never equals, what that published schedule would imply. Interpreting quantitative and qualitative data and observations to find out what went wrong between striving for our ideal and the reality, and improving the reproducibility of good performances is the task of civic consultants, folks like us at OpenPlans who are working to make cities run better. In fact, articulating the ideal to which we’re striving is a primary task in itself–one Shareabouts in particular hopes to help facilitate.

And it’s important to note, everyday users of these systems don’t care so much about the “why”, they care more about the “how” (do I get around the issue). So our approach to legibility needs to be “radically collaborative” (or maybe better, radically integrative), and ultimately be about giving citizens agency in their interactions with the city.

So what exactly does this mean for practitioners? I’m going to offer a initial working framework, and then some examples to help answer this question. My current working conception of legibility is three-fold:

  • A city where outcomes are understood. Cities are comprised of both a layer of infrastructure and and of politics, and empowerment (to a certain extent) is enabled by outcomes being (or cynically, just seeming) “legitimate”. Why was my train late today? Why was my bus stop moved down the street? Why did I get this letter in the mail that says I was denied for a public benefit? I believe insufficient answers to questions of understanding are at the core of people’s frustration with government. Metahaven rightly calls out this epistemological question of legitimacy as one of (brand) rhetoric in their book Uncorporate Identity.
  • A city that is plural. Cities are comprised of many different individuals, all with different needs: therefore, systems that serve as an interface between the city and those same people need to be equally diverse. Or customizable: not everybody has the same objectives. There are many truths to be found when interpreting the city. The obvious thing to discuss here is language localization of software, but a less obvious example is the use of “developer APIs” by government. APIs privilege the provision of information itself over any one particular delivery channel, and that challenges (but does not eliminate–”raw data” is not values-free) a “the medium is the message” approach that privileges one interpretation of the city over another.
  • A city where choices are made explicit. This is the toughest one, I think. It’s easy to provide false choices when the framing of a problem is as narrow as it (necessarily) needs to be to create a successful digital interaction, one that can be used in 30 seconds or less. Given my train is late, what else can I take to get to my destination? What is my course of action now that I’ve been told I’ve been denied this benefit? My bus stop was eliminated due to lack of funding, how can I help in the fight to restore that funding? This may be the most problematic because it is the only of the above three points that “sells” a future before it exists.

I recently learned of an exciting project that really struck me as an effort to make things legible: Dr. Kari Watkins’ OneBusAway Ambassadors Program. The program invites local transit enthusiasts to get a more “insider view” of local transit operations by visiting transit facilities and talking to operations engineers at the transit agencies. The idea is to help the ambassadors understand what might be happening when things go wrong (i.e. buses not appearing on the real time information system, etc.), and then let those individuals help the transit agency with outreach efforts and with responding to issue reports or customer complaints. This approach is exciting because it expands the customer service capacity of the transit agency in a novel way, builds on informal networks of expertise/interest and, at its core, is about making things legible to people who will then help make things legible to others. I’ll definitely be watching to see how the effort progresses.

To summarize, making things legible is about granting agency–it’s about having people walk away from an interaction feeling like they understand why things are the way they are, and offering a concept of the situation that is complete enough for people to act in accordance with their values. As designers of these interactions and systems, ours is a rhetorical task, and therefore one that needs to be approached from a critical perspective to avoid falling into traps. Traps that academics in the fields of design and critical theory, science and technology studies and other humanist disciplines have been thinking about for a long time–and to an extent can help us, as practitioners, avoid. And it’s our responsibility as designers of technology for the public to engage in an earnest discussion with these issues, continually improving our work towards outcomes that are legible.

 

Subscribe via RSS