Every digital service can benefit from content modelling – that is, using structured content types to make content more consistent, reusable and sustainable. But when it comes to government websites, it’s all too easy to design a content model that doesn’t meet user needs. Agencies and their users have radically different understandings of their subject matter, and a content model alone can’t bridge that gap.

Content models, domain models and mental models

In their influential book Designing Connected Content, Carrie Hane and Mike Atherton make the case that content modelling should start with researching the domain – the underlying subject matter that your content is ‘about’. Out of this research comes a domain model, a set of connected concepts that are the building blocks of the domain. For example, if your domain is recorded music, your domain model will map relationships between concepts like track, album, artist and genre.

Domain modelling is a great way to avoid the assumptions and biases that can occur if your content model is based purely on content that already exists.

But that doesn’t mean the domain model itself is free from assumptions and biases. On the contrary, a domain model is a map of concepts, and concepts are human constructs, ways in which people organise and understand the world.

The risk of moving too smoothly from a domain model to a content model is that we can end up imposing our mental model, our own way of understanding our domain, on users who might not share it.

That risk is smaller when a domain and its concepts are widely understood and shared. The music business and music listeners both think of recorded music in terms of tracks, albums, artists and genres. (This is not true for classical music listeners, which is one reason why apps like Spotify do a terrible job of organising classical music content.) Similarly, both organisers and attendees of conferences think in terms of venues, sessions and speakers (this is the main example used in Designing Connected Content).

But when the domain and its concepts are fuzzy, poorly defined, or poorly understood, we need to do extra work to bridge the gap between the organisation’s mental model and that of its users. And this is always the case with government websites.

How do citizens understand government? How does government understand itself?

What’s the average citizen’s mental model of how government works? To simplify enormously: let’s say you want to make a complaint about a packet of jelly beans. You do some Googling and find that there exists, fortuitously, a Department of Jelly Beans. Bingo, you think! These people look after everything to do with jelly beans, so I should talk to them about my jelly bean problem.

But the moment you actually interact with the department, this assumption is blown away. You discover that the Department of Jelly Beans has a circumscribed set of powers, specified in the Gelified Non-Perishable Foods Act 1991. These powers relate only to regulating the production and distribution of jelly beans: other departments deal with importation and pricing. Health effects of jelly beans are a matter for another level of government. Consumer complaints like yours don’t go to the department, but to an independent Gelified Foods Ombudsman. Even there it turns out you’re out of luck, because the legislation makes no mention of the correct proportion of black jelly beans in a packet, which was what you wanted to complain about.

Clearly, a website that simply reproduces the department’s legislation-based understanding of their domain, however rigorously modelled, is going to be of limited use to you. Right from the start, when we try to define what the domain consists of, there’s a mismatch between the organisation’s thinking and yours. 

This is one big reason why whole-of-government websites like GOV.UK are such an improvement: they don’t force a user to start their journey by figuring out where their need fits within the esoteric structure of government.

Concepts and user journeys

But the mismatch between mental models isn’t just at the domain level: it continues when we try to define concepts within a domain. To illustrate this, let’s move to a real-world example (this one is from my own experience).

Say you’re Australian with an overseas partner who wants to stay in the country. You probably know that they’ll need a visa. You might even guess that it’s called a ‘Partner visa’. So, your mental model of the immigration system involves two assumptions:

• Visa is a key concept.
• Visas are named after the reason for applying for them.

This isn’t entirely wrong. But as always with government, things are more complicated. It turns out that under Australian law, there are no fewer than 4 different partner visas:

• Partner (Provisional) visa (Subclass 309)
• Partner (Migrant) visa (Subclass 300)
• Partner visa (Temporary) (Subclass 820)
• Partner visa (Permanent) (Subclass 801)

Why 4 visas? Because there are different visas with different conditions depending on whether you’re applying overseas or in Australia; and in each of these cases you first receive a short-term visa, followed by a permanent visa.

It doesn’t stop there: you might also need a Bridging Visa or a Prospective Marriage Visa while you’re waiting for the application to be processed.

In short, there’s no neat, one-to-one correspondence between type of visa and reason for applying, so a content model based on ‘Visa’ as a content type isn’t going to line up with user needs out of the box.

Here’s one example of how the content model can break down:

There has clearly been some content modelling work done here. Summary information about two different visas is displayed side by side on the page, which is helpful, as the user journey will always involve applying for both visas in one process. The information about each visa is structured by a standard set of attributes, so it’s easy to make a comparison. So far so good.

But look more closely at the information under ‘processing times’:

The context is that both applications are done at once; the temporary visa (the one on the left) is processed first, then the permanent visa. So I have two questions (in addition to ‘Why does it take so long?’, which isn’t strictly a content model problem):

• Do the processing times for both visas start from the original application date, or does the ‘clock’ for the permanent visa start after the temporary visa is processed?
• If both processing times start from the application date, how can the temporary visa take longer to process than the permanent visa? That seems odd!

In other words, in an effort to be consistent, following good content modelling practice, this content has ended up more confusing to me as a user, because it lacks the context of the full journey.

What is to be done?

I certainly don’t think the solution is to abandon content modelling. Imagine how much worse the Immigration website would be if there was no consistency to the way visa information was presented!

Nor do I think the right approach is to just reproduce the user’s mental model rather than the agency’s. I’ve heard UX people in government fantasise about smart forms that ingest user details and automatically calculate entitlements, without users ever having to know what they’re applying for.

But while simplifying things for users is great, we need to be careful not to disempower them in the process. If I don’t know exactly what I’m applying for, what’s my recourse if my application gets rejected?

Instead, here’s one way of thinking about the right approach. Content modelling and content design must always work hand in hand. In cases where our content models need to reflect organisation-centric concepts, one job of content design is to bridge the gaps between these and the user’s mental model, one user journey at a time.

Sometimes, this will mean adding more nuance to a content model or to the templates that control its display. For example, processing times could be shown in a way that makes it clearer when they are calculated from.

At other times, we might just need to bite the bullet and create bespoke, inflexible, non-reusable content – if that’s what’s best for users.

The important thing is to get our geeky, structure-obsessed, systems thinking brains and our empathetic, user-centred, design thinking brains working together. As so often, the answer is collaboration.