Last year I attended a great workshop at UX Australia titled A re-introduction to information architecture, run by Donna Spencer. It was filled with important reminders and a few techniques that were new to me, one being the domain model.

Spencer attributed the domain model to Carrie Hane and Mike Atherton’s Designing Connected Content: Plan and Model Digital Products for Today and Tomorrow, which I picked up soon after the workshop to investigate things further.

With all that said, this article covers:

1. What a domain model is
2. How I went about applying a domain model to a recent website re-platform project for an Australian local government body
3. Translating the domain model into a content model for this same project
4. Methods for involving the user
5. My assessment of the technique

What is a domain model?

A domain model maps the underlying subject you’re dealing with.

An important distinction to make is that a domain model is not a site map. Site maps model content for a specific touchpoint. Here, we’re trying to model content independent of how a website, app or other touchpoint interprets it.

Why do we want to do this?

To make information architecture decisions confidently, you need a strong understanding of your content and its relationships. Creating a domain model is a good way to build this understanding.

Additionally, your audience isn’t here for your website (or whatever touchpoint you’re designing). Their needs and interests lie somewhere in the broader subject it represents. They also don’t arrive on your website and start navigating — they’re already navigating, every moment of every day, trying to meet their needs with the resources they can find and understand. Our work can better acknowledge this by starting with a robust model of the subject, and not a premature abstraction of it.

Finally, we don’t want to be restructuring the whole website again in a couple of years. By modelling the subject first, the resulting content model can be translated from something with far greater resilience. Hyde Park will be a park for a lot longer than it’ll be a web page, a brochure, or an Action on Google.

Modelling a council

I’m now going to run through how I used a domain model for a recent (still ongoing at the time of writing) website re-platform for a council.

The website in question covers a lot of what the council does. It also has ambitions to house content that currently exist on other web properties — if you know a bit about government, you’ll know that’s a lot of stuff!

Getting started

We began our domain model with a lot of desk research, subject-matter expert (SME) interviews and workshops.

The breadth was overwhelming—councils do a massive amount of different things. There’s libraries, parks, waste, venue hire, parking permits, public consultation and infrastructure, to name just a few.

Each of these things could easily be a whole model on its own, but we wanted something that could cover them all. To make things manageable, it was necessary for us to split up the domain.

These split domain models were drafted in the interviews alongside the SME. Some were also created in workshops with the content team. Each domain yielded interesting and important details that revealed business rules, organisational constraints and areas for further investigation.

Linking things up

The next part was necessarily messy. We digitised and consolidated all of our domain models into a Miro board. Miro is great tool for this kind of work, offering awesome drawing tools, real-time collaboration and commenting.

These boards (of which there were a few iterations) were then shared around to key SMEs and stakeholders for comment.

The different colours represent negotiated boundaries within the domain. For example, the blue boxes in the top-right were a few objects about outdoor places, while the red boxes closer to the middle were things like permits, grants and applications. The resulting information architecture and user interface didn’t necessarily make these boundaries explicit; however, we did find it helpful to make the model more approachable.

Where we landed

It was tricky to know when we were done. We felt it was complete enough when conversations began focusing more on its translation into a content model, discussing attributes and other details.

From concept to content

In this section, I’ll go through how I define a content model and list some key parts of our translation process.

What is a content model?

Where a domain model maps the world, a content model maps what actually makes sense to publish. Note that there’s still nothing about a touchpoint in this definition, although many content models are designed with one in mind.

It’s also worth noting that practitioners often have different views on what a content model is. Considering this, I thought it’d pay to be explicit on our terms and definitions for this particular project.

• Content type: A reusable set of structured fields. A content model has many content types. A content type has many attributes.
• Attribute: Information that makes up the content type. Often also called fields or metadata; e.g. Title, Description and Opening hours.
• Instance: One entry of a content type; e.g. for this project, the park down the road would be an instance of the content type Place.

Defining our content types

For our project with the council, defining content types was often a process of generalisation. For example:

