Back in my BBC life I worked on a variety of web things which these days they'd doubtless call products. They ranged from radio and telly programmes to music to food to wildlife to footballing. But they did have some things in common.
They were, for want of a better word, meant to appeal to a 'mass market'. Forgive me. Or at least a mass market partially defined by licence fee payment and UK borders. And their intended users were atomised as individuals. As were their 'needs'.
Food websites are a good example because everyone has some thoughts on food. Given the sheer number of recipes the Beeb gathered over time there were many, many ways to slice and dice them. By complexity: give me simple recipes, give me a challenge. By time of year: festivals and seasonality. By dietary choices: cultural or otherwise. You could aggregate around a 'dish' and provide 12 different shepherd's pie recipes which should be enough to meet most needs. By looking for dishes reused as ingredients you could provide aggregations of recipes using leftovers. And combine that with seasonality to give users - or, as the BBC might say, the audience - the usual selection of Boxing Day treats.
Every one of these lists and assorted lists taken in combination could be seen to serve a 'need'. I want to feed 12 people as cheaply as possible. I want to use up all this bloody turkey. I'm not used to cooking vegetarian food but I need a simple meat free recipe. Some of the 'needs' could be seen as more niche than others but, with a little restructuring of the underlying data they all became pretty straightforward to meet. Unlike more specialist recipe sites, BBC Food was pretty much aimed at everyone. The recipes ranged from one pot, six ingredient weekday teas to stuff that would take up most of Sunday. Pretty much anyone should have been able to find something they could cook there.
The second point around atomised users vs. complex communities is more interesting. At least to me. Whilst we had a variety of users with a variety of needs, they could pretty much be considered as individual, atomised agents operating independently. You have to assume that this wasn't entirely true and that recipes were printed, improved upon, scribbled over, photocopied, emailed, shared and tweaked further. But any communities that grew up around this stuff were off stage and invisible. You could design the facilities but you couldn't design the communities and the swapping and the sharing. And neither could you measure it. But this was fine. What happens on the web stays on the web. What happens next is more interesting but you can't design humanity. Allowing for off site behaviour was an edge case. Mostly we were trying to meet needs of individuals trying to find recipes to cook.
These days I work for the UK Parliament. Still doing web things. And Parliament isn't much like recipes. You could maybe say that the Parliament website should meet the needs of the broadest possible spectrum of society. That if we want democracy to work well, we need to make sure that the activities of Parliament are as visible as possible to the largest number of people. But the expectation that most people will visit our site to witness democracy in action seems misguided at best.
Before I joined Parliament I probably visited the website about twice. And one of those was just the usual interview preparation. And two might be exaggerating things. I certainly didn't know what I know now. And if you want to work at a place where you learn things, I can't recommend it enough. But I didn't feel uninformed. Because journalism exists and civic tech exists and Wikipedia gets edited and parliamentary business is picked up by the press and parliamentarians engage with the media.
Making things for a complex community of interrelated actors is quite unlike making things for a mass user base of atomised users. There's something Cynefin-y here, in that BBC Food disseminates information into a simple environment of autonomous users - whereas Parliament makes information available to a complex ecosystem of people. Which means the way in which information is made available is different and the process and meaning of measurement is different. Three people reading a recipe wouldn't be good. Three people reading a committee report doesn't carry the same meaning.
The complex information ecosystem is essentially human, independent of computers and outside many forms of measurement. If you wander round Parliament you'll see politicians, obviously. Some of them you might even recognise. But you'll also see clerks, librarians, journalists, lobbyists, members' staff, academics etc. And you'll see the various breeds chatting in corridors and cafes and bars. Because this is how it works: much of politics is informal information exchange.
If a minister wants stats on something they'll start with their department's civil servants. Backbench and opposition Members primarily rely on the parliamentary libraries. Most of this is enabled by Members' staff. The libraries answer Members' enquiries and publish briefings, which are publicly available - and read by civil servants, journalists and academics. Members and journalists and lobbyists talk to each other. Civic tech types take parliamentary output and re-configure it for new uses and new users.
Much like journalism, the civic tech people often include editorialisation in a way that Parliament doesn't. And many argue shouldn't. I'm reminded here of the ODI report on parliamentary open data which emphasised the need to concentrate on publishing core parliamentary information:
The majority of public interactions with Parliament are indirect, via tools like TheyWorkForYou and via journalists who often rely on these secondary sources. We recommend that Parliament supports the network of data users and developers who create tools that extend its reach.
There is a temptation within Parliament to want to own the engagement it has with citizens. Whilst we recommend being aware of the wider user need, open data is a way of extending Parliament's reach via developers, activists, journalists, and politicians
A majority of our work is responding to this. Getting the models right, getting the data right, publishing openly, using standards and making it easier for other people to build services on top.
Anyway. Back on topic. We're not dealing with individual atomised users. Or even groups of users with atomised needs. We're dealing with a complex community of actors and information flows much of which is beyond the reach of measurement. Recognising how information is communicated by people to people beyond the website is as important, if not more important, than how users experience that information on parliament.uk. Thinking in terms of information ripples makes more sense than thinking in terms of atomised website user needs.
Recently we've been working on modelling parliamentary procedure in order to make it easier for people to track secondary legislation laid by the government. Previously clerks got by with hand compiled calendars of praying days and email distribution lists. Now we've made a service that anyone with a web browser can use. But who will?
Tracking secondary legislation is important to many people but not often in their capacity as private citizens. Lobbyists and pressure groups want to see what's happening in their areas of interest, journalists are as ever looking for a story, clerks need the information to do their jobs, the libraries need the information to answer enquiries from Members, the government and civil service needs to know where their legislation is in the parliamentary process. And given that the window for debate and voicing opposition to secondary legislation is necessarily limited, backbenchers and opposition Members need to see what the government is dropping into Parliament in order to take action.
Imagining that large swathes of the public have a particular interest in many pieces of secondary legislation would really be missing the point. You could choose to target the service at some combination of opposition, member staff, clerks, librarians, journalists, lobbyists, civic tech types etc. But even designing with that intention misses the point. Because information flows exist outside the website. If the opposition whips office sees a potentially controversial piece of legislation, it seems unlikely that the librarians and the lobbyists and the journalists and other intermediaries and, by implication, the public generally will not find out. And the opposition and backbenchers are the one set of people who have the ability to formally object to the passage of secondary legislation.
The influence of GDS and of at least the first version of gov.uk is obvious here. Their approach emphasised the provision of more straightforward services to people by glossing over much of the underlying complexity of government. Before prioritising more specialist users with more granular information needs. And potentially obscuring the visibility of the operation of these systems. But the government case is different. They are the single point of access for many of the services society relies on. Parliament, by comparison, does not offer many citizen facing services. You can contact a Member, but if you're campaigning on a particular issue you might be better off joining a pressure group. Or a political party. You can petition against various things, in various ways. You can offer evidence to committee inquiries. But mostly you can vote. The scope for simplifying the workings of Parliament so as to simplify the interfaces it presents is limited. If you want to change the processes within Parliament you have three options: persuade a Member to want the same changes that you want, vote for someone who does or stand for election.
This is not to say that the website should be designed exclusively for one small set of users. If journalists pick up on some action the government is taking they should be able to link to the source, and readers should be able to follow that link and end up somewhere that is at least roughly comprehensible. Or at the very least, not the hideous confusion of weird typography, hideous clipart and wonky drop-down menus the Parliament website has today. This is of course assuming that journalists one day learn to cite sources. We wait in hope.
The wider point here being that not all users are equal. Some users have greater access to the means of effecting change than others. Some users have more power to disseminate information than others. In these cases, addressing Members seems to make most sense. This is not the same as neglecting users or the information needs of the public at large. Only last week I had a conversation where someone claimed that not designing for the widest possible user base was somehow 'immoral', and harmful to transparency and democracy. But designing for a bunch of people who don't use the Parliament website, are never likely to use the Parliament website and will find out this stuff via other means, whilst dumbing down the complexity and language to a point where it no longer serves the needs of expert users to monitor Parliamentary activity feels inherently more dangerous.