The Beginning of a Beautiful Friendship: Data and Design in Innovative Citizen Experiences

The past decade has brought enormous and growing benefits to ordinary citizens through applications built on public data. Any release of data offers advantages to experts, such as developers and journalists, but there is a crucial common factor in the most successful open data applications for non-experts: excellent design. In fact, open data and citizen-centered design are natural partners, especially as the government 2.0 movement turns to improving service delivery and government interaction in tandem with transparency. It’s nearly impossible to design innovative citizen experiences without data, but that data will not reach its full potential without careful choices about how to aggregate, present, and enable interaction with it.

Why Design Matters

Public data is rarely usable by ordinary citizens in the form in which it is first released. The release is a crucial early step, but it is only one step in the process of maximizing the usefulness of public resources for the people who own them. Because data carries important information about the parts of people’s lives that are necessarily communal, it needs to be available and accessible to all. It needs to be presented in ways that illuminate the information it contains and that allow residents to interact with it and incorporate that information into their lives.

The real-time transit apps that are such a strong early example of useful open data do more than offer a raw feed of bus positions. The best of them allow riders to search arrivals on multiple lines of their choosing and adjust their commute plans accordingly. We can see the difference between great and merely adequate design in markets where multiple applications have been built based on the same data. Designs that more smoothly facilitate the tasks that people want to do are the most adopted. Conversely, valuable data that is presented in a way that is at odds with citizens’ mental models or awkward to use often doesn’t get the attention it deserves.

When internal systems or processes first become transparent to end-users via the internet, something profound happens. Assumptions that seemed rock solid can come into question, and the entire reason for running the systems and processes can be redefined. I had the privilege of working at a large financial company during the early days of online stock trading in the 1990s. Since it was founded, the company had employed brokers to interact with customers and accept their trade requests. If the back-end systems supporting trading happened to go down, the brokers covered for them with multiple layers of backup plans. As experts and daily users, they also covered for quirks in the system, odd error messages, etc. The company invested heavily in technology and had a track record of ninety-nine percent system uptime, of which it was justifiably proud.

However, once it opened its doors on the web and allowed customers to place trade orders online, things changed. Ninety-nine percent uptime meant potentially fifteen minutes of downtime in twenty-four hours, which was enough to inconvenience thousands of customers if it happened to fall during the market day. A metric that had been important to the company, and on which it thought it was winning, was no longer close to good enough. Error messages written for employees who received six months of training (and were, of course, being paid to be there) were not clear or friendly enough for customers who were becoming accustomed to online interaction through retail. The company had to rethink everything from how it measured its mainframe performance to how it designed its web pages in order to present errors gracefully. It had to intentionally write and design error messages for the first time. It had to consider the needs of people who were not being paid to be there (and indeed, who had plenty of options with the company’s competitors) in making choices about its technology systems.

I’m happy to say that my old employer recognized and took on the challenge, and it continues to be a leader in modern, internet-enabled financial services today. I see an analogy between what happened in that industry in the 1990s and what is happening in government now in the 2010s. It was the opening of the systems to customer interaction that triggered a revolution in how the company approached designing for customers. This wasn’t just a financial industry phenomenon. As retail stalwarts like Nordstrom attracted online customers, inventory systems designed for internal use became accessible—or at first inaccessible—to customers, creating a frustrating experience. What Nordstrom did in its 2010 redesign has some similarities to a municipal open data release: the company exposed its entire inventory to customers shopping online, enabling people to directly find what they were looking for, wherever it existed within the company’s distribution and warehousing systems or its stores (Clifford, 2010). Again, the needs of customers now able to interact with Nordstrom’s systems engendered a profound rethinking of what information (data) it provided and how (design) it provided it.

Open data has the potential to trigger a similar revolution in how governments think about providing services to citizens and how they measure their success. It’s a huge opportunity, and to take advantage of it will require understanding citizen needs, behaviors, and mental models, and making choices about how to use data to support all of those. In other words, it will require design.

Where Does Design Come In?

