Information structures can usefully be represented as boxes and arrows, where the boxes describe the different constructs in our information space, and the arrows represent some relationship between them.

This notation has many benefits: it is a concise tool for exploring and communicating structures, and you can often point a finger at where a problem might be and how to correct it.

It also has many applications. We can use boxes and arrows for both the surface presentation of information, which is what the user sees, and the deep representation, which is the logical information structure we are designing under the hood.  Our job as information architects is to design deep structures that the business can reuse in multiple useful surface representations.  If we do it right, the deep structures change fairly slowly,  while the surface representations change more frequently as people, including us, have good ideas for new and useful combinations. So we have to get good at looking at surface artefacts such as web pages, site maps, and user scenarios and seeing what deep structures are implied.

Let’s take the example of an intranet makeover, where the client has a hand crafted intranet and wants to upgrade it to a web content management system.

We start by creating a site map, a structure of boxes and arrows showing how the pages in the site are linked together.  The structure is usually broadly hierarchical, with frequent ad-hoc linkages embedded within content or in sidebars called Related Links. The boxes name the pages, and the links name their destination.  If we are lucky, the name of the link is more or less the same as the name of the page that it links to.

At this point we use the diagram to point out structural deficiencies such poor structure, poor navigation and poor terminology, and we make recommendations for fixing them. However, this is old school IA, well documented, and we won’t cover it here.

Now we start looking for regularities in content, and what underlying information structure it implies.  We’ll record this as another diagram of boxes and arrows, which will look vastly different than the site map.  To start with, most intranets have many pages called News, so we will consider an information component called NEWS.  Many intranets have Projects pages, so we can add a box for this. Similarly for Events, Presidents Blog, etc.  There will still be many pages that are one off, so perhaps the first component we drew should have been WEB PAGE, or better CONTENT if we want to keep deep and surface constructs distinct.

What about something like Departments?  This is usually an intranet area for some if not all departments, with varying degrees of richness. Even though Corporate Communications has a richer area than Janitorial Services, we still do the analysis to see if there are regularities we can exploit.  For example, all departments might have Who We Are / What We Do or a gallery of staff photos and contact info, so we note this regularity.  At the end of the day, we might find a simple set of pages that let simple departments get a presence on the intranet, a medium-sized set of pages that handles larger departments, and a few departments that have their own distinct set of hand-crafted pages, handled by the Web Page box. But this is still surface presentation.  The underlying deep information components might include STAFF and SERVICES OFFERED.

What about situations where there are pages for General News, Departmental News, and Project News?   How do we decide if we want a separate information component for each of these. This is where we have to look more deeply into typical content.  Suppose Project News has distinctive information, such as milestone achieved, expenditure, and forecast.  This certainly could be handled in the body content in NEWS.  But suppose we want to provide an RSS feed of project updates so that subscribers could extract milestone, expenditure and forecast separately for their own purpose (maybe exporting to separate columns in a spreadsheet, we never know).  Then we would create a new information component, perhaps better called PROJECT STATUS UPDATE, in which achievement, expenditure and forecast were broken out from body content and stored as their own elements.

At the end of this exercise, we have a page full of candidate information components and a head full of questions.  Just boxes, no arrows yet. That’s another lesson.

If you want to practice, you could sketch out the structure diagram for this example or your own intranet.  Another good example would be to look at the information components of this blog.

The Information Artichoke Home Page   |  Modern IA Course Table of Contents