Unlike organizing external views of information, content modeling pertains to internal information architecture. Building a content model from scratch is relatively easy, while improving an existing system is more common and usually more challenging. Information architects intuitively recognize content elements for data fields and how these fields might be semantically linked, providing valuable opportunities that enhance a user’s experience. Recognizing important data elements and how they might be sorted and associated requires a certain style of thinking, recognition of patterns and a knack for classifying. As categories are identified they lend themselves to defined content structures and interconnections. As an information architect gains practice and experience, the internal structure of content becomes clearer.


information architecture
information models
field formatted data
content management

IA Column

Training Your Eye to See Structure

by Laura Creekmore

Content modeling has gotten a lot of airtime in the past three or four years, as designers and content strategists try to adapt content to work effectively in complex systems. I think of content modeling as internal information architecture – internal to the content itself – while the organizing work we do for navigation, for instance, is external to the content.

When you’re starting from scratch to build the content model for a new site, you can be as prescriptive as you like, shaping the content to fit into the system. But we so rarely have that opportunity. Most often, our work is focused on improving the information design of an existing system.

And this is where content modeling work can feel very, very squishy. When you look at a site composed of hundreds or thousands of individual items, it’s not always obvious what sort of content types you have. If you have recipes or event listings or bios, you can tell. Each of those types of content has an expected structure.

Even if you’ve put a whole recipe into a body field, because that’s all the legacy system offered you, you can still intuitively see how to split the content elements out into distinctive fields if you get the opportunity. Ingredients here, directions there. Or separate fields for each ingredient and amount, if you want to be able to calculate on these fields so users can customize the recipe for a different number of servings.

If you’re creating events, you want the specific event information broken out into fields that are built to take advantage of the iCalendar standard, so your users can add the information to their own calendars. This structure is defined and shared – and understood. We can all agree that events have a start time, and sometimes an end time, and a name or title, and can be described with a description, and could have a location, and could require registration and on and on.

But what do we do with content that goes beyond our expectations? When there is no intuitive structure? Often, a structural potential is there, but our inability to see it clearly leaves everything in the body field.

Training ourselves to see this internal structure, even when it’s not obvious at first, is the hard work of content modeling. It’s easy to fall back on “article with optional image,” when that’s the structure we clearly see, but that visually focused description provides no semantic information, no understanding about the meaning of the content. And semantic definition is where the real opportunity lies with content modeling.

In some ways, this kind of challenge may not seem like a big problem to many of us in the information science world. We are trained to classify, to define, to sort. This is our work. And from that perspective, I think there are many opportunities for us as we continue to categorize the world’s information into more useful, usable forms.

But in addition to opportunities for us, the challenge remains to teach others to evaluate the world with a classifier’s eye. It’s the learning how to think that’s the real work of it.

These processes are also things we can teach a computer to do for us (once we know what we want done). We now depend on computers for classification work, even in natural language processing situations – not just scenarios where we already have structured data ready to dump into buckets.

We have to understand the patterns we want the computer to see, though. Sometimes, thinking about functionality is the best way for humans to get at this structural work. Consider how these scenarios force you to think about the content itself:

  • I want to keep a record that the user has read the policy so I can audit for compliance purposes. (So a policy is a special kind of document that we need to collect user information about.)
  • I need to know when a particular drug is mentioned in our content so I can update the content when treatment recommendations change. (So a drug is a special kind of information connected to treatment information that changes from time to time.)
  • I want to learn about the department’s academic programs to learn what the residency requirements are for the PhD program. (So academic programs are a special type of content that have quantifiable information.)

Yes, these needs sound like use cases from the user experience world. Each of these needs for functionality helps us think about the kind of structure we might put around content to define it, make it work efficiently and reduce the time required for human effort.

Once we define the content structures, or types, of policy, drug and academic program, we can see how they connect to other information structures, like “user acceptance of policy,” “treatment prescriptions” and “residency requirements” or “required courses.”

If you’ve become adept at seeing the invisible internal structure of content over the years, be intentional about defining that structure in the information you touch. Look for opportunities to use semantic structure to improve the usefulness of information and to teach others how to see the hidden internal structure of information. Well-structured content makes information visible and useful to every user.

Laura Creekmore is the Bulletin’s associate editor for information architecture. She and her company, Creek Content, develop content strategy and information architecture for companies with complex communication needs. She can be reached at laura<at>creekcontent.com.