Survival of the flattest: how to futureproof your website’s IA
Whitehall websites are built on shifting sands.
Reshuffles, changes to the machinery of government, and (until 2011) convergence projects mean that hundreds of pages of content could, at almost any time, suddenly have to be deleted from one government site and added (in suitably re-purposed form) to another.
With that in mind I’ve been thinking about different approaches to website information architecture (IA) lately, as my team and I plan a new BIS site for launch early next year. It’s my hope that, by planning for those kinds of change now, we can limit the risk to the site if or when they occur.
The typical IA design approach, the one I’m most familiar with, is to run card-sorting exercises with a cross-section of the site’s audience to drive out a magic number of top level thematic headings. The new Defra website does this well, with four over-arching policy themes displayed in tabs across the primary navigation. The FCO, DH, Cabinet Office and HMT sites do similar things. CLG, DCSF and the Home Office offer a slight variation with sub-sites for different communities of interest. The principle is the same across all these sites and millions like them and it looks something like this:
This strict hierarchy approach has many advantages. To list just a few:
- It’s audience-focused, giving different groups of people all the stuff that’s relevant to them in one place.
- It tells the story of how everything fits together. Strategy leads to programmes which lead to projects and the context is always clear.
- It’s devolution friendly, allowing for major sections to be maintained by separate parts of the organisation.
But, depending on execution, it can also have drawbacks:
- It can be a rabbit warren to navigate, with too many opportunities for wrong turns and dead ends.
- It can create ‘nomansland’ intro pages which nobody’s really responsible for, because card-sort results are (rightly) seldom a mirror image of management structures.
- It risks becoming Swiss cheese when, for whatever reason, content needs to be hived off to some other website or just plain deleted.
By adopting elements of a more multi-dimensional hierarchy approach, I think it might be possible to have all of the pros of a strict hierarchy and none of the cons. It would look more like this:
In this approach you would start by creating an almost entirely flat IA, so that each discrete area, initiative or campaign gets its own section or article listed at the same level within the site, without imposing any structural hierarchy. In other words any chunk of content that forms a coherent, stand-alone topic, big or small, would get its own entry in the list, its own landing page, and as many child pages as needed to tell the story.
Over the top of this pool of equally-weighted topics you could then overlay various ways of finding and filtering the information – potentially as many ways as users need. For instance:
- By A-Z - driven by page titles and allowing for alternative or synonymous terms
- By theme – driven by tagging each chunk with terms from a preset list of themes
- By recently updated - populated from system metadata with an override for trivial edits
Using the themes data, you could also serve up the same list of topics:
- By audience – separate lists of content for each segment of the site’s user base
- By PSAs and DSOs – listing workstreams that underpin each strategic target or objective
- By Minister – associating ministers with the specific policies they are responsible for
…and potentially more ways besides.
Compared to the strict hierarchy approach, it seems this model would continue to give users access to everything they need in one place via the themes filter; would be just as effective in providing the link between specific work areas and the grand strategy; and would be even more devolution-friendly with topics corresponding neatly to the teams responsible.
What’s more, it would reduce the number of clicks from homepage to policy detail, simplify navigation all round and make it much easier to port content into or out of the site without requiring a root and branch re-think of the IA.
So there it is – a more futureproof IA. What do you think? Have you tried this before and come across pitfalls – and ways to avoid them – that I should know about? I’d really appreciate any feedback you may have.
Image credits: Sandcastles by Fernando; IA diagrams by web design from Scratch.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=56a6aa02-4a3c-4a32-9d9e-eec64d9e5708)
Related posts (auto generated)
If you enjoyed this post, why not leave a comment or subscribe to my RSS feed to get future posts delivered to your feed reader?
Comments
I like this approach and we always tried to achieve this through the poly-hierarchical approach in that a single chunk of information may sit in more than one location and will be available to users regardless of their entry point into the site. Essentially this is what a content management system should be doing by default.
I think once you have the audience driven top end you can deliver all the right content below providing you can reproduce the content without having to actually duplicate it.
Good luck with your approach
A good question. A recent project of ours has involved capturing and entering a lot of metadata about various resources as a first step, and while we had certain ideas about ways to present these resources initially, what we found, in part, was that once we’d gathered the metadata, we could actually come up with new ways of sorting and filtering the resources by this data.
For me, there are some interesting points coming out of this “bottom up” approach:
- You can determine what metadata you want to capture on a per-resource/page basis, but it’s not really until you’ve assembled the metadata itself that you know what the “nature” of the content -as a “whole” – is. Sometimes the most useful way of navigating emerges naturally once you know what the nature of the metadata is.
- Metadata allows you to make a lot of *inferences* – i.e. if you want to form a new group of resources, you can very easily, say, create it from resources which have property A *and* property B.
- Something like how you set out in the second part above, we now have about 3 or 4 different ways of filtering resources – making it fairly easy to explore these different routes, and to work out which ones is right according to your reason for looking at the site in the first place. Each route is effectively a different way of assembling a filter, but you can provide what is effectively a different interface, different instructions, etc, to each, according to audience et al.
The downside is, of course, that you have to spend the effort making sure everything has the correct metadata in the first place, which is by no means straightforward…
This problem was identified years ago in local government and a solution emerged from an Open Source CMS, and the then “Government Taxonomist”. The solution which emerged is now known as the LGNL ( Local Govt Navigational List ).
http://www.esd.org.uk/Standards/lgnl/
Agree with Carl, above, your CMS should permit this kind of behaviour, but it is rarely done correctly, and is another shining reason why Proprietory CMS’s just arent up to the job IMHO.
On the Esd page is a link showing organisations who say they are registered users of this list – but very few can actually pull the trick off.
(Mostly they implement what I term the “LGN-Lost” antipattern – http://www.councilsites.co.uk/about/antipatterns.htm )
In RDBMS terms (if you’re a bit of a data head) you simply create a referential table between your “main landing pages” and the taxonomy (or menu-system if you prefer).
As a result of implementing it there are stacks of unexpected bonuses you can reap, not least of which are, a propensity to lean towards:
-usable and predictable urls
-coolURIs
Which can really motivate you to check out the LOD (Linked Open Data) crowd.
But also the ease with which you can then
-create data driven tag clouds
-usability improvements
-search ‘boosters’
Real and meaningful user-behaviour metrics can be gleaned which when matched with temporal details can also lead to predictive navigation hints.
(eg via agents, or agent-prompted users: “on the last weekend every month the selection of the term xxx goes up 78%”. Lets put it on the home page on the last Friday of the month)
I have to say most of this is stuff spins-out after implementing a controlled vocabulary, but poly-hierarchical menus were catalyst to tease this kind of stuff out – well, if you, like me are both a data-head AND a usability-eagle.
HTH
@ Scribe
Meta data, good point.
It depends to which degree you feel the meta data should permeate your GUI layer, but if you go for 100% …
“The downside is, of course, that you have to spend the effort making sure everything has the correct metadata in the first place, which is by no means straightforward…”
Absolutely agree with that, expect to get murdered by your users if you don’t supply them the correct tools to do this, (this was the hardest part) or if you don’t have the structure in place to do this en-masse on their behalf.
Great post – been trying to do this for a while now but it cannot work in any sort of devolved content publishing. A tight control (ie highly motivated and skilled centralised publishing) needs to be maintained for the correct categorisation to happen.
Great post Neil. This is the holy grail…. but I think the main challenge is putting it into practice. Training content authors will be a key requirement. You may need a dedicated team who can train others to ensure that quality is maintained. Also, a method – possibly automated or part-automated – to check that the system is being used as intended is essential. Good luck – definitely worth the effort.
I’m about to do something similar at the FCO. I’m sticking with the single, canonical mode of organising pages (no way around this I think: users will always prefer to click than to use search), so it won’t have the flatness you’re talking about. What I’m planning to offer is horizontal cross-links between content related according to our classical IA facets: theme / actor / locale / timeliness etc.
As pointed out, metadata is the key. At the FCO our CMS can handle it, but we have a fairly messy and inconsistently applied classification … not looking forward to sorting that out.
The user testing I’ve done suggests that the best place for a ‘related content’ element is not the right-hand col, but at the foot of the core content. Here relevant onward journeys are offered immediately after the user has read the content they came to see.
Also note that as well as providing nav to goal seekers, related links fulfil a promotional role to non goal seekers, so it’s a nice twofer.
@ Rob Pearson
“Here relevant onward journeys are offered immediately after the user has read the content they came to see”
Except if you acknowledge that “maybe this content is not actually the content you expected to see”.
Which brings in another observation, not connected with your point per se.
Poly-hierarchical menu structures can nuke breadcrumb trails.
The “this subject belongs to that category” link can no longer mean “this is the way you came, hence this is the way back”.
Though you can kludge round it quite nicely with cookies, or tracking – though you also have to cope with the case that someone arrived on this page by following a deep link.
This is almost exactly the vision I had for the MoJ site. I identified a clear set of priority tasks that users came to the old DCA site for: news releases, consultations, contact info and specific professional guidance. All the rest ( biogs, ‘policy’ pages etc was just fluff – though useful for navigation purposes.
So the idea was to focus on the content for the key tasks and tag them with an agreed taxonomy – minister, DSO, PSA, policy area and type so that they could surface anywhere on the site where relevant (e.g. all speeches by a minister on his/her biog page, on the relevant policy page and in the speeches section of the news site.
Sadly the CMS just wasn’t up to it so we approximated it as much as possible and bodged the cross-linking where we could.
Conversely when we built the Wales Office site with SimonD, we had all the functionality to do this out of the box but no content to do it with….
@ Paul Geraghty
> Except if you acknowledge that “maybe this content is not actually the content you expected to see”.
This is a valid, even likely scenario but typically I’d expect a user to hit the back button pretty quickly if the page didn’t look like it supported their goal. I wouldn’t expect a user to treat the page as a new start point for their search …although usability testing would make this clear.
> Poly-hierarchical menu structures can nuke breadcrumb trails
Hmmm, most breadcrumb trails (all that I’ve ever designed) show the page’s position in the hierarchy, not the user’s path to the page. ‘Breadcrumb trail’ is a poor metaphor, but my experience is that that this is pretty well understood by users.
In fact I can’t think of a site that literally shows your path through the site: I’d like to see one (and try and break it 
)
I think the approach begs the question, why are you starting with the content? In other words, what is the website for?
I would favour an approach that starts with the tasks you need people to perform, prioritise these and base key navigation on them. If you have content that doesn’t fit into these tasks, you have to challenge whether it’s worth having at all. This approach would also tell you if you’re missing content.
I think card sorting is well suited to organising taxonomies, but it’s limited when it comes to assessing user journeys, no matter how broad your IA.
Thanks for all these great thoughts, and sorry it’s taken me until now to reply.
The comments about CMSs falling short of supporting this sort of thing struck a chord with me. I’ve so far been bitterly disappointed by every proprietary CMS I’ve used. (Fingers crossed for the next one, but I won’t get my hopes up).
On metadata: our plan here is to keep that pretty simple too, not get bogged down in too many variables right now. The ease of publishing is at least as important as the front end user experience, and I’ve learnt the hard way about over-specification of the back end. So for starters we’ll have:
- title and alternative titles, comma-separated, for the A-Z
- subject (from the IPSV vocabulary)
- themes (from a preset list with the option of creating new ones on the fly, which admins will keep an eye on)
- keywords (unrestricted folksonomy)
- the usual date published, date updated, location, contributor and publisher Dublin Core gang
(There may be more fields I’ve forgotten to mention – we’ll know I have if one of the BIS guys jumps in with a comment…)
From the above, we can drive other lists, like associating themes (and therefore policy topics) to ministers or strategic priorities.
So I’ll heed Adam’s wise words on training and quality assurance, but not go so far as implementing something like the LGNL just yet. Though some stuff, like consultations, will be linked open data (RDFa).
@Rob – I’m a fan of your work. And now of your blog, great title btw. Morello can handle that? Not without some bespokery, I’d have thought..?
@Jeremy. Ahem – yes. I should have had something in my post along the lines of ‘heavily inspired by MoJ’. We have been poking around the Justice A-Z a lot recently. Slightly different from what you describe, we’ll split content by type first, with separate templates for news, speeches, consultations, publications, ministers’ profiles etc. Then the narrative/article stuff that’s left will get this flatter IA approach.
@Phillipe, a valid point, and happy to say we’ve done that work as well and are user-testing it in parallel.
Keep the thoughts coming, and let me know if I’ve misunderstood something.
Some interesting comments.
@Paul Geraghty
“another shining reason why Proprietory CMS’s just arent up to the job IMHO”
This is simply untrue: there’s no barrier to feature functions because of licence model. If you want to adopt open source for other “ethical” reasons then fine, but to say that the kind of licence a product is sold under has an impact on ability to meet functional requirements is deeply flawed.
@WhitehallWebby
“Sadly the CMS just wasn’t up to it so we approximated it as much as possible and bodged the cross-linking where we could.”
I sympathise, but how did you select the CMS if it couldn’t meet your IA requirements? Or was this a flawed implementation by a service team that didn’t understand how the product worked?
@Neil Williams
Why is government procuring yet another CMS, particularly one with so few experienced partners in the UK?
What I’d really like to see is a published strategy for organising content on government sites. This can then be challenged by all the relevant parties independently of technological constraints. Once agreed, the strategy can then go to the CMS providers — open source and proprietary — to see how their products meet the requirements. Is this feasible, or on the agenda?
How about the Westminster Arms? I’d love to meet those of you I haven’t met yet. I could do Wednesday 7th, or most evenings the week after. I’ll try to bring some Home Office people too.
http://www.beerintheevening.com/pubs/s/21/2102/Westminster_Arms/Westminster
I’d love to meet those of you I haven’t met yet.
How about the Westminster Arms?
http://www.beerintheevening.com/pubs/s/21/2102/Westminster_Arms/Westminster
I could do Wednesday 7th, or most evenings the week after. I’ll try to bring some Home Office people too.
How about the Westminster Arms? SW1P 3AT
I’d love to meet those of you I haven’t yet. I could do Wednesday 7th or most of the evenings the following week.
[...] Information ArchitectureSurvival of the flattest: how to futureproof your website’s IA Mission Creep [...]
[...] Information ArchitectureSurvival of the flattest: how to futureproof your website’s IA Mission Creep [...]
That’s the one near the Abbey and QEII Centre, right? I’ll be there. Clutching a red carnation and a copy of Don’t Make Me Think.
Wish I could be there, but a touch out of my way.
Re: the A to Z on the Justice site. That was just a sop to policy owners. The real stuff is in the news and publications sections. Are stats showed that no one read the policy pages which is why we restricted policy teams to 200 words max.
…. should have said we sold those pages as signposts – to relevant content on our site as well as other govt sites like Direct Gov and related third sector sites. But we knew that most of the traffic was going to the related news/ speeches etc rather than via the policy pages.
Just a reminder it’s beers tonight, 1800, Westminster Arms. See you all there. This is me (I’m the one on the right)
http://www.flickr.com/photos/robotperson/817502624/in/set-72157600833032887/
The real issue is that everyone looks for information in different ways. You need to offer up a range of ways to find the same information – with the navigation and using metadata as the most used.
At the other end of the scale from the strict hierarchy would be a page with only a search box (and no links).
I think that your right to suggest a that information should be available by filtering the data in a variety of ways, however as mentioned above this brings metadata and taxonomy issues up. However, if you only provide this method for finding content then the site is as limited in terms of usability as if it only had the traditional structured IA.
Hello, I'm Neil Williams. I'm a government web geek, a dad, a husband, a grower of veg, a keeper of hens and a lapsed comedy writer, roughly in that order. 
It sounds like a marathon task, but it looks like you are gonna boss it. There is nothing worse than being caught in a loop on a gov website. I run a small one and know how this can happen, and I realise what a big job you have taken on. I am glad someone is doing this good work. Kudos, and sorry I am not clever enough to help, just posting here to encourage.
chris.