Flexible Documentation: Content Modeling

Content modeling and prototyping are invaluable tools to the software design and development process. Having a solid grasp of your content and testing your concept are necessary steps in most every web project. But there’s a lot of rework happening in that transition from research, information architecture to prototyping. Let’s see what we can do to upgrade our documentation in this process and be a little more efficient with our time.

Read more articles on Code, Prototyping

Structure

The usual process goes a little like this:

An Information Architect, Content Strategist or whomever is doing the content research will identify basic content types and their relationships. This will be communicated in possibly sketch form, maybe a higher fidelity representation, using a tool like Omnigraffle. This is basic building block of understanding content, which I hope is known before you even think about design.

For all intensive purposes, we’re going to be modeling the content for a Leisure Sports website.

content-model

Nice and simple, right?

Once you do your homework, pretty easy to create and not too difficult of a concept for clients to grasp, either. Plus it’s a necessary step into identifying how the major content components will work together.

Attributes and Real Data

Now we need to get into the details. Starting to define where that content is placed, all the details that go into those pieces of content and how it will be delivered in the UI (wherever that UI happens to be).

Historically, information architects, myself included, have done this in various ways. Spreadsheets or bulleted lists tend to be the go-to formats for documenting content. We create elaborately detailed content models to make sure we’re not only understanding the content components and attributes, but also volume of content, frequency and of delivery, and much more.

content-model

Spreadsheets and bulleted lists get the point across, don’t get me wrong. We see data attributes, character counts, labeling, etc.

But this isn’t the most efficient way of producing this content considering what will need to happen in later stages of prototyping and development. It not only has to be modeled in that spreadsheet, but again in code.

A More Efficient, Portable, and Flexible Content Model

Why not model our content in code? If we know we’re utilizing an API to deliver content through JSON, well, that’s supposed to be a pretty easy format to read by non-developers. Heck, I would even go so far to say it’s easy to create. See the same content model from above, but in JSON format below:

[
  {
    "name": "Bags",
    "aliases": [
      "Cornhole",
      "Bag Toss",
      "Bean Bag Toss",
      "Baggo",
      "Sack Toss"
    ],
    "players": "2-4",
    "rules": [
      {
        "id": 1,
        "title": "The Setup",
        "description": "Boards should be placed 21 feet from each other.",
        "category": "Scoring"
      },
      {
        // Rule #2
      },
      {
        // Rule #3
      }
    ]
  },
  {
    // Game #2, etc..
  }
]

This JSON file, not only can be used in coded wireframes and prototypes for mobile, desktop, watch and any device that has a WiFi connection, but also reduces the amount of rework performed by designers and developers!

Not a developing designer? No problem. Find your closest and least smelly developer friend and have a quick conversation.