Domain Modeling for Structured Content

Domain modeling helps organizations discover the information structures and meaning that allow structured content to reach further and last longer. By uncovering the assumptions and tacit rules that plague your content ecosystem, domain modeling can help you facilitate the shared vision necessary to create resilient, scalable systems for communication across channels.

In the context of content design, an organization’s “domain” is the information space in which that organization operates. It encompasses the organization’s sphere of activity, influence, and interest relative to business and user goals. The domain is the larger context in which all these elements are situated.

For the content and functionality that digital products like apps and websites deliver, the domain includes the set of circumstances, background knowledge, and purpose that drives users to seek out and use services and content. For example:

• Médecins Sans Frontières (Doctors Without Borders) operate within the domain of “humanitarian aid”
• Netflix operates within the “streaming media” domain
• Toyota is situated in the domain of “automobile manufacturing”

A domain model is a formal representation of the concepts that are important to how an organization communicates and operates in a given domain. The modeling process identifies and defines key concepts, and describes the consistent, predictable relationships between concepts in the domain.

How to Model a Domain

The primary goals of domain modeling are to identify the key concepts in a particular domain, then clearly articulate how those concepts relate in a consistent and predictable way. The resulting insight provides a foundation for a holistic structured content design process, and brings with it the myriad benefits that come with a clear, shared understanding of the meaning of concepts, labels, and relationships.

The steps I use for domain modeling to support structured content design are:

1. Research the domain
2. Identify and define domain concepts
3. Review and refine concepts and definitions
4. Model domain relationships
5. Review and refine the relationship model

1. Research the Domain

Researching the domain involves two interlinked steps: identifying what your domain is, and then identifying the concepts that characterize that domain and your organization’s role in it. Both of these steps draw on common qualitative research techniques, including:

• Stakeholder and subject matter expert (SME) interviews
• User interviews
• Content indexing & auditing
• Competitive analysis
• Contextual inquiry
• Primary research review (including journey maps and task flows)
• Secondary industry research review

Two questions that can help you identify and describe your domain are:

• What makes this domain distinct from similar subject domains?
• What are the boundaries of this domain from my user’s point of view?

For example, a recent client in the education space initially assumed their domain was “education,” or “educational materials.” As we dug into their content, business model, and user needs, however, we discovered that a better definition of their domain was “primary education and learning.” This framing helped us more effectively collect and identify concepts and focus our initial research in the right direction.

Once you have an initial sense of what your domain is, list the potential concepts that characterize the domain and your organization’s (and their users’) role in it. For this exercise, the best domain concepts are ones that:

• Represent a specific type of thing (as opposed to a specific instance of that type)
• Represent concepts that are central to, or have a particular purpose in your domain (as opposed to concepts that are likely to appear in any domain)

For the client in the “primary education and learning” domain discussed above, “instructional modality” was a good concept. The particular types of modality, “game,” “worksheet,” “song,” etc, were too specific. Likewise, “instructional resource” was included because in this client’s domain, that concept has a very specific meaning and importance, both to users and to the business.

As you collect candidate concepts, list them in a spreadsheet. Use the principles above to weed out the clear rejects, but don’t be too picky at this point: if you’re in doubt, include the concept. Not every one of these “candidate” concepts will figure into the domain model moving forward, but it is important to list them all to ensure you’re not leaving something important out.

To respect the confidentiality of my clients, I am only providing high level (or blurred) descriptions of client project work here. In order to provide concrete, readable versions of workflow artifacts and deliverables, here is an example from a recent personal project on which I used this same process, UX Methods:

👉 I’ll return to this example as we go to give you a running account of how each step builds on what came before, and how the output can be structured for use in subsequent steps.

2. Identify and Define Domain Concepts

For client projects, I typically end up with 50 - 100 candidate concepts for a given subject domain. Once you have a good collection of candidates, narrow the list down to a handful of central concepts on which you’ll focus. Lean on your research and consult with stakeholders. Which are the concepts that are central to why and how your organization and users engage in the domain? Which concepts fundamentally distinguish this domain from other domains? If you end up with more than 20 or so “core” concepts, consider whether you may really dealing with two connected but distinct domains. (And if so, split them up!)

Next, define your core concepts based on your research. You should be able to define your concepts in 1 - 2 sentences. If you need to do more explaining than that, consider breaking the concept down into separate ideas. It is also helpful to provide examples of 2 - 3 instances of this concept in your domain. This outside-in/inside-out approach helps you check the reality of your domain against your (and your organization’s) assumptions.

