Genesis. 11. 4-9.
They said, “Come, let us build ourselves a city and a tower with its top in the heavens, and let us make a name for ourselves, lest we be dispersed over the face of the whole earth.”
And the LORD came down to see the city and the tower, which the children of man had built. And the LORD said, “Behold, they are one people, and they have all one language, and this is only the beginning of what they will do. And nothing that they propose to do will now be impossible for them.
Come, let us go down and there confuse their language, so that they may not understand one another’s speech.”
So the LORD dispersed them from there over the face of all the earth, and they left off building the city. Therefore its name was called Babel, because there the LORD confused the language of all the earth.
That’s a weird way to start to talk about IA. But there are three reason why I started my talk with that story.
The first is that I gave a version of this talk a couple of times last year and I used the phrase ‘21st century towers of babel’ to talk about some of the digital places I’d seen – magnificent vertical structures, that while internally coherent, didn’t make much sense to one another. They don’t link very well. They make communication hard. They miss opportunities.
So I thought I’d go back to the source and introduce the metaphor properly.
The second reason is that projects can sometimes feel a bit like this image – communication is very hard. Gaps in understanding, ambition, technique and concern abound in projects. The ‘language’ of productivity in creative projects is sometimes confused, sometimes we lack a common vocabulary.
And the third reason is that I wanted to talk about ‘time’ as well as ‘spaces’ and places we create as information architects.
The story of the tower of babel is an etiological tale or an origin story. Origin stories aren’t jut cool if you’re a superhero. Origins are interesting. And stories about origins can travel into the future and shape it. Origin sets something off on a trajectory. It makes some futures more likely, some futures feel inevitable.
That’s what my talk was about – structures with internal coherence but relatively poor connections, the challenges of communication and the the importance of time as an extra dimension to consider as you design information architectures.
And it was also about the relative power of stories to tie everything together, focus on the gaps and to bridge them with meaning.
Back when I started thinking about information architecture I probably thought along these lines. I used to think that this was a pretty good mantra for information architects… It talks about places – information architecture is fundamentally interested to the notion of place making. And it suggests that by thinking about things, we can learn more about the place or places where that thing might belong.
But now, it’s that relationship between things and places that forces me to condemn this to the past.
Things are different these days.
It used to be that you put something on a shelf and the world was a little more organised.
Information architecture exploited everything we’d learned from library sciences and we carried forward those notions of organisation. Make places. Put things in them. It works fine for some types of places and some types of things. In the physical world a thing can only live in one place.
The relationships between places was simpler too. A place could only be in one place at a time. Places could only be contained by bigger places. The TARDIS didn’t belong in the past where it was invented, places were too simple back then.
In fact, if we think about the BBC before we created digital experience, back to the invention of Dr Who in 1963, through to our first broadcasts in 1922, although the ‘things’ we had to organise had the whiff of the immaterial about them, signals transmitted over the air, we still organised them in a similar way. We used schedules, ordered lists. There was a simple one to one relationships between a thing – a programme – and a place – a time in the schedule.
A lot of my early thinking about IA carried forward things I knew about organisation in the real world and applied it to digital things and places. I leant heavily on taxonomic hierarchy. I winnowed down categories. I built structures. I experimented. But I still tended to build up and down using tree-like structures.
I wasn’t around for it, but I suspect that when the BBC first got onto the web in 1997 the thinking was very similar. We had a few pages, a single digital service, a small self-contained world for the digital BBC. But things have changed.
We’re still striving for a single service that connects all our screens and services. But the BBC is now ready to think digital first.
We now build places out of things, times, channels, smaller places. We build things on the web, on interactive TVs. We build apps and cross-channel experiences. They’re a mix of data, noise, information and because many are online there are also a few pictures of cats…
We have multiple products – News, Sport, Weather, TV channels, learning content, coverage of live cultural events, weather services – we’re British, we love talking about the weather.
The BBC delivers services to 35 million devices, so a lot of users, worldwide every day. We’re the 3rd most popular website in the UK, the only British site in the Top 10 and we’re consistently the most trusted. We create around 1,500 URLs every day.
This scale and the scale of opportunity that new technologies have offered means that since 1997 we’ve made considerably more things and created very many more places.
And things are different now. As are the places that contain them.
Information architecture isn’t just the science of separation and reduction, winnowing down categories to move people progressively onwards. Onwards isn’t straightforward either. Journeys aren’t just moving from top to bottom – they’re wiggly and squiggly and sometimes confusing.
And it’s that idea, that while the organisation of physical things established a nice, clear pattern of putting ‘things’ in ‘places’, it encourages us to think about difference and separation.
We create coherence by grouping things that are similar. Which also separates things that are different. For me, IA is the science of separation and the art of connection. It’s a special sort of alchemy. And if we focus too much on separation, and ignore the gaps that this creates we miss opportunities.
So I’m always looking for more ways to pay attention to the relationships and the loose joins we can create to describe them.
A few years ago I started talking about ladders and climbing walls.
Simpler web structures, built using only taxonomic hierarchy feel like ladders to me. Ladders are wonderful. They move you up and down with efficiency and precision. But they’re not so good with lateral movement.
Whenever I climb a ladder there’s a moment of near terror when I have to move from the ladder to whatever it’s resting on. There’s a moment of ultimate jeopardy when it feels as though my centre of gravity rests absolutely nowhere. It’s a moment of doubt and fear.
You look at some websites and digital experiences, even when they’re part of a product suite, single brand or ecosystem and it feels like we’ve been building ladders, resting up against tree-like structures or 21st century towers of babel. Even when they’re internally coherent, moving between them is fraught with challenges. It feels like that moment on the ladder.
When we create gaps in information architecture I think we create similar moments for our users, for our colleagues, for our clients. Gaps can be frightening. Some web structures feel like this. Or if not frightening, they don’t particularly reward exploration or encourage lateral exploration.
So I started talking about climbing walls. They reward exploration. They encourage you to look sideways, move sideways. They’re much more like the web that we aspire to build. And the way we try to do this is by following some of the principles of domain driven design. Instead of a hierarchy, we create a multi-dimensional model. We understand and try to reflect the messy tangle of relationships that exist in the real world.
A domain model allows you to describe and make the otherwise invisible facts or implicit assumptions that you might find in a hierarchy explicit.
We iteratively build more knowledge into the abstract model we’re creating. We don’t just describe the hierarchical classification. We build out the context that went into the classification, building a model to describe the richer set of properties which underpin the classification. We reflect the real world.
It allows us to create classes of things, with instances, with properties, rich webs of relationships.
We’re no longer organising content, filing it in the right place in a structure. We’re building contextual models, so that when we start to make a thing, the context or structure is curated for us. This curating context enabled us to move towards dynamic semantic publishing.
For example we created a model to describe the Olympics. We describe venues, events, rounds, athletes, nations. We use linked data to make statements about these things and our content. It means that when we create a news story about an athlete it can appear on pages for athlete, sport, venue and nation. And our power extends beyond pages – we can allow our audience to follow these things, get alerts for weather at a venue, notification for updates to an even or athlete. We start to understand and reflect the world.
But we face the inevitable challenge. There are always spaces between the places we make.
One of my big concerns is building links to increase discovery of content and the value we offer every single audience members. We don’t have a problem making things – with 1,500 URLs a day there are plenty of things and places. The challenge is the connections, the loose joins that enable journeys, the inevitable gaps.
When we model a context we draw a box around it to mark the extent of our concern. Determining the boundaries of your context is very important. Given the size of some of our domains – 3 million pages describing our programmes content, thousand of natural history clips and education resources, we focus on the core domain, the most valuable part and then we build our products.
While this helps make the thing and enable lots of internal linking, it doesn’t guarantee links outside of that bound context. It probably does make external or cross-domain linking easier. Each model we create can include hooks, bits of data by which models and domains can interact. But we need to exploit that capability and it sometimes doesn’t happen. Webs are hard to make. Maybe connecting one bound context to others is a little harder still because the density of internal linking complicates discussion of external and cross-product linking.
This graphic is taken from a project that our marketing and audiences team carried out looking at links between our products online. Each petal on the flower represents the links within one our products – News, Sport and iPlayer. There are also grey lines, showing the links across and between products.
We know that there are overlaps of context between products. We know that programmes are about the same things as our news coverage. We know that our education and revision content for school children concerns the same real-world concepts as content we produce for radio, outside of a specific learning context. We know that there are opportunities to link these domains more completely. So why don’t we?
It’s difficult.
We constantly evaluate the balance between that art of connection and the science of separation. We have strategies for cross-product linking. But because we focus on the bound contexts, because we pour our energies into making the best specific place, rather than the larger place that contains it. It’s difficult.
A project mindset focuses on the bound context to limit complexity and focus on deliverability. It makes modelling possible and delivery easier. But it can lead to a sort of isolationism. We’re trying to overcome some of these challenges with ‘continuous delivery’ to break out of this ‘project’ thinking. But it’s an evolving challenge.
Time is invisible but it exerts a profound influence on the way our information spaces are experienced and evolve. Things can either grow together or apart. And even if you don’t believe that, things will grow. And as they grow they accrue a sort of gravity. I thought about this as a sort of ‘dark matter’ or invisible force that underpins the way our digital places interact. When this remains “dark matter” – invisible, ill-understood and un-used, we’re missing opportunities.
And that brings us up to date. That’s why we need to think about these things. But what should we do differently?
I think we need to build a culture of connection.
I think the ideal web is a series of small things loosely joined. But the things are much easier to focus on and think about than the loose joins and the gaps that they bridge.
We should find ways to encourage people to think about the invisible forces between the things just as much as the things themselves.
And I know that sounds a lot like “just good IA”. I think it is.
So I was looking for a model or metaphor that would sum this up. I love making models. Whether I use language, post its, pencils or pens – I think that’s where I’m most productive. And I thought I’d found one to describe this idea.
I thought about the planets and the solar system. The planets are self-contained but stand in relationship to one another – a little like the digital products we build.
And I liked this idea. It was almost a model of a model. Have you ever made one of those models of the solar system – small painted planets held on delicate, spindly arms. Plastic gears giving jerky motion to orbits that would rip real planets apart?
I thought about that. I thought about explaining to others that the places we make are like the planets in the sky and that we should think about the Gravity that influences our users as they try to move around and between our places. Gravity can trap you, it can secure you. It can wield an invisible influence.
And then I thought I should add time into the mix. Those static, rotating spindly arms don’t tell the whole story – maybe the movement through time is just as important as the movement through space – and considering the two together will help us to build more complete and complex models and systems. I try to architect spaces in which experience happen, in time. I create designed spaces which evolve through time. I should think about time too.
There is always a bigger context. But I think too often people get hypnotised into paying attention to things, rather than relationships. The suff between the pages is often the thing that will make or break a service or experience – even though it’s sometimes the stuff that the user doesn’t see or care about.
It’s really hard to think about invisible stuff – like assumptions, connections, dependencies. It’s hard to think about. It’s our responsibility.
One way of doing this is using very simple flow diagrams. But the important thing to stress is that it’s not the digram that matters – it’s the process you need to go through in order to create it.
I like fish.
I like the shape – it describes perfectly the process we go through as we document and make progress in making the invisible and unspoken visible, tangible and shareable. An initial problem framing and definition propels us forward and we then cycle through divergent and convergent processes as we describe and help shape decisions.
We zoom in and out throughout a project, ‘fishing’ for insight.
The process usually involves many conversation. As we talk to people we document what they tell us. We explain and share perspectives, we show connections and relationships.
We start with simple assumptions and try to validate and refine our understanding.
We keep the annotation simple – we’re not slaves to UML or entity relationship diagram conventions – we need this to be meaningful across disciplines.
So we sketch out the system, based on assumptions, making them visible. We Identify stakeholders for each part of the system and then work with them to flesh out detail on their part, we continually iterate, validate and distribute,
We fill in those gaps. Complex sub-processes called out and expanded on a new page.
Unknowns are flagged so that we can come back to it. Where integration between systems is required we flag it and begin those conversations.
We can think about the design of the thing as a service – how does it manifest across platforms, devices and sessions. We can use this to describe the experience and flow of a user through a system. But we also use these simple diagrams to talk about the system from an internal technical or organisational point of view – using them to describe the flow of data and information within and between systems.
And we always do this with multidisciplinary teams.
We’ve learned through domain driven design that any domain can be expressed with many models, and any model can be expressed in various ways in code.
Engaging with software engineers ensures that our model can grow and evolve to reflect the actual implementation. Because if our models makes implementation hard, or if we break some software design principle or we choose a model that can’t be accurately put into code – the conversation becomes fragmented again.
And why is that important, now? I think we’re living in an age built for information architects… but then maybe we’ve always been needed.
During the construction of the pyramids 4,000 years ago there was a point when the relationships among the elements increased far faster than the number of elements.
Pyramids were no longer just burial sites. They had become demonstrations of political and religious power, secure repositories of god-like rulers and their wealth, and impressive engineering accomplishments.
Each demand, of itself, would require major resources and were complex. When taken together, they generated new levels of technical, financial, political, and social complications. The complexity of the relationships were well beyond what engineers and builders could handle.
So architects started to take care of understanding, documenting and shaping decisions to resolve some of this complexity. Which reminds me of that fish… understand, describe and decide…
In ‘The hitchhikers guide to the galaxy there’s a creature called the Babel Fish. It’s described like this:
“The Babel fish is small, yellow, leech-like, and probably the oddest thing in the universe.
It feeds on brain wave energy, absorbing all unconscious frequencies and then excreting telepathically a matrix formed from the conscious frequencies and nerve signals picked up from the speech centres of the brain, the practical upshot of which is that if you stick one in your ear, you can instantly understand anything said to you in any form of language.”
While I’m not keen on being called the oddest thing in the universe – I like the sound of the other stuff.
IAs create shared meaning – it’s not the diagram that counts, it’s the shared language.
This is the same process we’ve engaged in for DDD. According to Eric Evans, a domain model isn’t a particular diagram. It is the idea that the diagram is intended to convey. It isn’t just knowledge in a domain expert’s head. It is “a rigorously organised and selective abstraction of that knowledge”. A diagram can represent and communicate a model, so can carefully written code, so can language; spoken or written. Or it can be the otherwise invisible understanding between team members. Each of these representations should use the same ubiquitous language.
IAs all do something similar to that babel fish – we engage in a practice of artful synthesising – creating shared and shareable meaning.
The diagram is another acts of placemaking – it creates a thought experiment teams can inhabit and try out different designs and assumptions. Teams can occupy it together, share and shape the space collaboratively before a line or code is written or even an interface mocked up.
I think that’s what we do as designers. We experiment. At the start of most design projects we begin with a question beginning with ‘How might we…’ and we play with constraints and opportunities until we find an answer that satisfies us and delights our audience. Each answer grows in fidelity until we can point at an actual experience and and answer that question with ‘like that.’
Until that point we’re just dealing in models and abstractions – turtles all the way down. But the more accurate we can make the models and the smaller the gap is between the model, the software, the rendered thing and the actual experience – the better we’re doing our jobs – because the more certainty the team has, the more confidence, the more shared commitment, the more intentional we’re being in our design.
When we are one people, when we have one language, then this is only the beginning of what we can do.
In the final section I spoke about trajectories – some wiggly lines we’ve been using to describe experience.
The boxes and arrows of the flow diagram describe the system, spaces and places that support an experience. But time makes experiences of space subjective. So we’ve been exploring ways of considering and depicting those experiences.
And we’ve been using wiggly lines.
Lines help you to interrogate every moment of strength and weakness in an experience. They help you avoid being fixated on interface, you consider a broader context. We want to create experiences with internal coherence and continuity, so why wouldn’t we design and interrogate them using a representation that stresses that continuity – a single, continuous line.
Lines allow you to tell simple, abstract stories. The physics of stories almost guarantee engagement and encourage the right kind of interrogation of ideas and designs. We use stories to reflect, inspire and synthesise. The inspired synthesis of information architecture can be delivered in stories. Stories are the artful making of sense that we’ve indulged in for millennia – we should continue to use them.
I think this is especially true now that we’ve moved towards creating more complex places made out of information. Hierarchies have a sense of direction – they flow from general to the specific. They’re IA with an implicit sense of direction. When you build flatter, graph-like models, the trajectory of an experience can flow in multiple directions. I think you need to work harder to explore the experiences that your design supports and work harder to explain the intended happy paths through those places, so that everyone understands the journeys they need to support.
Stories support decision making as they allow you to lay emphasis on the direction as well as the points of interest along the way. Drawing them makes them tangible – you have something to point at, something to anchor a memory or commitment to and something to return to.
So how do we do it?
I’ve mainly been thinking about 4 kinds of wiggly line – three of which were introduced to me by Steve Benford, an academic from Nottingham University in the UK.
Steve calls the first type a ‘canonical’ trajectory, and it describes the happy path through your system or service.
It’s fatter than the rest – you’ll see when we come on to the other types of trajectory that they describe specific individual, experiences. The canonical trajectory describes an envelope in which users will be experiencing your intended design…
It’s as simple as drawing a line to express an experience as it would unfold. The ‘x’ axis represents time as the experience happens. You can use the ‘Y’ axis to represent anything really – though we find engagement, satisfaction, comprehension all useful things to consider and represent. We’ve even used these diagrams to represent the number of choices or decisions we’re offering users throughout an experience, fattening and thinning the line to represent these.
There are lots of ways of using this ‘canonical’ or designed experience. It gives you a way to interrogate the designed thing from the perspective of a user. You can apply a gap or behavioural analysis to the stages of the trajectory – or interrogate needs or SWOT.
Drawing this simple representation of a user flowing through an experience helps to pull you back and ensure a design is as user-centred as it could be. And stories are an intuitive heuristic to apply to the happy path you envisage as you try to move people through a designed experience or environment. Are users falling within the range of your designed trajectory?
Which brings us to the second type of trajectory – the participant or experienced trajectory.
Whereas the designed trajectory describes a hypothetical journey that’s only imaginative, we also use trajectories to try to describe the actual experience that users take.
These are much thinner lines. When you plot these alongside the thicker canonical journey you can explore when experiences might fall outside of your design. Imagine this in game design as you explore what happens when someone wanders off the path you’ve set for them and becomes blocked from progressing – plotting this out gives you the chance to design a feature to pull the user back towards the happy path.
We use participant trajectories to tell the range of supported experiences for a given product or service. It enables us to tell the story of the same product for different audiences. The trajectories of an advanced user of our iPlayer radio app is very different from that of a general user.
We’ve also used participant trajectories a lot in design research. They’re a quick way to note down what happens during a design research session – a simple tool to capture a loose sort of cognitive walkthrough. We’ve also used participant trajectories in design research to identify new potential products and features, learning about and drawing existing behaviours and gaps.
By comparing the participant trajectory, what actually happened, against your designed trajectory, what you hoped would happen, you measure the accuracy of your hypothesis. And when there are gaps between the intended experience and the ones that you’re actually creating, you can focus on the moments of divergence and create features to pull your participant back towards the intended path.
So wiggly lines are awesome – no-one is going to disagree with that. But it’s time to spend a moment thinking about the awesome power of dots.
Lines have continuity. Well-designed experiences do too. They stitch moments together so that experiences flow. But there can be seams between these moments.
As we’ve thought about trajectories we’ve also been thinking about ‘transitions’. Transitions are moments when the continuity of your designed experience could be at risk. They’re moments to pay special attention to – they’re likely to be the points when your user leaps from a ladder or totters on a tower. They’re moments when a users centre of gravity is displaced and the experience is at risk… so they’re moments of risk and reward for a designer or IA. They’re sometimes indicated by dots.
By thinking about specific moments and types of moments in an experience we can design features to enhance or avoid them. We think about beginnings, changes in interface, sessions, switching domains and social encounters…
Each moment when the nature of an experience changes in some way is an opportunity – by understanding and reflecting on the type of opportunity we’re better-able to exploit it.
Now I know that’s a whistle stop tour of transitions but luckily there are two more trajectories to go and I’ll use the next type to fill in the gap in understanding that’s probably inevitable.
Experiences create artefacts – whether these are artefacts of memory, or media – if we consider and design the ‘stuff’ created by an experience we can extend our influence into the future. The penultimate type of trajectory is the Historical trajectories.
A great example of this is the ’historical trajectory’ created at theme parks. The canonical trajectory is the design of the park. The participant trajectory is the route an individual takes and the order they choose to experience the rides. The photos of your time screaming into the wind on the rollercoaster is a historical trajectory. You can use it to remember and re-live the experience.
You can use historical trajectories at the end of the project process to reflect and describe what went well and what didn’t. We do retros at the end of design sprints and projects – we use a range of techniques but sometimes we use trajectories as a simple yet slightly structured way to kick off the discussion. It’s amazing the permission that a squiggly line gives you to explore assumptions – the ambiguity in a quickly sketched line of an experience during a project creates a space to discuss stuff that might otherwise be difficult to name or talk about.
Social media shares can act as another flavour of historical trajectory – you can use these as ‘shared or social trajectories that can pull others into having a version of the experience for themselves. The historical trajectory is the hook that we use to pull them into that experience.
The historical trajectory is similar to the story that the user will tell after the experience – it’s one means by which we can reach into the future and project our design forwards. For example, I knew there wasn’t time to cover details of the transitions we’ve been exploring, so I created a historical trajectory for this talk. It’s a booklet that details what I’ve said and has a few more details about trajectories and transitions.
You’ll have noticed that Steve’s trajectories describe the ‘during’ and ‘after’ of experience design. I’m also interested in the ‘before’ and the spaces and places that we create that will be inherited by people in the future.
Predicted or organisational trajectories are my attempt to describe these. They’re warnings, in a way. They’re also a type of instruction manual.
During any project we make decisions, we bake assumptions into our design, we enable opportunities and commit to a range of possible futures. Most design projects are experiments. We ask ‘how might we…’ and hope that we’re right.
Predicted trajectories are designed to describe these assumptions and describe the path they suggest into the future. They’re not necessary a wiggly line – though representing the different paths visually helps.
I use them to suggest a range of futures that might come about. For each future I describe the steps along the path – the things that would probably happen to make that trajectory more likely. I discuss with stakeholders the likelihood of these transitions. The conversation gives us a shared understanding of the things to look out for in the future but I can also highlight the points at which they need to get back in touch and get the help of one of the IAs in the team. This helps me to decide when and where the IAs in our team would be most useful – we can plan to either avoid a negative trajectory that seems likely or add some IA expertise to a project where it can have most impact.
There are clients that I wish I’d done this with when I worked in an agency. I’d spend months building a CMS, committing to assumptions, setting off on a path, creating a trajectory. And then, some time later I’d click back towards the site I created and notice it’s become a monstrosity. None of the things they promised would happen have quite played out the way you expected – the trajectory has changed and the IA is under stress. Of course, we design resilience into systems, but pointing out when reviews and maintenance might be required sounds like good professional and commercial practice.
Predicted trajectories encourage us to ask ‘what next?’ and to define the role for information architecture to build the best experiences for our audiences now and in the future.
So “Come, let us build ourselves a city and a tower with its top in the heavens, and let us make a name for ourselves.”
Maybe towers aren’t the future. But the story has survived.
That story of the tower happens 100 years after Noah. Noah survived the flood.
Now we face another flood. It’s a flood of information and I think stories are the vessels that might help us survive. Information architects are some of the people who can tell those stories.
In this post I’ve talked about the dangers of ignoring gaps, the importance of making the invisible stuff in projects more visible – assumptions, the connections and relationships, the dependencies and possibilities. I’ve talked about the structures we make and the ways we can understand and explain the experiences they contain.
We face uncertain futures. But information reduces uncertainty. Information is fuel for insights. And architecture creates systems. And systems are greater than the sum of their parts. They’re complex, powerful and necessary to deliver the kind of experiences we want to offer our audiences.
So we don’t need to make a name for ourselves – we’ve got one – information architects – we just need to find more ways to exploit the promise that the name holds.
And we also need to mind the gaps.
Leave a Reply