Information architecture for PdMs and org designers
Information architecture for PdMs and org designers
The Overlap #12
Welcome to The Overlap, a biweekly newsletter that explores the relationship between product & organization design.
This newsletter is published every other Wednesday, which means that this should come out next Wednesday. However, next Tuesday is Election Day in the US, so I wanted to publish this before the election. I’m nervous about what will happen next week, and I’m sure many of you would rather be doomscrolling instead of reading a newsletter about product. (I know I’ll be.)
Anyway.
In this essay, we’ll talk about information architecture or IA for short.
I recently took a 1-hour course on information architecture by Abby Covert, an experienced information architect. I wanted to brush up on some foundational ideas in information architecture before I start an IA-focused project for a client.
This essay will summarize what I took away from the course. I’ll also add some additional commentary that’s specific to a PM or org designer. I’m no IA expert, but I do think some of its basic ideas are useful for product managers, UX designers, and organization designers.
Why is IA useful?
Think about words that everyone in tech says.
“Product Vision”
“Strategy”
“Process”
“Experiment”
“MVP”
We hear these words all the time. Yet they mean different things to different companies. They can even mean different things to different people within a company if that company is huge. “Experiment” at a startup most likely means something entirely different than an “experiment” at a large company.
Now, think about words or acronymous that are specific to any previous companies you’ve worked at.
“Squads”
“IDM”
“FSS”
Teams and organizations need a consistent language. Without a consistent language, teams aren’t aligned, assumptions become costly, and the end user experience is incoherent. Information architecture helps teams (and teams of teams) establish a consistent language.
What is information architecture?
Here’s how the Information Architecture Institute defines it:
Information architecture is the practice of deciding how to arrange the parts of something to be understandable.
It’s all about arranging the parts of a whole to make sense of it.
We see information architecture every day:
Page numbers & chapters of a book
Pages & Labels of a website
Menus for navigating an app
Signs directing travelers in an airport
Train names and subway stops
The idea of information architecture has been around since the mid-1960s. Many folks consider Richard Saul Wurman, the creator of the TED conference, to be the “father” of IA. His thing was that information architecture was all about defining the foundations of a system before making it “look pretty.”
Others suggest that the term originally came from Xerox Labs. From A Brief History of Information Architecture:
Xerox was among the first corporations to address this notion of information structure and use the “elegant and inspiring phraseology, the architecture of information” to define its new corporate mission.
Abby breaks information architecture down into three ideas: ontology, taxonomy, and choreography. Let’s dive into each.
What is ontology?
Ontology is the declaration of meaning in a specific context.
Example: take the word tech.
At a software company, tech can mean the technologies developers use to build and maintain the company’s product.
“A food delivery app requires a lot of tech.”
“The tech supporting this web application is super expensive.”
Among your friends, tech can mean the industry you work in.
“I work in tech.”
“I should’ve worked in tech instead of the medical field.”
If you’ve ever performed on a stage, tech means the lighting, audio, and visuals that are part of a performance.
“Tech rehearsal is tomorrow.”
“Our tech crew takes care of lighting.”
Tech takes a specific meaning depending on the context it’s used.
What about the ontology of a word that’s used within an industry? Let’s look at how discovery can mean different things within the tech industry.
To a design thinker, discovery can mean the phase dedicated to understanding. It involves researching the problem space, framing the problems to be solved, and gathering enough evidence and initial direction on what to do next.
“From talking with customers in discovery, we believe these are the problems we should solve first.”
“Discovery will help us prioritize what to design and build.”
Say you work at an agency or studio. To your client, discovery can also mean the first month of collaboration. It still involves researching the problem space, framing the problems to be solved, and gathering ideas on what to do next. But a client understands it more as the first phase that’s focused on understanding.
“In discovery, we dive deep to understand your goals so that we can design a solution that maximally meets them.”
“We’ll know more about that problem in our design phase, as we’re still in discovery.”
Discovery can also mean how a user finds content for the first time. This applies to product managers, designers, and developers.
“Spotify’s discovery is really good. I find the best music there.”
“I wish Substack had a better discovery. I have a hard time finding new newsletters through their site.”
What is taxonomy?
Taxonomy is the structure and relationships between the parts of the whole.
While ontology is about the meaning of our concepts, taxonomy is about the relationships between our concepts.
Let’s look at an example: Twitter. Take the ideas of tweets, retweets, and timelines.
Ontology would tell us to define each idea, clearly:
Tweets are what users post. They can’t contain more than 280 characters.
Retweets are a repost of another person’s Tweets.
Timelines contain a stream of Tweets and Retweets from the users they follow.
Taxonomy would tell us how each idea is related:
Users can Retweet Tweets.
A Retweet cannot exist without a Tweet already existing.
A Retweet is not the same thing as a Tweet.
Timelines are comprised of Tweets and Retweets.
Tweets and Retweets belong to Timelines.
Ontology forces us to think about what the concepts are, while taxonomy forces us to think about how the concepts relate to each other. Both ways of thinking can produce the same output—you can’t define Timeline without Tweets and Retweets. But the point is that they’re two different tools.
Other examples of taxonomy:
Website pages
Sections of a mobile app
The way a building is broken into rooms
The Dewey decimal system at the library
The alphabetical order of a phone directory
What is choreography?
In dance, choreography is how a performance is arranged and presented to an audience.
In information systems, choreography is how content is presented to its audience.
To a product manager, examples of choreography are:
You can’t post photos on Instagram on the browser, only in the app.
If you have a private Twitter account, only your followers can see your tweets.
If you paid for a Substack writer’s subscription, you can see both paid and unpaid content.
To an org designer, choreography can mean
The steps in a team’s meeting process
The steps in a decision-making process
How an internal experiment is defined and decided on
How to stay up to date on the transformation effort (e.g., Slack channels, open forums)
Choreography creates conditions on the ontology and taxonomy. It determines when content is shown to users and when content isn’t shown.
Clarify ideas early and often
When I first started as an org designer, I immediately grasped how crucial it is to define the ideas I introduce to clients early and reinforce these definitions often.
I’ve brought in ideas like:
From my clients’ perspectives, these words were either a) brand-new or b) pre-existing notions. When I didn’t clarify these terms, they adopted their own beliefs on what they meant.
Safe to try meant “force a yes on this decision” rather than “a way for teams to de-risk complex decisions.”
Action meetings meant “meetings the consultant facilitated” rather than “tightly facilitated, participant-driven meetings.”
Experiments meant “big change” rather than “small, bite-sized changes.”
People unconsciously make meaning out of unfamiliar ideas so that it fits their way of seeing the world. Venkatesh Rao calls this a desire for “legibility”:
The big mistake in this pattern of failure is projecting your subjective lack of comprehension onto the object you are looking at, as “irrationality.” We make this mistake because we are tempted by a desire for legibility.
So if you ever introduce new ideas to an organization, be clear about what these ideas mean, and reiterate their meaning throughout your time with that org. On the flip side, observe when your own desire for legibility isn’t helping your team/org, and try to be open to defining with your team/org, rather than for.
IA is a shared practice
Information architecture is not a one-person effort. We can’t solve the problem of inconsistent language by only relying on a single consultant or information architect. IA must be practiced among members across different disciplines.
To practice IA with your colleagues, practice facilitation. You can’t just create a spreadsheet, write down all the terms and definitions of each term, and say “alright, this is how we’ll define the words we use.” People will want to debate your definitions. That’s part of the fun!
So to put it into practice:
Notice the words your organization uses.
Write them down in a spreadsheet or doc.
Write the definitions of each word.
Capture other words each word is related to, along with the nature of their relationship.
Share this with your team and ask, “What did I get wrong?”
Your team will build on it from here. All it takes is you starting the conversation.
What I’m Reading
1/ Object-Oriented UX
I first found out about Object-Oriented UX through my friend Conor O’Holleran:
OOUX’s approach is similar to information architecture: define all the objects in your system, then map all the ways your objects relate to each other. If there are two different names for similar ideas, that shows how powerful the idea is!
2/ Lateral Thinking With Withered Technology
Awesome read on how the Game Boy focused on producing great games even over utilizing the latest technology. Great example of how real strategy requires tradeoffs.
3/ Little Futures: Permeable Organizations
I love this edition of Little Futures because it connects many broad ideas. It talks about the idea of permeable organizations: smaller firms with orbital stakeholders and a more adaptive strategy. Permeable organizations have ever changing boundaries that enable them to become an ever better organization.
My company launched a SaaS product for devs 🚀
We launched a product called Spirit Fish. It helps developers quickly make their websites discoverable by search engines. After initially building it for our own client websites, we thought others might find use from it too.
See you after election week,
–tim
Thumbnail photo from this are.na block.