# Convergence with curiosity — the art and science of information architecture

This post might be controversial. I’ve no idea. When I sat down to write and edit this I knew about as much as you do now about what it was about. Exciting, isn’t it?

Hopefully you’re as curious as me. Curiosity is fast-becoming my most valued professional attribute. Curiosity inhibits frustration. It motivates and energises creativity. Curiosity can undermine the invisibility of assumptions. Curiosity is magic.

This post is about curiosity. It’s also about whether information architecture is a fundamentally convergent practice. If it is, I think curiosity might be the most important attribute that any IA can cultivate… so let’s explore.

#### Problem/Solution pairing = playing both sides of the equation

Information architecture is all about balance and a special sort of convergence.

Architecture requires the definition and arrangement of elements to construct a balanced problem/solution pairing. As an IA, I straddle an equation with requirements on one side and capabilities on the other. There are different words I can use to describe the sides of the equation:

Problems = Solutions

Structures = Infrastructure

Ideas = Implementation

Definitions = Meaning

I play with the two sides of the equation to find definitions, balance and harmony that result in something that is meaningful and useful.

Importantly I can define and arrange on both sides of the equation.

1+3+1 = 2+3

1+1+1+2 = 4+1

5 = 7–2

Different arrangements in either the framing of the requirements or the implementation of the solution have an impact. Different acts of architecture will affect the coherence, connectedness, efficiency and resilience of the resulting system. I’m most effective when I think about all the elements in the equation. I can define problems **and **solutions. I should work on both sides of the equation, flipping back and forth to find the balance.

In this view, system requirements are an output of good architecture — not an input. Of course, we’ll begin with a sense of requirements. But an information architect must follow user-centred methodologies to determine the ultimate requirements for the emergent system — just as much as they create and arrange designed elements to create a solution. This sets ‘architectural design’ apart from other types of engineering design. We must manipulate both the ‘definition and framing of the needs’ and ‘the range of possible solutions’.

“An architect who needs complete and consistent requirements to begin work, though perhaps a brilliant builder, is not an architect.”

*The art of system architecting, p.20*

**Creatively constrained = IA as a converging discipline**

Sometimes IA can get a bad reputation as a limiting and constraining part of the design process. We’re often the people focused on constraints. Meaning-making is hard and as custodians for coherence and consistency, we’ve been known to poop on parties. But the definition of IA that I’ve just tried to explain is as creative as it is empowering. It reveals where the creativity lies in IA. It empowers us to see constraints as variables in a system and equation that we can control both sides of. I can explore many alternative arrangements on either side of the equation. My work is not done until the two sides balance. But I am constrained only by the physics of the equation — and they are within my own power to command and control.

“An “ill-structured” problem is a problem where the statement of the problem depends on the statement of the solution. In other words, knowing what you can do changes your mind about what you want to do. A solution that appears correct based on an initial understanding of the problem may be revealed as wholly inadequate with more experience. Architecting embraces ill-structured problems.”The art of system architecting, Preface

I arrange and pull things together. I focus on the middle of that equation to make sure the rules I establish are as solid and reliable as an equals symbol. In systems architecture some constraints may seem immovable. But every elements of a design is either a conscious or unconscious choice. Intentional architecture extends our responsibility for the choices embedded in both sides of the equation.

#### Curiosity balances convergence

I have a nagging sense that information architecture is an especially difficult thing to practice with generosity and curiosity. We constrain complexity by fixing definitions and reducing the number of moving parts. But we must be able to revisit these definitions, across both sides of our ‘problem/solution’ pairing to ensure we’re at our most effective.

We should be curious and generous as we converge.

When we hold on too tightly to meaning and definitions, I think there’s a chance we limit our ability to unlock solutions. This is a version of ‘strong opinions, loosely held’. We should never be so certain of our solution that we fail to recognise a better one, even when it’s in disguise. Curiosity energises us to consider what might otherwise frustrate us. It also keeps us generous.

‘Architecting’ is not a nice word. If it’s onomatopoeic it suggests a rugged, jagged back-and-forth that’s not always helpful in a discipline driven by interrogating difference and asking the difficult question.

Maybe I’ve mellowed. I now like the sound of a ping-pong ball bouncing back and forth between two sides of a problem/solution pairing — maybe with a little face drawn on it to keep things light. I think of ‘Penelope the ping ping ball’ as bouncing between stakeholders. She’s having conversations. Each one leaves an imprint. As she bounces around she tests hypotheses as she collects and tries out new definitions of requirements and ideas for solutions. Finally this back and forth slows as she comes to settle on the design of a system that makes sense.

On other days the image that fixates me is an hourglass. I think of marking the time I spend on a project using an hourglass. I think about one side recording the time and attention I spend on the solution and the other, my effort on defining the problem and its parts. I think about how I can maintain roughly equal amounts of sand in each half. I think about the back and forth of my attention. I think about the gentle flow of the sand. I think about balance, order, equilibrium and the regular, repetitive flow. The rat-a-tat-tat in the word ‘architecting’ feels more positive. It sees me knocking on a door and starting a conversation. The back and forth feels more generous.

So I’m working on some practices that reflect this thinking and might make me a better architect

**Problems/Solutions**

I interrogate, communicate and document both sides of equation. I keep in mind that I have responsibility for balancing the equation. But it’s not cheating to manipulate both sides — it’s required.

**Questions/Statement**

I try to ask two clarifying questions and one ‘new information’ question for every statement I make. One statement or conclusion to three questions feels about right for an architect. But clarifying questions help me to reduce the stress I put others under and help me to understand.

**Conclusions/Curiosity**

I treat conclusions with caution and curiosity. I need to be conscious and intentional in the moments when I choose to fix meanings and conclusions. At some points I do need to fix a definition or element in the architecture. But remaining curious and asking myself ‘what if?’ will sometimes give me the answer to an architecture and equation that would otherwise remain unbalanced.

#### Assumptions = riddles

When we pour all our attention into fixing requirements and when we remain immovable in our definitions, we compromise our ability to do our jobs. We can unintentionally create impossible puzzles, equations that are fundamentally unbalanced.

Most puzzles and riddles trip us up when we unconsciously adopt a constraint or framing that stands in our way and obscures an otherwise obvious solution. Architecting is about remaining curious, asking “what if”, and remembering we can control both sides of the equation.