How Information Architecture Creates Shared Understanding

In this edition of Tecknowledgy, Jens Wallner, Information Architect at Mercedes-Benz.io, shares why alignment across Product, Design, Engineering and Business starts with something deceptively simple: being clear about what the user is actually trying to achieve.

Jens Wallner

Information Architect|MB.ioneer since May 2016

Fun fact:He has a passion for traditional Black Forest cuckoo clocks and enjoys repairing them in his spare time.

As digital experiences become more complex, keeping that understanding intact across the whole journey becomes harder. For Jens, this is where Information Architecture plays an important role: connecting individual decisions to user intent and giving different disciplines a shared context for the work. As AI-assisted workflows make execution faster, that context matters even more. The question is no longer simply whether something can be built, but whether it belongs in the experience and remains coherent with everything around it.

Looking beyond the piece you’re building

One of the tensions I find most interesting in multidisciplinary work is the difference between what a team optimises for and what a user actually experiences. Teams inevitably have areas of responsibility, and within those boundaries people make decisions that are entirely reasonable. Users, however, don’t experience those boundaries. They experience the website as a whole.

For me, this is why shared understanding starts with making the user’s intent as specific as possible. Before anyone starts building, I want us to understand what the person is trying to achieve, what constraints shape that goal, where the intent sits across our website and what success should look like. Increasingly, we also have to consider how AI should work with that intent. We don’t need to approach the problem in the same way, but we do need to be solving the same problem.

A decision can be completely correct in isolation and still contribute to an experience that doesn’t work when you zoom out. This is where I think Information Architecture needs to hold the wider journey view. Mapping user intent to the journey phase it belongs to helps connect what an individual team is building with what the user is ultimately trying to achieve, including what came before, what they need at that moment and where the journey should take them next.

Once that context is visible, we’re no longer simply deciding what needs to be built; we’re understanding why it belongs there and how it needs to relate to everything around it. Product, Design, Engineering and Business can bring different perspectives to the work while remaining anchored in the same user intent and the same larger journey.

Alignment starts before the work does

I see early alignment less as getting everyone to agree on every decision and more as giving everyone a common reference for the decisions they will eventually need to make. If we’ve clearly defined the user’s goal, the relevant constraints, where that intent belongs in the wider journey and what success looks like, disagreements become easier to navigate because there’s something more useful than individual preference to refer back to.

Without that shared understanding, the symptoms are familiar: features can be individually complete without connecting naturally, ambiguity enters during handovers, and teams end up in rework cycles that look like communication failures. Often, I think the problem starts earlier: nobody made the intent precise enough before the building began. Nobody wrote down what “good” actually meant.

That’s also why I’m cautious about treating additional coordination as the solution as products become more complex. Another workshop or alignment meeting may help, but if the information people need to make a good decision remains ambiguous, more opportunities to discuss that ambiguity won’t necessarily resolve it.

I’d rather improve the quality of the constraints people work from. A well-defined constraint can continue doing alignment work after a meeting has finished because the context no longer depends on someone being there to explain it. The aim isn’t to replace collaboration with rules, but to let teams spend more time on the decision itself and less time reconstructing why they’re making it.

Designing constraints that carry the context

This way of thinking changes what documentation means to me. A design system or platform documentation shouldn’t only be a static reference for checking a component or pattern. It can become part of the infrastructure through which teams maintain a shared understanding of the experience.

The more clearly we describe which patterns exist, which templates make sense at different phases of the journey and how those choices relate to user intent, the less knowledge depends on context living exclusively in people’s heads. Someone joining later shouldn’t need to have attended every previous conversation to understand why something has been designed in a particular way.

That becomes even more important when the consumer of that context isn’t necessarily a person. In our current practice, we’re treating the design system and platform documentation as machine-readable infrastructure, a live source of truth that both teams and tools can reference. For Information Architecture, the challenge becomes not only structuring the experience itself, but making enough of the reasoning behind it explicit that it can travel with the work.

What changes when execution gets easier?

AI-assisted workflows and Vibe Coding are making it possible to move from an idea to something tangible much faster. A flow, wireframe or component can increasingly be generated from a prompt. What interests me most isn’t simply that execution becomes faster, but what happens to the decisions around it. If generating an interface becomes easier, the difficult question increasingly isn’t whether we can build something. It’s whether what we’ve built makes sense alongside everything else. Does it use the right pattern? Does it belong at this point in the journey? Does it connect properly to what comes before and after it? Most importantly, does it actually serve the user intent we started with?

These questions require context and judgement, and they’re closely related to what Information Architecture has always been concerned with. In our current practice, we’re beginning to encode that UX judgement into the systems AI agents work from: what patterns exist, which templates serve which journey phase and, increasingly, both the classical UI path and the agentic path for an individual user intent.

For me, this is why the role of Information Architecture isn’t shrinking as AI becomes more capable. It’s moving upstream. If teams and tools can produce more parts of an experience in parallel, then the context and constraints guiding those outputs become even more important.

The goal isn’t to make Product, Design, Engineering and Business think alike. It’s to give those different perspectives a common foundation: a clear understanding of the user, the intent behind what we’re creating, the journey it belongs to and the outcome we’re collectively trying to achieve.

Ultimately, coherence doesn’t come from every individual piece being correct. It comes from understanding how those pieces need to work together.