Lots of products are the result of compromise. There’s a Venn diagram I trot out that describes how I work to create experiences that combine business priorities with user needs. User experiences sit in the sweet spot where these two sets of requirements are most closely aligned. Information architecture creates systems that combine these two perspectives, it builds a space in which consensus can thrive because everyone sharing the space has a shared perspective.
But as I wrote recently, things change. New products, for example are specifically designed to change things. So how do we design a product that is designed to nudge users to change their behaviour? And if we want our product to respond to this evolving behaviour and relationship, how can we plan and document how our product will change alongside our users? When your designing with the knowledge that things change, a Venn diagram doesn’t cut the mustard.
The shape of things to come
There are a few principles that I return to when I think about information architecture. One of the most important is salience. Salience is an importance word – it’s much more important than relevance. Because salience suggests that relevance changes. Information architecture isn’t just about thinking about things, we need to think about spaces – the ‘idea’ spaces in which the things exist.
The important thing to remember in information architecture is that the spaces we create get their character from two sources.
- the inherent properties of the space (which are limited, often to just the thing we call it)
- the things we put in the space.
When we group objects we create spaces, regions, neighbourhoods. These places have a character, not just because of the thing we call them, but because of the character that evolves thanks to the stuff that is placed there. Have you ever heard of a concrete wasteland in a place called ‘Happy Meadows,’ or other, similarly ironic naming. We get it with people too – ‘Ooh, he doesn’t look like a Henry’ is a reasonable observation. The same incongruity can spread throughout our IA if we’re not carefully aware of the changes our design might undergo.
It’s the realisation that things change that helps you to argue for redundancy in information architecture. It’s also another reason why any IA project should have a clear plan or roadmap for the future that can be committed to.
Information architecture is as much about designing tolerance as it is structure. Because the nature of the spaces you design is dependent on the content that is placed there, the information architecture you design must have the flexibility to flex and warp to deliver within these boundaries. The relative importance or prominence of content will change as the neighbouring items change with it.
[blockquote]Salience forces us to think about the temporal aspects of product design – how will our products evolve and change over time. How do we remain relevant?[/blockquote]
Venn diagrams take a snapshot. But we need to plan products over time.
User experience design isn’t just about negotiating static relationships between user needs and business needs. We’re not designing static structures. We create complex systems that should be capable of evolving.
When we design an information architecture we’re creating a system, not just a structure. If we can describe the system at various states as it is used and interacted with, we can do a better job of getting others to understand the choices we’ve made. Trajectories are one way to describe the temporal aspects of designed products and experiences. When we create information architecture we also need to describe the path that the architecture will take as the product evolves. And we need to describe the assumptions that predicted the direction of that path.
Information architecture should allow products to evolve. Product design isn’t just a compromise, it’s a compromise that will change over time. But good information architecture can turn a compromise into a relationship. Redundancy in IA ensures that your product has resilience. Products without well thought through information architecture are brittle. It’s a bit like a marriage, if you don’t know each other well, if you base things on a compromise, it will fail.
Have a plan and stick to it. But make sure your plan is flexible enough not to be stupid in the future. You don’t need to be a psychic to be able to do this. List the assumptions and features that make your solutions work. List the things that are going to (or liable to) change as the product evolves. The things that make your plan work can’t be the things that are going to change, unless your designed solution changes with them. Work out the shape of things to come and make sure your IA can evolve to fit it.