Why is “information architecture” at the centre of the design process?

Let’s get two things straight — namely what I think “information architecture” and “design” are. I think both names suffer from a problem. They describe both an output and a process.

1. The thing you create: We can create a design and we can create an information architecture within and around a design.
2. The thing you do: We don’t only use these words as nouns to name the thing we’ve created. We also use them as verbs — we ‘design’ a solution to a problem, we ‘architect’ a situation to make it more coherent.

The decisions that you make as you design or architect change the product or service that you’re working on. How you make the decisions is the process view. The results of all your decisions, the final “design” and “information architecture,” is the other meaning — the output.

These definitions form the scaffolding around this whole article.

Design is the transformation of existing conditions into preferred ones

HERBERT SIMON

I like this quote from Herbert Simon. I like the word ‘transformation’. It does a nice job of suggesting how design can create and combine elements to change things and have an impact. It’s maybe a bit optimistic. It suggests that design always moves towards ‘preferred conditions.’. But design sometimes results in worse conditions and unintended consequences. And while that might be an example of unsuccessful design, it happens enough for me to want to hint at or avoid in my definition. So perhaps we can improve on Simon’s definition without seeming arrogant.

Design is the translation of intent into experiments

DAN RAMSDEN

I’m going to try this definition out for a while. It owes something to the Simon definition and the way that Jared Spool talks about design as ‘the rendering of intent’. It adds in “experiments”. At least for me — working across complex systems and products used by millions of people — I’m never 100% certain that my “design” will deliver 100% of the intended impact. And framing design output as an experiment ensures we don’t forget to check whether they work our not.

But the big idea in this definition is: ‘translation’. It’s the reason why I think information architecture is so central to the design process. Design is translation between ideas and experiments, intent and experiences.

How the process of design looks to me

(problem) = ideas = intent = experiments = experiences

I have an idea. I consider whether the idea addresses the problem as I currently understand it. This little thought experiment is followed up with loops of multiple experiments. These experiments tend towards higher levels of fidelity. I try to “render my intent” through iterations in pictures and words, then wireframes, then prototypes and then products. Each one of these translations and experiments results in experiences — whether I’m the one having them in my head. Or it’s the team I’m working with as I try to share my idea accurately. Or it’s the final, intended audience of users. These experiences are the X in UX. We have experiences as we design (process) and users have them when they encounter our design (output).

Designers work through multiple iterations, checking in that they’ve translated ideas efficiently (maybe even adding value) as they create designs. Some solutions work better than others. Ideas that address problems are sometimes called solutions. Some introduce unintended consequences or have different levels of performance. But Design is a process to manage the translations. We think “we want people to have this sort of experience” and then try to bring about the conditions for that experience to exist. And we can check in and judge our effectiveness by referring to the elements of the equation. The internal consistency which makes this possible, and makes the equation balance, is the information architecture.

Making meaning

My depiction of the design process is full of equals symbols. They might not be exactly the right thing to use. I guess you might argue that I should use a “>” symbol. It’s true, as we progress through the design process we tend to accrue more complexity and generate more value. But I’ve used the equals symbol because in trying to move through the stages, I want to stay true to my intent. I might pick up serendipitous discoveries that add value to my idea as I render it. And I might shave off things that aren’t adding value or are compromising my design. But I want consistency between stages and coherence within the equation as a whole. I want things to make sense. And I want things to “mean” the same thing throughout the process (and the experiences my output prompts).

We can argue over the symbol to use — but the truth is, there is a relationship between the elements in the equation. For me, they’re described with an equals sign because Design is about balancing equations. It’s about finding solutions that are equal to problems and opportunities. You might choose a different symbol — but it needs to make sense and have a consistent meaning.

The fundamental principle is balance of opposing forces. Design thinking balances exploitation and exploration, reliability and validity, analysis and intuition, and declarative logic and modal logic.

ROGER MARTIN

The information architecture within a design (both process and output) makes the balancing within the equation possible. It also ensures the equation is “solvable” by other people. It does this by introducing logical coherence. It ensures words, images, shapes and colours are used consistently. And it ensures that as we move from idea to execution, we stay true to the original intent — and can clearly articulate it — so that we can meaningfully measure the effectiveness of our design.

Without this internal coherence and confidence that our output is an accurate, reliable test of our hypothesis, we’re not doing design. The power of design which has a consistent information architecture is that if we find that our idea (which we translate to intent, experiments and experiences) is not equal to the problem, we can interrogate every part of the equation. We may have made a mistake in execution. Maybe our idea wasn’t quite right. Or even more powerfully, maybe we didn’t really understand the problem fully.

Design lets us manipulate every element of this equation to bring balance — but it can only do that if the equation (the project) has a coherent information architecture. So, what does that mean in practice:

• Use canvases or other tools to build shared language and definitions around the aspects of your project — people, technologies, ideas
• Make sure you have agreed definitions of the problem — and any other key concept — so that when you use words or pictures, people translate them in the same way
• If you’re communicating in abstract terms through flow diagrams or using boxes and arrows don’t change things for the sake of it — use shapes, colours and typefaces consistently
• Check in on each iteration of a design so that you’re consciously assessing what you’ve added, lost or changed
• Always head into an experiment with a clearly stated hypothesis and shared agreement that the experiment is a fair and accurate test. Sometimes explaining your idea to someone else is an experiment.
• Don’t be afraid to revisit your problem definition as you build more knowledge through your experiments — sometimes the issue isn’t the solution being wrong, it’s your understanding of the problem.