Concurrent information architecture

I often think of information architecture as providing ‘direction’ – it defines an axis along which an experience should flow. IA lays the foundation for a design – so it prescribes some of the shapes that will emerge as a product or service is designed and built. But I like to think it also helps to shape the experience contained in those places – it points and provides a direction to follow in the space.

When I’m working on an IA project, in the early stages, my focus is on discovering a unifying principle or model that makes sense of the domain or design challenge. I’m looking for the direction or axis.

I sometimes think of IA as carving out a direction – sort of like making the channel of a river. The ‘water’ of the actual experience is usually constrained by the IA, occasionally it overflows, sometimes it resists or rewrites the course of an experience. But generally IA suggests not just a way of making sense of a design, but the way. IA deals with the spatial aspect of design, so I think about it as providing direction through the spaces it defines.

Multiple directions

As I’ve been thinking more about the architecture of complex systems and services I’ve been searching for a way of describing situations and concerns where multiple information architectures intersect. If IA provides the direction, pace and facilitates the flow of experiences, what happens if journeys jump across different architectures?

As content becomes more fragmented, aggregated and disaggregated I think this happens more regularly.

The BBC website is a good example of this. We have separate products offering News, Sport and TV programmes – and lots of other things. We also have a ‘homepage’ at www.bbc.com that aggregates and presents the best of the BBC. And we link between these products and services. News will very often link to sports news in the Sport ‘site’, for example.

The challenge of this has always been finding information architecture that makes sense in the individual product context – the best IA for the News website, for example – but also create IA appropriate for the next biggest context – the BBC online as a whole.

Networked systems architecture

I’ve been struggling for a name for this challenge – for discussing when one architecture contains a smaller, denser model and when separate systems interact to support the movement of actors between them. I’ve toyed with networked systems.

I’ve talked about ‘spatially networked systems’ as being systems that are connected across different structures or spaces – like in the example of BBC News, Sport and iPlayer. They are separate but connected ‘products’ which form a larger networked system.

Without shared architecture they would remain ‘un-networked’. They could be linked to and between, just like any other part of the web. But they wouldn’t make as much sense together as they could – the shared architecture creates a networked or connected system. It supports sense-making when actors change direction or jump to another structure within the network.

I’ve also used ‘spatially networked systems’ to describe systems and information architecture that enables progressive enhancement. I’ve described architectures with the same ontological and taxonomic foundations but which are experienced differently across different devices. The underlying structure of the system is the same, but there might be layers to the experiences they support and enable. One example of this is the way we deliver experiences to a range of TV and large screen devices, using the same architecture to support different experiences on non-smart TVs, non-connected smart TVs and connected smart TVs.

Finally I’ve talked about ‘temporally networked systems’. By this I’ve meant systems separated by time. I’ve used this idea to describe how you might design or suggest the evolution of an information architecture. What features of the IA can scale up as a system grows in size or complexity. What elements might want to add in the future, which will be consistent with the design principles and model established in the initial design.

These were all ways of thinking about how different information architectures interact with each other – whether they’re different systems experienced at the same time or the same architecture as it evolves or changes through time.

Concurrent architecture

I’m now trying out the label ‘concurrent architecture,’ hoping that it expresses the idea of information architecture which intersects. Although the architecture contributes to a larger system or service, it can also be thought about and developed independently. It exists as an individual architecture and part of a larger system or design.

Here’s an example.

Sonos make audio equipment. I’ve got a few speakers, in different rooms, and have been playing with the service and experiences they enable. I think I may have found an example of what I’m talking about.

Sonos has a fairly traditional IA for finding and playing your audio content.

You can search your media library by artist, album, genre – all the usual suspects. You can also access media from multiple services – radio, Spotify and other music services. I think of these as demonstrating the type of ‘networked’ design I’ve just written about.

The ‘concurrency’ occurs when you start to think about the physical spaces that music is being played in. Each speaker represents a different place that contain that ‘IA of music discovery.’ You find the audio and play it for a place. But the places also have a fluid structure. You can group speakers to create new places – Kitchen & Dining Room, Dining Room & Long Room, Bedroom.

The way my brain makes sense of this is that the ‘places’ are the primary unifying principle – top of the tree. They contain a separate information architecture that can be poured into these places as they’re created – by buying, naming and then grouping or ungrouping speakers.

For some time I’ve been concerned with how we integrate complex and overlapping information architecture. I’ve worried that ‘one-IA-to-rule-them-all’ is often impossible to create. I’ve embraced bound contexts to manage complexity and focus on deliverability. I’ve tried to balance the resilience, efficiency and simplicity of the IA I create with coherence and connectivity. I’ve thought about containment – one IA containing another. I’ve thought about connection – using relationships to connect models at their points of intersection.

But I’ve struggled with language to describe decision making in these designs. I like the phrase, ‘turtles all the way down.’ But I’m interested in more detailed language and metaphors for the relationships between models and systems I architect and design. Where should the boundary fall between one information architecture and another? When is one site or service enough? When should you expand your scope and when should you narrow your focus?

I’m still not sure there’s a straightforward way of getting this balancing act right to make sure your IA is ‘big enough, but no bigger.’ But I like the idea of complimentary, concurrent architectures that are built to be compatible. I’m pleased to be developing more language to use in discussions of containment and inclusion alongside considering connection and compatibility.

I think having these conversations will help us to create information architecture that enables users to make sense when they switch direction and jump across systems. Trying out words to express these ideas should help me to design this sort of architecture in the future.