Data science can be understood in terms of seven stages: acquire, parse, filter, mine, represent, refine, and interact (Fry, 2004). For the eagerly waiting civic hacker, the first step, acquire, is accomplished through an open data release. For the skilled civic hacker, or for many journalists, that step is the critical one—she can thank the agency that released the data and proceed with her project. The average city resident, however, finds him or herself dependent on others for six of those seven steps after data is released, and in particular, on the final three steps—represent, refine, and interact. These steps are strongly associated with the practice of citizen-centered design.

The difficult task of making data meaningful and useful to all the people who can benefit from it can draw on many methods and examples, but skipping these final steps or doing them poorly can lead to confusion and underutilization of the data that activists have worked hard to get released. Consider US Census data, to take a large example. Early versions of American FactFinder simply provided links to available datasets—a valuable service and a vast improvement on what was available before, via the internet. Still, it was very challenging for untrained people to wade through it.

The latest version of FactFinder, which was released with the 2010 census data in early 2013, has employed design in order to go much further (see http://factfinder2.census.gov). This has been a process of evolution, from the first online releases after the 1990 census to today. The latest version allows a search by ZIP code and returns a set of tabs, each of which highlights one critical piece of information, such as the total population of that ZIP code on the population tab. The Income tab highlights median household income. There are many more facts available in neatly arranged web tables via links, and there is even a Guided Search wizard that helps users find their way to tables that are likely to interest them. It’s not Nordstrom.com (or any other large retailer with a design staff and design culture) in terms of ease of use, but it does a great deal to return this data, which is collected by the government and owned by the people, to the people in a form in which they can use it.

Examples From a Design Perspective

There’s more to designing open data well than just making it searchable and presenting it attractively. In a recent study of US counties’ official election department websites, my collaborators and I discovered a problem with election results released online (Chisnell, 2012). Counties, as everyone who follows elections knows, are the units that precincts roll up to, and for most of the US, they are the level of government that has officials who are responsible for ensuring fair elections and publishing results. All of the counties that we studied fulfilled their statutory obligation to provide vote totals within their county, but voters with whom we conducted usability sessions were dissatisfied with what they found. Why? The counties are releasing the same information they have released for decades, to newspapers in earlier days and to radio and television journalists as the twentieth century progressed. For hundreds of years, journalists (and state election officials) have performed the service of aggregating these county tallies for voters, so that they know who actually won. This is what voters have come to expect as the meaning of “election results”—“who” or “which side” prevailed in the contests they voted on. So, voters looking at county election websites were confused and disappointed by the results sections, which provided only local tallies and no “results.”

There’s nothing wrong with this public data, but there is a problem with information design. Voters look to these sites for what they think of as results, particularly on second and third rank contests that may not be well covered by the media. The sites currently don’t provide voters’ idea of results, but simple design changes would allow them to. Without complicating these sites’ visual or interaction design, the counties could provide links to the overall outcomes of the contests they report on and satisfy everything citizens want. Design isn’t necessarily about being fancy or even pretty—much of it is about the right information at the right time.

The government has collected the first names of children registered for Social Security since the program began. They’ve collected baby names from birth registrations for longer. In fact, births and names are a basic public record. In the 1990s, after the advent of the web, these records became much more interesting because the data was made available in a form that was easy to explore. We can thank an SSA employee named Michael Shackleford for writing the first search program and making first name data public (Graham, 2013). The agency has since evolved its own design and seen others build on top of its open data. One famous example is NameVoyager. NameVoyager offers a brilliant design on top of public data—the step of visualizing the popularity of names over time on a graph, with pink and blue bands representing girls’ and boys’ names, and the simple interface that constricts the bands as the user types each letter of a name turns a bureaucratic dataset into a game.

Mobile apps using transit data are one of the biggest citizen-facing open data success stories, but again, an app that simply provides a feed of GPS coordinates for buses isn’t a winner. Those that provide the most features aren’t necessarily the best ones either.

Weather data has seen some interesting developments in 2012 and 2013 in terms of design. Government weather data has been considered a public good since the government gained the capability to collect meaningful weather data. However, until very recently, it has been offered to the public through basically a single information model. This model was regional (because information was distributed by broadcast), focused on large events and weather patterns, both because those make sense in the regional model and because the entities with the most pressing need for weather data were agricultural and industrial.

Now, consider three recent weather apps, all for mobile phones, that take public weather data a step further: Dark Sky, Swackett, and Yahoo! Weather. All use essentially the same public data, and each offers a different experience. Swackett (released in January 2012) proposes that the main reason individuals need weather data is to understand what kind of clothes to put on or whether or not to bring a jacket. Its interface shows a whimsical figure, which the user can customize through different editions, dressed appropriately for that day’s predicted weather in the user’s location. More traditional weather information is available through navigation.

Dark Sky (released in April 2012) doesn’t show a person, but it also assumes that an individual’s reason for looking up the weather is both hyper-local and immediate-future. Dark Sky’s default screen shows expected rainfall over the next sixty minutes for the user’s current location. It answers the question “do I need to take an umbrella if I go out right now,” and it sends notifications like “light rain starting in five minutes.” (All of this is only useful because the data is excellent.)

Yahoo! Weather’s new app, released in April 2013, combines government data with Yahoo’s repository of photos shared by its users to provide a simple temperature with a photographic background that gives a sense of what that weather feels like in the current location. Its designers chose radical simplicity—there are no radar maps, no extended forecasts, and no extras. Different people might choose differently among these three apps—none of them is clearly “better” than the others—but they all employ design in combination with open data to deliver an experience that far exceeds anything that existed prior to the 2010s.

Even our work in open data standards can be supported by good design choices. I don’t mean colors and fonts, but choices about where and how to display information that takes account of how people use it. I’ve been guilty of being a killjoy in the past when I’ve heard about restaurant health inspection score data being released and civic hackers building apps on it. As a UX designer, I’ve never observed anyone paying attention to the required public posting of scores in restaurant windows, and it’s hard for me to imagine that anyone would actually use such an app in the course of ordinary restaurant going. That said, when Code for America collaborated with the city of San Francisco and Yelp to place restaurants’ latest scores within their Yelp profiles using the LIVES standard, I predicted that this would be a useful and successful design.

Why? Yelp is one of the key places where people make decisions about restaurants already. Having one more piece of information available within that interface supports established behaviors that would be difficult to change, whereas having to download and install a separate app specific to health inspections would complicate the process of evaluating restaurants. While this may seem like just an implementation choice, it’s a design choice that makes an enormous difference to the user experience.

Much of the work that we are proudest of at Code for America involves strong design, as well as clever technology. BlightStatus, built for the city of New Orleans by Alex Pandel, Amir Reavis-Bey, and Eddie Tejeda in 2012, is celebrated for its success in integrating data from seven disparate city departments. It employs plain language, simple and familiar web affordances, and clear information hierarchies.

DiscoverBPS, the Boston Public Schools search app created by Joel Mahoney in 2011, succeeds because it looks at the process of school choice from a parent’s perspective. Rather than listing data school by school, it allows comparison across factors that are likely to be important to families (based on the creators’ user research). In reducing the burden required to extract meaning (i.e. the specific information categories they care about) from public data, it uses design to make the information more accessible to everyone.

How Do Successful Collaborations Between Officials, Data Geeks, and Designers Work?

Design is a less familiar field to some members of the open data community, but it shouldn’t be intimidating. Designers, in particular designers who practice user-centered design, interaction design, or other disciplines from the broad user experience field, are accustomed to working in cross-disciplinary teams and being transparent about their processes. Much like geeks in other fields, they are often idealistic and unable to resist working on interesting problems.

At Code for America, we include a fellow with a design background on every team, in collaboration with coders and data scientists. The designer’s first role is to understand the problem from a citizen perspective. They may review analytics, conduct interviews or end-user observations, or facilitate more formal research. From here, they go on to propose experiences or interactions that would improve the audience’s life, without immediate reference to what’s technically feasible. This is one starting point for collaboration. Many designers sketch at the stage where developers begin hacking around. Inspiration is equally possible from this direction or from what a developer may dig up in understanding the dataset; a free-ranging conversation between the two disciplines is often magical.

We also ask designers to set goals for the end-user experience of anything we build and to work with their city partners and developer colleagues to align around what qualities the experience should have. Some of these are general—it’s always a goal for an application to be simple, beautiful, and easy to use—but many are specific to the problem and audience. A 311 dashboard for a busy city official and a Parks & Recreation app for neighborhood residents will have very different design goals. Once these goals are known, a good designer can guide a team in arranging information and choosing interface elements to support them. Designers are also expert in identifying barriers to adoption or use based on their knowledge of the audience.

To be clear, design training isn’t required to do any of this, although an experienced designer can be a great asset to a team and designers are starting to join the open data and civic hacking movements in greater numbers. Many of the core design and user research techniques are well documented and require less time to learn than a new programming language. So, design can play a role as an activity, as well as a team member.

What Could Open Design Look Like?

Whenever I write about design in government systems or open data, I run up against the question of whether design, too, can be open. While the answer is an unqualified yes, the processes and culture aren’t as mature as they are for open data or open source software. One interesting example is the Gov.UK design principles, which attempt to open a successful design process (“Design Principles,” 2012). Organizations adopting these principles would follow many of the techniques described above.

Traditionally, design has been among the most copyable disciplines—there is no reverse-engineering required to make a Submit button that looks like someone else’s excellent button. There have been lawsuits over the years that have attempted to protect designs (witness Apple suing Microsoft over early versions of Windows), but most have been unsuccessful. It’s understood that compelling designs will be imitated. At the same time, there’s something important about a willingness to be imitated and to have a two-way dialogue with others working to improve experiences in the same space. The city of Buenos Aires has committed to open-sourcing the design of its open data catalog, and the Gov.UK website publishes critical elements of its design, in addition to the process principles. Both of these designs are strong, and hopefully, their openness encourages more people to start from strong foundations.

How else can we share? We can share examples of useful design goals that contributed to successful applications. We can share learning experiences about particular audiences and tasks. While there may be reasons why a Chicago transit rider is different from a Seattle rider, it’s highly likely that they have many needs in common. If a member of our community interviewed fifteen commuters in Seattle and proposed a set of design goals for a transit app based on those experiences, those goals could be a useful starting point for a team working on a transit app anywhere. We need to develop better mechanisms for this level of sharing as we develop a culture of open civic design.

Conclusion

Design is a critical practice for enabling open data to reach its full transformative potential. Without citizens being able to interact with government data directly, we are unlikely to trigger a revolution in how services are provided. We all know how much we need that revolution, for reasons of cost, fairness, and human dignity.

Methods drawn from the user experience field are the easiest way to translate open data into a format that’s usable and accessible for the average (or non-average) citizen. The most successful and broadly used open data projects have always relied on design, whether or not people formally trained in design were part of the teams. Our task now is to bring our best design ideas into our shared movement and take advantage of everything the discipline has to offer. With design, we can give the public back its data in real use, as well as in name.

About the Author

Cyd Harrell is a user experience expert with over fifteen years of experience improving online and software products. As Code for America’s UX Evangelist she works with fellows and staff to help create inventive and cost-effective civic technology that serves the needs of real users. Previously she has been a Board Member at Brightworks School and the VP of UX Research at Bolt Peters.

References

• Chisnell, D. (2012, December 6). What I’m working on now. (Web log). Retrieved from http://civicdesigning.org/featured-story/what-im-working-on-now/
• Clifford, S. (2010, August 23). Nordstrom Links Online Inventory to Real World. The New York Times. Retrieved from http://www.nytimes.com/2010/08/24/business/24shop.html?_r=0
• Fry, B.J. (2004). Computational Information Design. (Doctoral dissertation). Retrieved from http://benfry.com/phd/dissertation-110323c.pdf
• Government Digital Service. (2012). Design Principles. Retrieved from https://www.gov.uk/designprinciples
• Graham, R. (2013, April 14). What baby names say about everything else. The Boston Globe. Retrieved from http://www.bostonglobe.com/ideas/2013/04/13/what-baby-names-say-about-everything-else/Ln9kVOl9haGhFoHwQv9h7I/story.html