• The domain model’s entities Park, Community centre, Library, Service centre and others were generalised into the content type Place
• Person, Team, Department and other entities became the content type Profile, which helped a lot in reducing duplication of contact information
• Room, Sports facility and some instances of Venue became the content type Space, and the entity Equipment became one of its attributes

I imagine this won’t be the case for every project. For more focused domains that can afford less abstraction, the number of resulting content types might exceed the number of entities in the domain model. Given this project’s timeline and the breadth of the council’s domain however, generalisation was a pragmatic method to follow.

Defining a content type’s instances

Some of the resulting content types were more ambiguous than others. We had also started developing features like on-site search around them, so the classification of a concept had some implications beyond the constraints imposed by attributes.

The domain model helped here again. We could refer back to a content type’s origins and see what relationships it had in the underlying subject domain.

We also documented known distinctions for each content type as part of our content creation guidelines. Here’s an excerpt for one of the more ambiguous content types Program:

Something is likely a Program when…

• its underlying purpose is to support a specific audience or set of circumstances
• it has an application or registration process associated with it
• it has eligibility criteria

Specificity of instances

It was also important to have a shared method on how the specificity of a single instance should be determined. For example, should a single instance of a sports competition (a Program) be:

1. Sports competitions at Recreation Centre (Location)
2. Volleyball competitions at Recreation Centre (Location + Sport)
3. Senior volleyball competitions at Recreation Centre (Location + Sport + Experience level)
4. Senior lunchtime volleyball competitions at Recreation Centre (Location + Sport + Experience level + Time)

We decided that the specificity of an instance should always seek to balance the following two principles:

1. Specificity matches as closely as it can the underlying user goal at its basic level, i.e. where someone would ‘naturally’ think of the concept
2. Specificity reflects a level where the most relevant meaning is introduced to the concept

For the example above, we ended up prioritising principle #1, and decided a single instance should be Volleyball competitions at Recreation Centre (Location + Sport).

More meaning would have been introduced at a lower level. For example, registration costs differ depending on the experience level of the competition; senior, junior etc. — but we hypothesised people wouldn’t be searching for the concept like that. It did however mean some aspects of the content increased in complexity, e.g. having to list out registration costs for each experience level of the sports competition.

Involving the user

All of these structural decisions have a big impact on the end user. The challenge was, how do we gather meaningful data at this abstract stage, when the research focus is broad?

Our core research method ended up being what I would classify as contextualised user interviews. We needed observational data grounded in life, but the tasks we wanted to study had to be generalised; we had a lot of ground to cover. Much of the research also took place in the midst of the COVID-19 pandemic, so purist contextual design principles like gathering data in the field weren’t feasible.

Here’s how the preparation and running of a session went:

1. Participants were recruited from criteria that focused on recent and relevant experience, e.g. hiring a room within a community centre in the last month
2. The majority of the interview would focus on the participant retelling this experience, and the interviewer drawing out details of the events (e.g. people involved, hurdles encountered, moments of accomplishment)
3. The participant was then shown a proposed structure expressed as a prototype (sometimes paper, remote ones screen-shared in Figma); e.g. a web page about a venue, its features and hiring conditions
4. The participant then reviewed the prototype in relation to the experience they just retold, grounding the evaluation in reality

Observations from these sessions were then inductively reasoned into revised content structures.

There was more to it than that, but I’ll save it for another post.

My assessment

I was impressed by the wealth of inspiration and insight the domain modelling process generated for our team. I’ll definitely use it again.

I also found the domain model an effective tool to externalise conversations about content and get people across what the council did quickly and accurately. The entities’ names also helped cultivate a shared vocabulary, which can never be undervalued.

Finally, the domain model gave us assurance we had captured everything—or at least enough of everything. After all, it’s based on a resilient underlying subject, not an organisation’s structure or an existing touchpoint. As we went through sprints, I observed fewer surprises regarding content. I also anticipate future expansions and the introduction of new touchpoints are less likely to result in tearing down the whole thing and starting again, as these things can sometimes demand.

Thanks for reading! A lot of this is my interpretation of Hane and Atherton’s work, so I’d highly recommend you pick up their book if it was interesting to you.