3. Review and Refine Concepts and Definitions

Your first pass at definitions should be based on research. This is your best assessment of what “accurate” is for a given concept in the context of your domain. The next step is to set up a series of reviews with stakeholders and SMEs to get feedback on your definitions. Structure your discussion to elicit feedback on:

• The relevance of the concepts you’ve identified
• The accuracy of your provisional definitions
• The accuracy of your provisional set of example instances

The goals of reviewing your concepts and definitions prior to beginning to define the relationships between them are to (a) make sure you’re on the right track and (b) unearth hidden concepts or meanings. Be prepared for your definitions and examples to evolve—possibly significantly.

I prefer to review core concepts in small groups of 2 - 3 participants at similar levels of responsibility in the organization. As you move through each review session with new groups of stakeholders and SMEs, add another column to your Concepts & Definitions spreadsheet for notes.

Resist the urge to update definitions as you go. Your goal in the review sessions is not to react to individual statements, but rather to build a record of:

• How the organization as a whole thinks about the concepts that are core to its domain
• Where there is broad agreement
• Where there is inconsistency and internal disagreement on concepts
• Where internal understanding of concepts differ significantly from commonly accepted definitions, industry standards, or insights gained from domain and user research

After you’ve completed your reviews, now it’s time to revise your definitions. Synthesize the feedback you’ve received, and, where necessary, ask additional questions or draw on additional research. If you find there is broad disagreement on what a concept means, it may be that two (or more) groups are using one word to refer to two (or more) different concepts. Don’t just “do what the boss says”: untangle the layers of meaning in what you’ve found and suggest more nuanced language that can help you and everyone in the organization communicate more clearly and more consistently.

4. Model Domain Relationships

Once you have a well-defined and consensus-based set of domain concepts, you can begin to model the consistent, durable relationships between them. In the relationship modeling phase, it can be helpful to think of your “concepts” as domain “objects”: this allows you to expand or contract the units of meaning you’ve identified based on the relationships they have in common.

To begin this process, copy your domain concepts list (just the terms, not the definitions) into a tool that allows you to move objects around spatially and connect them with labeled lines. (Miro is an excellent tool for this).

As you begin to model relationships, keep these points in mind:

• Domain concept relationship models are not sitemaps or user flows. Resist the temptation to fit the domain model into those patterns.
• Look for the primary relationships between objects. You’re not trying to identify every possible relationship, but rather the connections that define the domain. Look for the connections without which this domain could be (or is) some other domain.
• Add or combine concepts until you can describe simple, direct relationships between objects. This can be difficult, especially for the kinds of complex relationships we often encapsulate in language, but it is important for two reasons:
  1. Picking apart complex relationships surfaces hidden domain objects—these are often unstated assumptions the organization has about how something works or tacit rules you’ve yet to uncover. Get these out in the open and make sure there’s agreement on what they are and how they relate to other objects.
  2. The domain model is going to be used to design information structures that allow computers to orchestrate elements of an information system. This is orders of magnitude more straightforward when you’re dealing with binary relationships. Introducing complex, tertiary relationships significantly complicates building a system, and introduces assumptions into relationships that can lead to unexpected behavior later on.

Adding Concepts

If you find it difficult to define a clear, direct relationship between objects, you may be missing an object, or you may have described a concept as a single object that should be multiple objects (because it represents several distinct relationships in the model).

For example, the initial domain concepts list for UX Methods didn’t include a distinct concept to represent the idea of a “Design Problem.” When initially drafting domain relationships, this posed a problem in creating clear, simple relationships between “Outcomes” and “Goals.” Adding a “Design Problem” object helped surface the missing concept and allowed for the creation of direct relationships.

Combining Concepts

Sometimes concepts that have substantive differences in the way they are defined relate to other concepts in the same way. In some of these cases, you can create a clearer and more manageable relationship model by collapsing concepts into a single object or grouping them together.

In the UX Methods domain, “Solution” and “Insight” are distinct concepts. Both concepts, however, relate to adjacent concepts in the model in similar ways.

Combining these concepts creates a simpler model, and creates clarity around the essential relationships between the relevant domain objects. In this case, combining these concepts to the single object “Outcome” led to the insight that both “Solutions” and “Insights” could be accurately described by a single “Input/Output” taxonomy.

