The third way for designing enterprise wiki information architectures


Last week I was talking to someone about enterprise wiki adoption. I ended up sketching a rough diagram like this so we could talk about the need to design (in an active, participatory sense) social computing environments that provide enough information scaffolding so that users can be productive at the beginning but that also allow emergent, socially negotiated information structures and usage patterns to develop over time.

The problem I’ve experienced in the last decade or so with traditionally organised information systems is that they have typically been based on a planned information architecture model. That is, someone comes up with a master plan for the intranet navigation scheme or the document management system file plan. In the beginning this all works really well – faced with a new system, people like the certainty of knowing what goes where (particularly if they are moving from one system to another). But over time the effectiveness of this structure begins to degrade – new people arrive, organisational functions change, people start to take short cuts, unforeseen requirements arise, etc etc. What often happens is that organisations either get lost in the beginning by trying to design the perfect structure so it will never change or fall into a cycle of periodic efforts to review and update this structure.

This is great for people that like to run card sorting exercises, but not much fun for the people that just want to get on and use the systems on a daily basis. Besides, they know that each review will require them to learn a brand new structure or even worse, force them to migrate their data yet again. These heavily planned structures also have a tendency to support the lowest common denominator, but of course as people learn to navigate an information architecture they will want to use short cuts to get to the places or manage the things they are working on most frequently.

However, a purely user generated information architecture is not the answer either because these take time and nurturing in the early stages before they gather enough momentum to become efficient. Without out the right support, this approach can fail before it even gets started because the lack of structure becomes a barrier for some users. In fact, where this support is provided what we find is that someone or a small group of users create that structure for other people to use – however, the danger is that this proactive group may not actually reflect the broader needs of all users. Providing users with even a bare bones information framework that is only partially right can even help with  the overall design process, because most people don’t like to start with a blank page.

What is much better is a hybrid approach that provides enough structure as a foundational information architecture layer but also allows a user negotiated information architecture to appear. This allows you to maintain productivity by ‘jumping’ from a reliance on the planned architecture to the negotiated structure, once it becomes sustainable. This foundational information architecture should:

  • Create a familiar environment;
  • Accommodate the full scope of the organisational business systems or processes it is designed to support; and
  • Provide just enough detail so that people can begin working in it immediately, but without blocking future evolution.

This idea is relevant not just to wikis, but any kind of enterprise information system that is subject to information architecture decay. However, its one reason why I encourage people to customise wikis, rather than simply implement them out of the box with the hope that if they build it, someone will come. Just bear in mind, this requires a design approach that is participatory otherwise the jump may become too wide when it becomes time to cross.