Reporting back on a design sprint exploring the future of data portals and civic engagement
Over a number of sessions a few weeks ago, we carried out an adapted design sprint (to accommodate remote working, and because we’re using the sprint to explore a range of possibilities, rather than to design a specific product) asking: “What could data portals or platforms of the future look like if they are to better support civic participation?”
After exploring the history and wider context of portals and participation (see past posts), and drawing on a number of short persona profiles, we mapped out a number of potential user journeys. These explored how journalists, community organisers, transparency advocates or engaged citizens might seek out and engage with data, and engage with current portals, and ultimately discover (or not) data that could support them in creating change. This led us to focus in on a number of particular ‘portal problems’:
The false promise of a single shopfront - portals at first appear to offer ‘all the data in one place’, but, from the perspective of users seeking data to solve a particular problem, they can rarely deliver. While portals are often built around organisations, or particular domains: individuals seeking data to solve problems will often need data that cuts across these boundaries.
Dead-ends and 404s - every dataset on a portal needs some degree of maintenance. A number of our hypothetical searches either ended up looking at the meta-data for outdated datasets (“Ok, so I can see a dataset from 2017; but is there anything more recent?”), or 404-pages (“Hmm, it seems the portal has linked me off to a dead dataset.”). As one participant put it “A portal full of dead-ends isn’t very inviting.”
Interpreting data takes specialist knowledge - and this is tricky to solve with technology and tools alone. Much of the data on portals is ‘data exhaust’, collected for one purpose, but now available for others. And to work out whether it can be repurposed requires a degree of knowledge about the background of the data, and benefits from knowing about alternative data (or information) sources that might be available.
Search sets up particular expectations. Most portals begin with a search box, but often struggle to provide or prioritise relevant search results. Finding the right datasets that may be available to use often involves a more exploratory process - and many citizen-activist users will struggle to use the faceted drill-downs that may be available to refine search, not least because they are often designed around the organisational structures of the portal-owners, rather than the problems, positions and capabilities that users arrive with.
Portals only surface the data that is collected. Yet, in many of the potential user journeys we explored, users may be seeking data that is not yet collected or brought together in the form they need. Portals offer few pathways that support users reaching data dead-ends to either adapt their information-seeking strategies, or to consider ways of creating the missing data through community action.
There are limited incentives for publishers to improve their data - and few ways for users to flag interest in using data, or report problems with datasets in ways that feed back into improvements.
While this is by no means an exhaustive list (and we’ve discussed a number of other challenges across the sprint) - these challenges have shaped the solution space we have gone on to address.
Any design process is informed, often implicitly, by a set of ethical, political and philosophical perspectives. These shape the values that guide design choices, and in any collaborative design process it can be useful to surface and discuss driving values.
In our second sprint session, we took a look at how Utilitarianism, Deontology and Virtue Ethics each motivate different kinds of design questions, from focusing on the aggregate consequences of a technological artefact (Utilitarianism), to considering how a design responds to fundamental rights of users (Deontology), or the kinds of character and behaviours that a design fosters (Virtue Ethics) (This is, of course, a super-simplified summary).
We also explored different perspectives on citizen engagement, and the role that data plays in relation to them. For example, in some frameworks, portals are primarily tools of transparency, meeting a citizens (as taxpayer) right to know how their money is being spent by government, and supporting citizen oversight of politics and politicians. By contrast, other perspectives see portals as part of delivering ‘government as a platform’, where government provides the minimum-viable infrastructure to let market-based innovators then provide services to citizens, who (as consumers) then participate by exercising their market-choices over the services they use. Between these poles, there are perspectives that portals as providing access to data resources that can support collaboration and co-production between citizens and the state: improving both services and policies, as well as supporting independent community action.
At the same time, we looked at the wider reasons portals may exist, and the roles they play: from responding to top-down edicts, or simply following a ‘policy-meme’, to helping bring order to the chaos of organisational data practice, or to increase economic exploitation of data. This led us to then explore a number of ‘How Might We?’ questions and identify particular themes to address, including:
Addressing the organisational set-up of portals
Understanding the current availability and usage of data
Supporting people to understand available data, and what it means
Support self-description of datasets / publication of data from different perspectives
Helping people to discover more relevant things
Translating data into meaningful stories
Making people feel empowered to use data for change
Drawing on all these discussions, we identified a small set of principles to reference in our following design work:
Serve those who need it most
Provide helpful onward journeys - ‘the link is as important as the node’
Support conversations - we don’t always have a fixed answer
Always be a welcoming host
One platform for all - don’t rely on ‘back channels’ that expert users who are ‘in-the-know’, or internal organisational stakeholders, can use to get better access to data or answers.
In the next post, you’ll find some of the solution-sketches all these discussions sparked.