Information Architecture checks for Design Systems

Content patterns can take us a long way.

Avin Vadas
Bootcamp
Published in
5 min readOct 29, 2022

--

Photo by Philip Myrtorp on Unsplash

Information Architecture (IA) often has an absent presence during Design System’s discussions.
It’s both abstract and supposedly obvious at the same time.
Questions about it often results in either avoiding a long discussion (having no time) or an awkward silence (having no idea).
Among many Design Systems created in recent years, I personally came across a few of them that include an Information Architecture section. A few others, actually created Content Design Systems.

The main case against including an IA and content section in a Design System is often the creation of an additional dependency, while, on the other hand, keeping our branded Lego bricks as general as possible is the quickest way to get things up and running.
The problem is, that content is a pattern-based system in it’s own right, and by overlooking it’s core concepts and structures, we still tackle them by proxy, idly creating alternative versions while bridging the gaps back to the brand values and strategy.

Contents are specific, and when building a Design System to serve dozens of products, half of which were recently acquired from external brands, sticking to the safest generality and planning ahead for downstream branching might be a good enough path to go.
But when the scope is more controlled and the adopting products more organically related, mapping terminology and data structures with content teams can reveal core conceptual models, that are so obvious to those who created them that they wouldn’t emerge as patterns until we explicitly ask.

Alignment with content patterns will not only prevent potential conflicts of names and concepts, but can also set the ground for genuine design solutions and an actual competitive advantage down the road. The thing is this:

While Design Systems work is much about making our specifications general, a deep insight of our content environment can make our generalizations more specific.

Both IA and Product Design shape the user’s mental model of our system.

Our design is there to communicate content, order, and related affordance.
Our patterns- and the context of their use- map a wider image in our users’ minds of how things are being done in our platform and sets their expectations from the brand rather than just the product.

Content are the patterns beneath our patterns.

Each pattern structure sets a convention for either order or functionality.
A few examples can be:

  • Navigation components tell the logic by which we categorize our content, as well as the ways to find them.
  • Heading types (H1, H2…H6) and their combinations show the rules by which we balance hierarchical depth and content importance.
  • Content structures, from full page layout to a single article or a system notification, every piece of content sets a Content Model that users expect to recognize in similar cases.
  • It’s also about what not to do: Sometimes, a pattern designed to support a specific type of content, just wouldn’t be compatible because it wasn’t aligned with specific content convention or parent model.

Content recognizability can make or brake consistency across products.

When a piece of content retains its familiar structure, it helps users bridge significant visual differences, between different products, platforms (web, mobile, native desktop, etc), or even contexts of use.

Design systems work gets more and more semantic.

As design systems were always about naming and taxonomy, the growing specific use of Design Tokens, along with the recent AI-powered tooling makes our governance mechanisms as well as direct controls more and more about words and names rather than about visual values.
Which leads to the next item:

Collaboration with strategy and content should be seamless.

By creating a Design System, we also create a parallel semantic map of our product's environment for different use.
Just as we use a city map to find the ‘M’ label for the nearest metro station and the labels on the metro map to drop off and go up at the right spot in the city, the ability to shift between our content and our design maps within the same conversation is getting more and more essential.

What to check?

The painful part is that unless we are lucky enough to have some documentation about the labeling, a content model map , and people who own them in the organization to collaborate with, the deeper patterns are for us and the content team to excavate.

My early goal is usually to prevent conflicts with existing concepts and terminology as much as possible, so the design and content systems can complete each other. By setting this, we also open the road for genuine solutions and opportunities to emerge between design and content As the system matures.

Our main objectives can be:

  1. Naming and labeling system: Check that we don’t call similar entities by different names, or use a name already in use to describe something different in the design system. Running into such conflicts half a year into the project is not the best way to start your morning.
  2. Metaphors of any kind: Here also, I fish for dualities first.
    Metaphors are contextual. If the product includes content areas that are conceptually referred to as “galleries”, we might consider calling that image view pattern we just pushed to our storybook some other name.
    On a deeper level, metaphors often suggest wider patterns of thinking about how the system parts are organized and relate to one another.
    Going a little deeper down such a rabbit hole, when you find one, can often pay off.
  3. Repeating patterns of relationships and connections:
    What type of relationships connect the different objects in the system? (think of parenting hierarchies, containments, versioning , parallel modes of an entity, etc).
  4. Content models and the conventions they reveal: How are content units built from the inside? is there any repeating internal order? User profiles, articles, notifications, code snippets, and comments in a thread. What repeating patterns are visible across different content structures? Where do they differ?

Make it visible.

Information Architecture is an often-transparent essence.
We won’t realize it’s there, but we will feel it's broken as soon as things stop coming together.
Having an IA reference in our Design Systems can make it an approachable and powerful sense-making element, that feeds the “why” reasoning straight into our daily design decisions.

Sources to get convenient with Information Architecture:

Information Architecture by Louis Rosenfeld, Peter Morville, Jorge Arango

Mapping Experiences by Jim Kalbach

Understanding Context by Andrew Hinton

Mental Models by Indi Young

How to make sense in any mess by Abbey Covert

Sources to get convenient with Content Strategy:

Guide to Content Strategy by Peter Zogas

Microcopy: The Complete Guide by Kinneret Yifrah

--

--

Bootcamp
Bootcamp

Published in Bootcamp

From idea to product, one lesson at a time. Bootcamp is a collection of resources and opinion pieces about UX, UI, and Product. To submit your story: https://tinyurl.com/bootspub1

No responses yet