👉 To see the final version and applied use of the UX Methods domain model, have a look at the running example in Structured Content Design 2022.

5. Review and Refine the Relationship Model

As with the domain concepts, it is crucial to review and refine the relationship model with stakeholders and SMEs. In Designing Connected Content, Carrie Hane and Mike Atherton recommend drafting a relationship model collaboratively from the start. While this can be a great option in many situations, I have often found that for client work the particularity of the relationship model, as detailed briefly above, means that it is easier and more efficient for feedback providers to react to a draft than to learn how to create a model themselves.

In most cases, in fact, I like to have multiple approaches for stakeholders to respond to. This encourages everyone to adopt a more open mind to how these concepts may relate, and provides additional opportunity to have nuanced discussions that lead to a deeper understanding of the subject domain at hand.

On a recent client project, for instance, I drafted three relationship models from the 23 domain concepts we had collaboratively defined in previous steps, then presented each model to three groups of reviewers for feedback (details of images blurred to protect client confidentiality).

When discussing relationship models with review participants, I also find it helpful to annotate the relationship diagram with numbers to make it easier to discuss particular sections and structures. This is especially useful if you’re conducting your review remotely.

As with the concept review, capture feedback as you go, but don’t actively revise the diagram in the review session. If you’re using Miro, you can use a different colored “sticky note” for each participant so you’ll know where to follow up if you have questions later.

Once you’ve collected a complete set of feedback, revise your model. As you did with your definitions, synthesize the feedback you’ve received, and, where necessary, ask additional questions or draw on additional research. Dig in to any points of friction or disagreement you find, and if necessary, conduct a second round of reviews to make sure you’ve teased out and accounted for the nuances of your domain.

Next Steps

Domain modeling is a valuable tool for discovery, generating alignment, and documenting a shared structural foundation on which subsequent work can be built. While these broad benefits create considerable value throughout the life of a product, for content-focused work the primary “next step” after domain modeling is the design of a content model.

You can find details on creating content models, as well as how domain modeling fits into a holistic structured content design process in “Structured Content Design Workflow 2022.” I also highly recommend Hane and Atherton’s Designing Connected Content, which provides the foundational model the process I describe here is built on, and gives an approachable, well rounded introduction to, well, “designing connected content.” Sarah Wachter-Boettcher’s Content Everywhere is also a goldmine of insights and examples of understanding, modeling, and putting content to use.

Acknowledgements & Resources

Carrie Hane’s and Mike Atherton’s work in structured content spans more than a decade and has had a profound impact on how I understand and practice technical content design. Their book, Designing Connected Content, is a must read for anyone designing content systems that need to scale on the modern web. The steps and examples I present here trace a direct lineage back to their insights, and are offered in the spirit of providing an additional viewpoint and further examples for those dipping their toes into domain models for the first time. None of this would have been possible without Carrie’s and Mike’s clear formulation of how domain modeling fits into the larger process and why it is necessary.

Dan Klyn, information architect and co-founder of The Understanding Group (TUG), uses the term “ontology” to refer to the particular meaning of a product or service. He describes ontology as “what we mean when we say what we say.” Dan’s careful and deliberate focus on how hard it is to accurately convey meaning—and how we might overcome those challenges—has been elemental in my understanding of how to design for clarity in our increasingly confusing world. His work is well worth exploring for those seeking to make the complex clear.

Though not focused on content design directly, Tamara Adlin’s innovative work on Alignment Personas provides crucial insight into the perils of unaligned teams, and the steps it takes to get everyone pulling in the same direction. Using her alignment persona framework on client projects has helped me understand the outsized rewards of taking explicit steps to align stakeholders and team members, and in turn how to apply that strategy to the process of defining meaning and structuring content.

I’ve written elsewhere about where structured content design and web semantics and knowledge graphs meet. The approach I’ve outlined above encourages us to think about and describe content as data that can be integrated into information systems and mediated, read, and interpreted by machines. Michael Uschold’s Demystifying OWL for the Enterprise provides a cogent and accessible introduction to the design and creation of the formal web ontologies that allow us to express human meaning in a way that is actionable by machines.

UX Methods Examples

• View (and save your own copy of) the UX Methods Concepts & Definitions Google Sheet
• View (and ave your own copy of) the UX Methods Domain Diagram in Miro