Building Public Service Ecosystems
“What makes something simple or complex? It’s not the number of dials or controls or how many features it has: It is whether the person using the device has a good conceptual model of how it operates.”
—Don Norman, “Living with Complexity”“To define is to limit.”
—Oscar Wilde, “The Picture of Dorian Gray”
This is the second in a series of essays about open logic for public services. (You can find the first here.) Together, they argue for public systems that are built to be understood and navigated. This is an argument for open rules, logic, and algorithms, and for interfaces designed to help people learn about the complex systems they rely on every day, so they can improve their lives.
The public systems we build for people to get help, escape poverty, and improve their lives are complex: they have multiple points of entry, overlapping solutions, seemingly random eligibility requirements, and other miscellaneous complications. Complexity can exist because systems, people, and organizations are not as efficient as they can be. But complexity can also exist because it must, because people may need many different kinds of help, from many different kinds of professions. Eventually, people who need public services will have to engage with a complex system that they’re unfamiliar with.
In a crisis, people may not have the luxury of time or errors to learn how to navigate these systems. A need for public services can sometimes look much like an emergency — appearing with little warning and abundant severity. Moreover, a mistake can have severe consequences: a backslide into poverty, losing a home, or missing an opportunity for care.
At the same time, expertise for navigating these systems does exist: not only from the experts providing public services, but also from the thousands of people who have previously tried to navigate these systems. How can we bridge the gap between this expertise — this collective mental model of how a complex system works — and the people who need it most?
Help is not a list
When someone needs help, the first thing that they might do is try to figure out what type of service they need, and then look it up. Not that long ago, this search — or any other search — might have started with a phone book. If you needed, say, a plumber, you would navigate to the section for plumbers in the yellow pages, and face anywhere from a dozen to a hundred options. Of course, you wouldn’t call every plumber on the list — that would be too much. You’d probably call the first one, or the one with the most prominent ad. Plumbers know that too — that’s how A1A Plumbers is hired to liberate the menagerie of plastic zoo animals inhabiting your pipes.
Although we’ve stopped using phone books, this way of presenting information remains influential. Yahoo’s original “search engine”, for example, resembled a giant digital phone book — the web, collected and categorized. Digital directories of service providers are popular civic technology starter projects. The solution for help being hard to find? Find everyone who provides help, and put them in a list.
Often, these lists offer a first level of basic categorization, and perhaps a second, and then stop. This solution works pretty well for things like plumbers and pizza. There’s a simple request, and a simple, known solution.
But requests for public services aren’t always simple, and finding help is more than a simple request and a simple response. A person may need or may be able to get more services than merely what they request — for instance, someone who has just lost their job may look for unemployment assistance, but may also need assistance with rent, food, and utilities. Someone may be seeking help (or a type of help) for the first time, and may not be aware of every available or relevant service. This also means that the most urgent part of a person’s story may not be obvious — for example, if someone receives a letter that their food stamps have been revoked (a time-sensitive notice), one may need to urgently contact a lawyer. Or, a solution may have multiple, overlapping options: think the range of services a victim of domestic violence might pursue, from social services to criminal complaints to restraining orders.
Here, a simple directory may not be enough to help people engage with this complexity. Presenting a long list of providers may lead users to start with service providers at the beginning of the list (like A1A Plumbers), who may not be able to help. So a user might call or click or visit the next one. Or the next one. Or the next one. This loop of search, inquiry, and rejection is costly, and enough unsuccessful searches may lead someone to conclude that help is unavailable to them. Moreover, once someone finds a service that does fit, they might stop their search — losing an opportunity to connect someone with additional services they might need, or might need more urgently.
Whether for plumbers or public services, the presentation and structure of information changes how people use it. Directories organize and categorize services based on how professionals in a field are organized and categorized. This doesn’t necessarily match how clients need the same services, and how those services are correlate with each other. Here, people engage with public services not merely to be connected with an immediate service, but to prevent and mitigate poverty. We should build information structures, then, that help people do exactly that.
Connecting stories to help
Good structures help a person move from guessing what they want (e.g., “help with finding a job”) to uncovering what they actually might need (e.g., employment agencies, resume help, training, rental assistance, food assistance, utilities). Put another way, we might build structures that 1) connect someone’s need to multiple services, and 2) show how different services relate to or correlate with one another.
What could one of those structures look like? Let’s start with the example we just mentioned: looking for a job.
A simple directory query might return job search services, from temp agencies and employment agencies, and stop here.
We can do better. We could add specificity to the existing results, and start to categorize them. For instance, a person looking for a white-collar versus a blue-collar job may need to visit a different agency.
If a person is looking for a job, it’s possible they might need other services that could support finding a job. For instance, someone might be interested in vocational skills trainings, or job-seeker clinics that help with resume-building and interview practice. These categories of services might be correlated with each other — people who ask for one type may also be interested in the other type, so we could mark that.
A veteran might also be able to get help at the VA, so we could add a quick check for that.
When a person actually gets an interview, services like Dress for Success can provide interview-appropriate clothing.
Finally, someone might need to know their rights when searching for a job, and may need legal help if they face discrimination.
We could keep going beyond services that are immediately related to employment. Someone who is looking for a job might have recently lost their job, and so might need services to mitigate lost income. Not everyone will need these services, but those who do will need them urgently.
For example, because lost income might impact a person’s ability to pay rent, they might need information about rental assistance programs or affordable housing. They also might need information about how to protect against eviction, information that is far more helpful before an eviction notice is actually received.
Some of this services might need urgent attention, like rental assistance, so we could highlight them.
Finally, someone might need other supplemental income help, like assistance with utilities or food (which we could obviously fill in with more services, but here we’ll skip it).
We’ve now got the beginnings of a initial map of service types and guidance that is responsive to someone’s story — in other words, a structure. A person might not need all of these services, but we can use this structure to pinpoint questions to ask a potential client in order to include or exclude certain services, and highlight issues that may be especially — or surprisingly — urgent or time-sensitive. And, now that we have a structure, we can keep iterating on it to add more detail and scenarios (in this example, housing is obviously under-detailed), and use it as the basis for digital tools for public service delivery.
This structure can even exist independent of the initial “I need a job” request, allowing us to start at any part of the network and navigate to relevant services.
Ecosystems in practice
In technical terms, this looks a little like a semantic network. A simpler way to think about it is that we’re mapping the ecosystem of public services. Rather than lists of organizations who might or might not provide services, the core of this network is knowledge about how services relate to other services and to what people need.
These ecosystem maps place services in the context of the human stories that implicate them. This isn’t necessarily new information, but it exists only in the heads of experts and clients who have traveled these service paths before. If expertise is the ability to connect someone’s story of need with a coherent set of public services, ecosystem maps are the first steps in making this expertise available to everyone.
This approach helps us move from open data about individual public services to open knowledge about the public service ecosystem. We wouldn’t necessarily directly present an ecosystem map to someone seeking help, although it could be useful with the right annotations and navigational tools. Rather, ecosystem maps can help experts and non-experts alike understand where a particular service fits in a larger system. Communities can build on this data structure to deliver better information about services someone might need, and might need most urgently. And because the core of these networks don’t depend on specific service providers, experts across geographic and sector boundaries could collaborate on building them.
Modeling public service ecosystems can help break down the silos that separate practice areas, helping experts express and share their expertise for navigating public services. The product of this work could be used as the foundation for digital triage tools, databases of service providers, research on service outcomes, and more, while providing a common language to understand public services and their hidden connections. For instance, service providers could use this to identify related services for their clients, or to produce packets of information that sort potential services by urgency and relevance. Community-driven knowledge networks could help first-resort organizations, like libraries, churches, community centers, and schools, provide accurate, structured help. Finally, policymakers could use this network in conjunction with reporting data to better understand how different public service needs are related to each other, which could yield insights about how to offer, fund, locate, and evaluate these services. (Itself worthy of an essay, just not this one.)
Ecosystems as interface
The presentation of information influences how people see the world. Information about public services and public policies does more: it sets the terms for how people interact with government. How information is presented — and what technology is required to access it — has a gravitational pull on public life, influencing everything from who can get services to how easily people can participate in policy change. Hiding complexity, rather than presenting models for understanding it, raises the barriers for interacting with government, making help more difficult to find and policy change more difficult to effect. Small wonder, then, that people grow angry and frustrated with a system that doesn’t provide what they need.
Someone’s ability to find help depends on their ability to understand where their story fits within a larger ecosystem of public services. Solving this problem, then, isn’t merely a matter of simpler processes, open data, or more experts. Rather, we should aspire to democratize expertise itself, and make the unwritten rules and hidden connections between services accessible and understandable to everyone. When we start thinking of finding help in terms of navigating ecosystems instead of scrolling lists, we can begin to weave constellations of individual service providers into a true social safety net.
