The design process and the scaffolding within

In a post last week I shared a definition for design. I said: “Design is the translation of intent into experiments designed to generate value.” That post is about how information architecture is the stable set of rules which govern the relationships within a design to bring internal coherence. Information architecture means designs are easier to make sense of when people encounter them. Because once you’ve encountered and understood the “rules”, you benefit from predictability — it’s more efficient to make sense of the information you encounter and use.

I wanted to dig into that implied definition of information architecture — particularly the role information architecture plays in the design process. I think when you understand information architecture, you can navigate the design process more intentionally and make better things.

Information architecture is the stable set of rules which govern the relationships within a design to bring internal coherence. — it means designs are easier to make sense of when people encounter them.

Translation and transformation

I said that design is a process of translation. I think that’s right. But there’s also something attractive about the word ‘transformation’. Design definitely isn’t ‘transliteration’ — it’s not just “swapping the alphabet” as we work on ideas and turn them into designs. It’s more like inventing a new alphabet or grammar with each new design. We make something below the surface, which ties together ideas as we refine and combine them to make the things that emerge fit for purpose. We might not be consciously following rules — but “rules” and translations are created as we work through the design process.

Design starts off with some creative (or commercial) impulse. It might be a problem to solve or an opportunity to address or exploit. We have ideas aimed at part or all of the problem. Intent is important because it defines our areas of scope and attention. We combine our creativity with conscious attention on the problem. We can have loads of ideas, but unless they’re aimed at addressing some intentional outcome, it isn’t design.

So early design stages look like this loop as we consider the “problem definition” and have “ideas” which we think might address the problem. We ask “will this idea have the desired outcome?” We might check whether there are any undesirable consequences. We’ll likely be careful with constraints and dependencies at this stage. But at some point we will begin to consider whether we can actually test or deliver this idea. This shift to considering feasibility introduces the next component of my definition — experiments.

At some point in design, you have to make something. So the later stages of design find feasible ways of translating ideas into “real” experiments where people can experience the thing you think addresses their problem or brings value through meeting an unmet need or opportunity. So, you have the later stages of design:

We translate our ideas into experiments and then observe the experiments to see if they result in the types of experiences we intended.

Last week I visualised the design process as an equation. I’m going to return to that version in three paragraphs. But as I sketched these triangular versions I was struck by the architectural vibe — all scaffolding-like. When you connect the stages together, they start to look like the base of a pyramid. So I added a keystone and some labels and got this — the design process pyramid.

The shape suggests that there is balance. The arrows suggest that there is interplay and relationships between the elements which achieves and sustains this balance. The labels suggest the types of activity within “zones”. The interplay or internal coherence is the information architecture. Information architecture is the stable set of rules which govern these relationships within a design to bring internal coherence — it means designs are easier to make sense of when people encounter them. It also describes the rules that are experienced and established through the design process.

You can think of the information architecture as scaffolding within the structure of design. Design isn’t ‘transliteration,’ it’s translation, and within each design there will be an information architecture which defines how we move from each stage and how we relate problem/ideas/intent/experiments and experiences to ensure they’re “equal” to each other — that they’re accurate translations. Design is as much about the transfer of information as it is about the creation of information — we have ideas and then we need to share them. We cannot design efficiently without optimising how we share information.

Information architecture is usually invisible. But you still feel the influence of it. And if you create unintentional architecture or don’t pay attention — you can start to perceive that the overall design becomes unbalanced and makes less sense. It’s as if we change the rules mid-game — we introduce uncertainty, unpredictability and inconsistency. What was a nicely structured pyramid is now a less predictable, irregular shape (a bit like a kiwi bird, apparently).

Back to the equation

Part of IA is about consistency — and I already have two representations of the design process. The pyramid is more about “dependency” and foundations. The equation is closer to a temporal or sequential representation — while we know that design doesn’t always follow the same linear path, broadly it will move left to right through the elements of the equation as a project progresses.

Flattening out the pyramid gets us back to the equation. The equation stresses that design manages translations between problem definition, idea generation, hypothesis articulation (intent), experimentation and experiences (and evaluation) and that these things need to “equate” in some way. This is the most abstract way you can explain the design process — it’s about creating and manipulating things in each of these stages to deliver “experiences” which resolve the “problem.”

“Abstraction” is central to my understanding of information architecture and design. The design process is full of information. And it exists in different forms — we can call these layers of abstraction or “levels” of complexity. Or we could talk about “fidelity” (and you should read this post from John V Willshire on similar ideas using the idea of fidelity). The point is, we create and convey information during the design process on a spectrum from purely conceptual to completely concrete.

We can also change the “format” of the information as we translate ideas into products and services. I think of these as two different types of translation — two different types of activity we undertake during design. One set of activities is like the process you might go through to turn an idea for a play into a script, the other is more like turning the script into a performance.

So you can move “between” levels of abstraction (or fidelity) and you can move across different forms of representation. Moving from “script” to performance is likely more efficient and predictable than just moving from a “description” of the idea and creating a performance through improvisation… but that might feel more free and “creative” and reveal opportunities that you wouldn’t have discovered if you just followed a script. Moving from idea straight to performance is even less predictable — but it could conceivably also move a project forward and help unlock some creativity. In this case, it’s likely you might then capture some of that improvisation as a script or at least reflect and describe it in some way. This paragraph is an improvised performance of me describing the design process. I went back and edited it multiple times. It shows how we can move up and down and backwards and forwards during design.

Design provides us with a set of tools, processes and ways of thinking to make creative leaps between problems and ideas and between intent and experiments to deliver valuable experiences. Information architecture provides the structure so that others can follow your intent — your line of thinking. It also means you can go back and check you’re doing what you intended or what you promised a team or client. This is why IA is valuable during design, as people collaborate and create shared intent and co-ordinated activities. (It’s also valuable in the final design as end-users encounter a design and can make use of the features you’ve created to fulfil a need or desire — but I’ll write about that in the future.)

Depicting the how design and information architecture operate at different levels of abstraction can help us understand the shape of the design process. Once we have a map we can locate ourselves within the process and carry out a sort of audit to consider which bits we haven’t visited. Unconsidered sections are usually the source of unintentional aspects of a design or the points of weaknesses where a design begins to fail. So, let’s add in some scaffolding to the equation to represent different levels of abstraction and see if it produces a useful map.

This map shows how each element of the equation can exist at different levels of fidelity (or if you prefer, how clear and concrete each stage feels can vary). Does the problem feel ill-defined, entirely conceptual, clearly articulated in words and pictures or well defined and predictive of future scenarios. If it has reached this point, you’ve probably worked all the way up the top of the scaffolding.

You can ask the same questions of each element of the equation. Is the idea just at the rough concept stage, do you have wireframes, do you have a working prototype, do you have a design that can be built? Is your intent clear, can you articulate the outcome you want to achieve, can you articulate it in measurable outcomes? Are your experiments viable, feasible and reliable? Are people able to experience your designs — how do they react? You can interrogate these types of questions, working across the scaffolding structure to understand if there might be gaps. You might not need to have visited every junction. But there should probably be one (or multiple) paths from the lowest level of your problem definition to the highest levels of experiment.

I think every element in the design process equation probably operates at different levels of abstraction. We can express this in the scaffolding structure above. And sharing this type of structure or information architecture is one way of navigating the design process more effectively.

UPDATE: I’ve developed some of these ideas in the following post: https://danramsden.medium.com/consistently-describing-design-cefd9aa8964e