Developing a site structure

The information architecture (IA) work for the current website project I’m involved in has been chunked into four phases with the intention of redesigning the website from a “content out” point of view.

1. The content view
2. The site view (this post)
3. The page view
4. The user view

Using content items identified in the Content Delivery Plan (acknowledging the risk of an incomplete client gap analysis) this past week has saw us developing the new site structure for our client’s website redesign. This work is not website navigation—it informs the navigation design—but it’s not exactly the same thing. We have maintained industry terms  as metadata rather than use it directly as site structure because we believe general site visitors shouldn’t need to learn the organisational structure of the client or know our precise terms (jargon) to find stuff. By maintaining the industry terms as metadata we can offer an alternative navigation scheme for those people within the same niche.

Our terms of reference include the concept of IA classification schemes and IA patterns to help us organise the content in a manner that will make sense to the website’s very broad audience.

IA classification schemes

Schemes can be categorised as either exact or ambiguous and ultimately the scheme you use is the one that is most appropriate for the content at hand. This means you can (and probably will) mix and match schemes within your website.

Exact schemes include:

• Time;
• Alphabetic;
• Geographic;
• Format (of content): consider blogs that use type of posts—articles, opinion, news, tutorials—to group similar content together;
• Organisational.

Ambiguous schemes are exactly that, you’re typically building from scratch doing what’s best for the content you have:

• Task;
• Audience;
• Subject.

An example of a time-based scheme would be the section of your website dealing with news releases. It’s logical to group and sort news articles by the date they were released e.g. by Month and Year because that’s how people will expect to access this content. You would also use a Time scheme to organise event information in an event calendar. The new website will naturally use this scheme for its news but the bulk of the content will use the ambiguous Subject scheme as we wanted to break away from the very deep, jargonised categorisation that exists already (again, I’ll iterate we’re not throwing this out of the project completely though). Task-based schemes seem easy but with a very large website and varied audience types I can foresee this will quickly get very difficult if you tried to apply it to the whole website. I believe this scheme is better suited to web applications where the focus is more obviously task-based. Audience schemes are similar to task schemes in that it could get ugly quick. They work best when the audience can be split into groups with clear boundaries, a user can readily identify what group they belong to as their reason to visit your website changes (sometimes in the same session) and content can be assigned to groups without too much overlap. Remember that here we are not talking about how pages are linked to from a website’s global navigation or sub navigation, we’re talking about the categories or “folders” that the content is assigned to / resides in. Where do you put content relevant to all groups? In all your audience-based containers? For this redesign we will use metadata on the content page to record audience type and in later iterations develop a navigation scheme for key audience types. The subtlety is important to note at this stage of the design process.

IA patterns

Fortunately for us a bunch of really clever people have identified a common set of solutions, or patterns, for particular design problems that occur time and again in the real world. Again, in our content-focussed approach to the IA, we can mix and match patterns based on what’s appropriate for the content to hand and the way people want to access it.

• Hierarchy: suitable for small sites with varied content;
• Database: suitable for content with a consistent structure;
• Hypertext: unstructured content that relies on hyperlinking key words or phrases to discover more—the classic wiki structure;
• Linear: only useful for step-by-step instructional or transactional workflow (like a checkout process);
• Simple hierarchy and database: suitable for general content plus some content types with a consistent structure;
• Catalogue: good for large sets of structured content as seen in ecommerce solutions;
• Hub and spoke: Good for hierarchical content when people will want to return to a central place before moving to new content;
• Subsites: typically used for large corporate or government sites with many independent sections of content (lending itself to the Organisational scheme earlier);
• Focussed entry points: suitable for any content, but usually hierarchical where people want to access content in different ways;
• Tagged: suitable for large sets of content and allows people to find information according to their own terminology (e.g. Flickr).

For our client’s redesign project, the overarching pattern is that of the simple hierarchy and database. As already hinted at, different sections of the website will use different patterns so any online forms would use a linear pattern and the concept of landing pages that we’re accustomed too could use the hub and spoke, subsite or focussed entry point patterns as we see fit. We will reveal the content metadata as tags to provide an alternative navigation scheme rather than to underpin the site structure.

Developing the site structure for the new website

How did we go about this? We just got on with it! There’s no easier way to say it. Denizens of the floor where our team resides will have noticed the brightly-coloured soft-seating area thanks to several hundred Post-It notes. Armed with yellow Post-It notes labelled with the subject name and reference number from the Content Delivery Plan, we went about categorising them into groups using pink Post-It notes. This exercise is known as card sorting and myself and our modern apprentice performed an Open card sort which meant that we created the groups ourselves (based on where we would look for the content). We then performed a Closed card sort by roping in colleagues and only giving them the group Post-It notes. this lead into another more open card sort before we finalised our work to present to the client team. We collaborated in further card sorting exercises with them over a few days before again finalising and documenting the site structure.

We ended up with a site structure that was neither deep nor broad. The project team as a whole want visitors to be able to explore content via the extensive relationships that can be derived from the metadata so we consciously broke away from the official categorisation scheme and grouped the content as we felt people outside of the organisation would do. We based the site structure on the content we knew about—the gap analysis has not yet been completed—but this is no bad thing. Even after launch the website will grow so the site structure must be flexible in that regard anyway. Working within an Agile environment we can adapt to these changing circumstances. That’s not to say we can redo four weeks work in one, but philosophically everyone understands that change is an integral part of the project, that change is OK and that quick decisions can be made knowing that we can undo / redo later.

In just a week the design team tackled this phase of the work, presented back to the client the new site structure and achieved sign-off of this important milestone. The client is really happy, the project manager is happy and I’m… relieved Now, I have until this coming Thursday to examine the content from a Page View and develop the wireframes for five key page types before presenting back to the client once again. Agile can be pretty rough on the design team at times but I’m pleased that an underlining design process is being examined, followed, documented and built on. It will be a busy few days again but the client will be pleased to know that we finally move away from some pretty abstract thinking and start to produce more concrete stuff that actually looks like a website.

Further reading

Too date I’ve collated 33 bookmarks to share with you should you want to delve deeper down the rabbit hole. I’m principally indebted to Donna Spencer however and her very-easy-to-read book “Practical Guide to Information Architecture” published by Five Simple Steps.