How to Make Sense of Any Mess: Information Architecture for Everybody
Despite a lot of experts praising this book, I have a hard time recommending it to anyone wanting to learn information architecture for the first time. The author attempts to cover too much by expanding information architecture to cover any kind of information problem. It’s a great idea, but when an idea is abstracted, it makes it harder to grasp what the author is talking about. Good refresher for experienced designers, but I wouldn’t start here if you’re just starting with IA.
My notes and highlights:
Messes are made of information and people.
A mess is any situation where something is confusing or full of difficulty.
It's hard to be the one to say that something is a mess.
The first step to taming any mess is to shine a light on it so you can outline its edges and depths.
Information architecture is the way that we arrange the parts of something to make it understandable.
Everything around you was architected by another person. Whether or not they were aware of what they were doing. Whether or not they did a good job. Whether or not they delegated the task to a computer.
Some things are simple. Some things are complicated. Every single thing in the universe is complex.
A common complexity is lacking a clear direction or agreeing on how to approach something you are working on with others.
Differing interpretations can make a mess complex to work through.
Knowledge is complex.
Part of that includes agreeing on what things mean.
If other people have a different interpretation of what we're making, the mess can seem even bigger and more hairy. When this happens, we have to proceed with questions and set aside what we think we know.
Every thing has information.
The most important thing I can teach you about information is that it isn't a thing. It's subjective, not objective. It's whatever a user interprets from the arrangement or sequence of things they encounter.
While we can arrange things with the intent to communicate certain information, we can't actually make information. Our users do that for us.
Information is not data or content.
Data is facts, observations, and questions about something. Content can be cookies, words, documents, images, videos, or whatever you're arranging or sequencing.
The difference between information, data, and content is tricky, but the important point is that the absence of content or data can be just as informing as the presence.
The jars, the jam, the price tags, and the shelf are the content. The detailed observations each person makes about these things are data. What each person encountering that shelf believes to be true about the empty spot is the information.
Information is architected to serve different needs.
When it comes to our use and interpretation of things, people are complex creatures.
We're full of contradictions. We're known to exhibit strange behaviors.
Most importantly perhaps, we realize that for the first time ever, we have easy access to other people's experiences to help us decide if something is worth experiencing at all.
Stakeholders are complex.
A stakeholder is someone who has a viable and legitimate interest in the work you're doing. Our stakeholders can be partners in business, life, or both.
Managers, clients, coworkers, spouses, family members, and peers are common stakeholders.
Knowing is not enough. Knowing too much can encourage us to procrastinate. There's a certain point when continuing to know at the expense of doing allows the mess to grow further.
To start to identify the mess you're facing, work through these questions: Users: Who are your intended users? What do you know about them? How can you get to know them better? How might they describe this mess? Stakeholders: Who are your stakeholders? What are their expectations? What are their thoughts about this mess? How might they describe it? Information: What interpretations are you dealing with? What information is being created through a lack of data or content? Current state: Are you dealing with too much information, not enough information, not the right information, or a combination of these?
Draw your mess.
Intent is the effect we want to have on something.
The words we choose matter. They represent the ideas we want to bring into the world.
For example, if we say that we want to make sustainable eco-centered design solutions, we can't rely on thick, glossy paper catalogs to help us reach new customers. By choosing those words, we completely changed our options.
Language is any system of communication that exists to establish shared meaning.
Perception is the process of considering, and interpreting something.
For Las Vegas casino owners and their customers, those carpet designs are good. For designers, they're bad. Neither side is right. Both sides have an opinion.
What we intend to do determines how we define words like good and bad.
What's good for a business of seven years may not work for a business of seven weeks. What works for one person may be destructive for another.
When we don't define what good means for our stakeholders and users, we aren't using language to our advantage. Without a clear understanding of what is good, bad can come out of nowhere.
When you're making decisions, balance what your stakeholders and users expect of you, along with what they believe to be good.
Pretty things can be useless, and ugly things can be useful. Beauty and quality are not always related.
When making things, we should aim to give equal attention to looking good and being good. If either side of that duality fails, the whole suffers.
Beware of pretty things. Pretty things can lie and hide from reality.
To avoid confusing each other, we have to consider how our message could be interpreted.
The meaning we intend to communicate doesn't matter if it makes no sense, or the wrong sense, to the people we want to reach.
To determine who matters, ask these questions: Who's most important to get agreement from? Who's most important to serve? What words might make them defensive? What words might put them at ease? How open are they to change? How will this affect their lives? How does the current state of things look to them? Is that good or bad?
Start with why.
Understanding the why behind what you're making allows you to uncover your intent and potential.
without a clear reason for doing something, even the most committed and loyal person will eventually abandon the hope of finishing the task.
To start with why, ask yourself: Why does this work need to be done? Why is change needed? Why do those changes matter? Why should other people care? Why hasn't this been tackled correctly? Why will this time be different?
When deciding what you're doing, ask yourself: What are you trying to change? What is your vision for the future? What is within your abilities? What do you know about the quality of what exists today? What further research will help you understand it? What has been done before? What can you learn from those experiences? What is the market and competition like? Has anyone succeeded or failed at this in the past?
There are many ways to do just about anything.
Whether you're working on a museum exhibit, a news article, or a grocery store, you should explore all of your options before choosing a direction.
To look at your options, ask yourself: How could we communicate our message? How much time and effort will it take? How could the solution look and feel? How will this be produced? How will this be maintained? How will this be measured? How will we know if we've succeeded?
Our why, what, and how aren't always determined in a linear process. The answers to these fundamental questions may change from moment to moment.
The words we choose change the things we make and how we think about them.
State your intent.
The following exercise will help you state your intent and clarify your language with other people. First, choose a set of adjectives you want your users to use to describe what you're making. Then, choose a set of adjectives that you're okay with not being used to describe the same thing.
I find these rules helpful during this exercise: When put together, each set of words should neither repeat nor disagree with each other. The second set shouldn't be a list of opposites from the first. Avoid negative adjectives, like slow or bad or ugly. Keep each word as neutral as possible. A good test is that someone shouldn't be able to tell which list is positive or negative.
Whenever we're making something, there are moments when it's no longer time to ponder. It's time to act, to make, to realize, and perhaps to fail.
As you go through the mess, you'll encounter several types of players: Current users: People who interact with whatever you're making. Potential users: People you hope to reach. Stakeholders: People who care about the outcome of what you're making. Competitors: People who share your current or potential users. Distractors: People that could take attention away from your intent.
Reality happens across channels and contexts.
As users, our context is the situation we're in, including where we are, what we're trying to do, how we're feeling, and anything else that shapes our experience. Our context is always unique to us and can't be relied upon to hold steady.
Tweeting while watching TV is an example of two channels working together to support a single context.
When you begin to unravel a mess, it's easy to be overwhelmed by the amount of things that need to come together to support even the simplest of contexts gracefully on a single channel.
Beware of jumping into an existing solution or copying existing patterns. In my experience, too many people buy into an existing solution's flexibility to later discover its rigidity.
When architecting information, focus on your own unique objectives. You can learn from and borrow from other people. But it's best to look at their decisions through the lens of your intended outcome.
When you discuss a specific subject, you subconsciously reference part of a large internal map of what you know. Other people can't see this map. It only exists in your head, and it's called your mental model.
Before you make objects like diagrams or maps, spend some time determining their scope and scale.
To think through scope and scale, ask yourself: What do people need to understand? What are the edges of the map or diagram? What are you not mapping or diagramming? Where will other people see this map or diagram (e.g., on a wall, in a presentation, on paper)?
While you're thinking about scope and scale, consider the timescale you're working with.
A timescale is a period of time your map or diagram represents. There are three main timescales: Then: How did things used to be? Now: How are things today? When: How do you see it being in the future?
Architecture before design.
When you're making a diagram, keep the structure pliable. Give yourself room to play with the boxes, move them around, and see what happens.
Keep it simple. The more you add styling and polish, the less you'll feel comfortable changing and collaborating on the diagram.
If people judge books by their covers, they judge diagrams by their tidiness.
People use aesthetic cues to determine how legitimate, trustworthy, and useful information is. Your job is to produce a tidy representation of what you're trying to convey without designing it too much or polishing it too early in the process.
Make it easy to make changes so you can take in feedback quickly and keep the conversation going, rather than defending or explaining the diagram.
Your diagram ultimately needs to be tidy enough for stakeholders to understand and comment on it, while being flexible enough to update.
The biggest mistake I see beginner sensemakers make is not expanding their toolbox of diagrammatic and mapping techniques.
The more diagrams you get to know, the more tools you have. The more ways you can frame the mess, the more likely you are to see the way through to the other side.
To help you build your toolbox, I've included ten diagrams and maps I use regularly in my own work.
Block Diagram. A block diagram depicts how objects and their attributes interrelate to create a concept.
Flow Diagram. A flow diagram outlines the steps in a process, including conditions a user or system is under, and connections between tasks.
Gantt Chart. A Gantt chart depicts how processes relate to one another over time. Timelines, and project plans are both common examples of Gantt charts. This type of chart helps us to understand relationships between people, tasks, and time.
Quadrant Diagram. A quadrant diagram illustrates how things compare to one another.
Venn Diagram. A Venn diagram is useful for highlighting overlapping concepts or objects.
Swim Lane Diagram. A swim lane diagram depicts how multiple players work together to complete a task or interact within a process. This is especially useful when you're trying to understand how different teams or people work together.
Hierarchy Diagram. A hierarchy diagram depicts how objects, concepts, people, and places relate to each other. In website design, hierarchy diagrams are often called sitemaps.
Mind Map. A mind map illustrates the connections between concepts, objects, ideas, channels, people, and places within a particular context.
Schematic. A schematic is a diagram of an object or interface simplified for the sake of clarity. Schematics are known by many other names including wireframes, sketches, lo-fis, and blueprints.
Journey Map. A journey map shows all of the steps and places that make up a person or group's experience.
Picking a diagram/map:
- Make a block diagram that shows how the pieces of a concept interrelate.
- Demystify a process by making a flow diagram.
- Break your latest project down into its individual tasks and make a Gantt chart.
- Compare a group of restaurants in your neighborhood in a quadrant diagram.
- Explore what happens when concepts or objects overlap using a Venn diagram.
- Break any multi-user process into a list of tasks per user with a swim lane diagram.
- Depict the content and organization of your favorite website in a hierarchy diagram.
- Unload all of the cool ideas in your mind right now in a mind map.
- Explain how to make your favorite food with a simple schematic. Bonus point for exploding it!
- Make a journey map of a day in your life.
Everything is easier with a map.
The power of a matrix diagram is that you can make the boxes collect whatever you want. Each box becomes a task to fulfill or a question to answer, whether you're alone or in a group.
Matrix diagrams are especially useful when you're facilitating a discussion, because they're easy to create and they keep themselves on track. An empty box means you're not done yet.
After you face reality, it still takes a tremendous amount of work and courage to move from understanding why something needs to change to knowing what you can do about it.
Change takes time.
When we reference a place, it exists within other places.
When we reference things, they exist within other things and places too.
Digital things live within other things and places, including physical and analog places.
Nothing exists in a vacuum. Everything connects to a larger whole. Whenever you're making something, figure out which levels you're working at:
Making changes at one level without considering the affects they have on other levels can lead to friction and dissatisfaction between our users, our stakeholders, and us.
You can turn a space into a place by arranging it so people know what to do there.
The way we choose to arrange a place changes how people intrepret and use it. We encode our intent through the clues we leave for users to know what we want them to do.
When you're cleaning up a big mess, assess the spaces between places as well as the places themselves.
Space may not have a designated purpose yet, but that doesn't stop users from going there. No matter what you're making, your users will find spaces between places. They bring their own context and channels with them, and they show you where you should go next. Find areas in flux and shine a light on them.
I once had a project where the word "asset" was defined three different ways across five teams.
I once spent three days defining the word "customer".
Language is complex. But language is also fundamental to understanding the direction we choose. Language is how we tell other people what we want, what we expect of them, and what we hope to accomplish together.
When we don't share a language with our users and our stakeholders, we have to work that much harder to communicate clearly.
When we decide that a word or concept holds a specific meaning in a specific context, we are practicing ontology.
Here are some examples of ontological decisions: Social networks redefining "like" and "friends" for their purposes The "folders" on a computer's "desktop" you use to organize "files" The ability to order at a fast food chain by saying a number
To refine your ontology, all you need is a pile of sticky notes, a pen, and some patience. Find a flat or upright surface to work on. Write a term or concept that relates to your work on each sticky note. Put the sticky notes onto the surface as they relate to each other. Start to create structures and relationships based on their location.
Ontology always exists, but the one you have today may be messy or nonsensical.
It's important to discuss and vet your ontological decisions with stakeholders and users.
A good starting point in exploring ontology is to bring everyone together to make a list of terms and concepts. Ask each person to share: One term that they wish they knew more about One term that they wish others understood better Go through each term as a group and use this as a forum for educating each other on what you know about language and context. Don't "uh huh" your way through words you've never heard or don't understand. Instead, untangle acronyms and unfamiliar phrases. If someone uses a different word than you do, ask for clarification. Why do they use that word? Get them to explain it. Complexity tends to hide in minutiae.
Create a list of words you say.
Documenting language standards can reduce linguistic insecurity.
A good controlled vocabulary considers: Variant spellings (e.g., American or British) Tone (e.g., Submit or Send) Scientific and popular terms (e.g., cockroaches or Periplaneta Americana) Insider and outsider terms (e.g., what we say at work; what we say in public) Acceptable synonyms (e.g., automobile, car, auto, or vehicle) Acceptable acronyms (e.g., General Electric, GE, or G.E.)
Create a list of words you don't say.
For the sake of clarity, you can also define: Terms and concepts that conflict with a user's mental model of how things work Terms and concepts that have alternative meaning for users or stakeholders Terms and concepts that carry historical, political, or cultural baggage Acronyms and homographs that may confuse users or stakeholders
In my experience, a list of things you don't say can be even more powerful than a list of things you do.
To define a term clearly: Write down the meaning of the term as simply as you can. Underline each term within your definition that needs to be further defined. Define those terms and test your definition with someone who doesn't know those terms yet. Look at each individual word and ask yourself: What does this mean? Is it as simple as possible?
As you talk through your controlled vocabulary, listen for stories and images people associate with each term.
Gather the following about each term: History: How did the term come into being? How has it changed over time? Myths: Do people commonly misunderstand this term, its meaning, or its usage? How? Alternatives: What are the synonyms for the term? What accidental synonyms exist?
Nouns represent each of the objects, people, and places involved in a mess. As an example, a post is a noun commonly associated with another noun, an author. Verbs represent the actions that can be taken. A post (n.) can be: written, shared, deleted, or read.
It's easy to adopt terms that are already in use or to be lazy in choosing our language. But when you're deciding which words to use, it is important to consider the alternatives, perceptions, and associations around each term.
When you combine nouns with appropriate verbs, the resulting sentences can be referred to as requirements for what you're making.
When we talk about what something has to do, we sometimes answer with options of what it could do or opinions of what it should do.
A strong requirement describes the results you want without outlining how to get there.
Measurements have rhythm.