User (noun.)

Definition: A person who encounters a message.

Also referenced as: Users (noun)

Related to: Assumption, Bias, Channel, Context, Ecosystem, Experience, Factor, History, Intent, Interact, Interface, Journey, Meaning, Mental Model, Object, Path, Perception, Player, Requirement, Stakeholder, Subjective, System, Worksheet

Chapter 1: Identify the Mess | Page 20

What’s information?

Information is not a fad. It wasn’t even invented in the information age. As a concept, information is old as language and collaboration is.

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.

For example, imagine you’re looking into a bakery case. There’s one plate overflowing with oatmeal raisin cookies and another plate with a single double-chocolate chip cookie. Would you bet me a cookie that there used to be more double-chocolate chip cookies on that plate? Most people would take me up on this bet. Why? Because everything they already know tells them that there were probably more cookies on that plate.

The belief or non-belief that there were other cookies on that plate is the information each viewer interprets from the way the cookies were arranged. When we rearrange the cookies with the intent to change how people interpret them, we’re architecting information.

While we can arrange things with the intent to communicate certain information, we can’t actually make information. Our users do that for us.

Chapter 1: Identify the Mess | Page 24

Users are complex.

User is another word for a person. But when we use that word to describe someone else, we’re likely implying that they’re using the thing we’re making. It could be a website, a product or service, a grocery store, a museum exhibit, or anything else people interact with.

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. From how we use mobile phones to how we traverse grocery stores, none of us are exactly the same. We don’t know why we do what we do. We don’t really know why we like what we like, but we do know it when we see it. We’re fickle.

We expect things to be digital, but also, in many cases, physical. We want things to feel auto-magic while retaining a human touch. We want to be safe, but not spied on. We use words at our whim.

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.

Chapter 1: Identify the Mess | Page 27

Meet Carl.

Carl is a design student getting ready to graduate. But first, he has to produce a book explaining his design work and deliver a ten-minute presentation.

While Carl is a talented designer, public speaking makes him queasy and he doesn’t consider himself much of a writer. He has drawers and boxes full of notes, scribbles, sketches, magazine clippings, quotes, and prototypes.

Carl has the pieces he needs to make his book and presentation come to life. He also has a momentum-killing fear of the mess he’s facing.

To help Carl identify his mess, we could start by asking questions about its edges and depths:

Chapter 1: Identify the Mess | Page 28

It’s your turn.

This chapter outlines why it’s important to identify the edges and depths of a mess, so you can lessen your anxiety and make progress.

I also introduced the need to look further than what is true, and pay attention to how users and stakeholders interpretlanguage, data, and content.

To start to identify the mess you’re facing, work through these questions:

Chapter 2: State your Intent | Page 34

Good is in the eye of the beholder.

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.

And while you have to define what good means to create good information architecture, it’s not just the architecture part that needs this kind of focus.

Every decision you make should support what you’ve defined as good: from the words you choose to the tasks you enable, and everything in between.

When you’re making decisions, balance what your stakeholders and users expect of you, along with what they believe to be good.

Chapter 2: State your Intent | Page 35

Looking good versus being 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.

As users, we may assume that a good-looking thing will also be useful and well thought-out. But it only takes a minute or two to see if our assumptions are correct. If it isn’t good, we’ll know.

As sensemakers, we may fall victim to these same assumptions about the relationships between beauty and quality of thought.

Beware of pretty things. Pretty things can lie and hide from reality. Ugly things can too.

If we’re going to sort out the messes around us, we need to ask difficult questions and go deeper than how something looks to determine if it’s good or not.

Chapter 2: State your Intent | Page 38

Who matters?

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.

We need to consider our intended users. Sometimes they’re our customers or the public. Often times, they’re also stakeholders, colleagues, employees, partners, superiors, or clients. These are the people who use our process.

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?

Chapter 2: State your Intent | Page 45

Meet Karen.

Karen is a product manager at a startup. Her CEO thinks the key to launching their product in a crowded market is a sleek look and feel.

Karen recently conducted research to test the product with its intended users. With the results in hand, she worries that what the CEO sees as sleek is likely to seem cold to the users they want to reach.

Karen has research on her side, but she still needs to define what good means for her organization. Her team needs to state their intent.

To establish an intent, Karen talks with her CEO about how their users’ aesthetic wants don’t line up with the look and feel of the current product.

She starts their conversation by confirming that the users from her research are part of the intended audience for the product.

Next, she helps the CEO create a list of questions and actions the research brought up.

Afterwards, Karen develops a plan for communicating her findings to the rest of the team.

Chapter 2: State your Intent | Page 46

State your intent.

Like Karen, you need to make sure the language you use to state your intent doesn’t stand in your way. 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.

Chapter 3: Face Reality | Page 51

Reality involves many players.

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.

You may play several of these roles yourself. Be aware of potential conflicts there.

For example, if you believe your users are like you but they’re not, there’s more room for incorrect assumptions and miscommunications.

Chapter 3: Face Reality | Page 54

Reality has many intersections.

Tweeting while watching TV is an example of two channels working together to support a single context.

A single channel can also support multiple contexts.

For example, a website may serve someone browsing on a phone from their couch, on a tablet at a coffee shop, or on a desktop computer in a cubicle.

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.

“It’s just a ____________” is an easy trap to fall into. But to make sense of real-world problems, you need to understand how users, channels, and context relate to each other.

What channels do your users prefer? What context are they likely in when encountering what you’re making? How are they feeling? Are they in a hurry? Are they on slow Wi-Fi? Are they there for entertainment or to accomplish a task?

Considering these small details will make a huge difference for you and your users.

Chapter 3: Face Reality | Page 61

Rhetoric matters.

Rhetoric is communication designed to have a persuasive effect on its audience.

Here are some common rhetorical reasons for making diagrams and maps:

Chapter 3: Face Reality | Page 67

2. Flow Diagram

A flow diagram outlines the steps in a process, including conditions a user or system is under, and connections between tasks.

Conditions are rules that dictate the flow. For example, the path I take in the flow is different if I’m ordering for pickup or delivery.

Chapter 3: Face Reality | Page 75

10. Journey Map

A journey map shows all of the steps and places that make up a person or group’s experience.

The rows represent the user’s context (e.g., outside, on the bus, at home). Each point represents an event or a task that makes up the overall journey. Each point is placed sequentially as it relates to the other points.

This example shows events that only involve one person, but journey maps are also useful for showing the movement of pairs, teams, and organizations.

Chapter 3: Face Reality | Page 76

Try diagramming.

  1. Make a block diagram that shows how the pieces of a concept interrelate.
  2. Demystify a process by making a flow diagram.
  3. Break your latest project down into its individual tasks and make a Gantt chart.
  4. Compare a group of restaurants in your neighborhood in a quadrant diagram.
  5. Explore what happens when concepts or objects overlap using a Venn diagram.
  6. Break any multi-user process into a list of tasks per user with a swim lane diagram.
  7. Depict the content and organization of your favorite website in a hierarchy diagram.
  8. Unload all of the cool ideas in your mind right now in a mind map.
  9. Explain how to make your favorite food with a simple schematic. Bonus point for exploding it!
  10. Make a journey map of a day in your life.

Chapter 3: Face Reality | Page 78

Face your reality.

Everything is easier with a map. Let me guide you through making a map for your own mess.

On the following page is another favorite diagram of mine, the matrix diagram.

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 making a simple matrix of users, contexts, players, and channels, you’ll have a guide to understanding the mess. By admitting your hopes and fears, you’re uncovering the limits you’re working within.

This matrix should also help you understand the other diagrams and objects you need to make, along with who will use and benefit from them.

Chapter 4: Choose a Direction | Page 100

Watch out for options and opinions.

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.

A weak requirement might be written as: “A user is able to easily publish an article with one click of a button.” This simple sentence implies the interaction (one click), the interface (a button), and introduces an ambiguous measurement of quality (easily).

When we introduce implications and ambiguity into the process, we can unknowingly lock ourselves into decisions we don’t mean to make.

As an example, I once had a client ask for a “homepage made of buttons, not just text.” He had no idea that, to a web designer, a button is the way a user submits a form online. To my client, the word button meant he could change the content over time as his business changes.

Chapter 4: Choose a Direction | Page 101

Opinions are like…

No matter how hard we try to be aware of opinions swirling around us, it’s hard to remain neutral. But in the end, progress can’t happen without a decision.

When you’re choosing a direction, you may run into these questions:

  • What if I disagree with a user need or opinion identified in my research?
  • What if I disagree with the way another stakeholder sees a core concept or decision?
  • What if I don’t want to do this the way others want me to?

Some people choose to hide from the realities behind these questions. But if you shield your ideas and simply follow orders, you may end up with goal-crushing (and soul-crushing) results.

We have to balance what we know with what we see and what other people say.

We listen to our users and our guts. There is no one right way. There is only your way.

Chapter 4: Choose a Direction | Page 104

Control your vocabulary.

Are you facing a mess like Rasheed’s? Do your stakeholders speak the same language? Do you collectively speak the same language as your users? What language might be troublesome in the context of what you are doing? What concepts need to be better understood or defined?

To control your vocabulary:

Chapter 4: Choose a Direction | Page 83

We work at different levels.

When we reference a place, it exists within other places. If I say, “I live in SoHo,” that place is within another place called Manhattan, which is within a place called New York City.

When we reference things, they exist within other things and places too. For example, a mug exists within a cabinet, in a coffee shop, in a building, on a city block, in a neighborhood, in a city, in a state, in a country, on a continent, and so on.

Digital things live within other things and places, including physical and analog places. For example, a user accesses a mobile application on a smartphone, in a coffee shop, in a building, on a city block….

We make places and we make things. The places and things that we make are part of a user’s real life.

Chapter 4: Choose a Direction | Page 84

What are you making?

Nothing exists in a vacuum. Everything connects to a larger whole. Whenever you’re making something, figure out which levels you’re working at:

Object: a specific thing.

Interface: a point where a user affects that thing.

Location: a particular place or position.

Journey: the steps in or between locations.

Structure: a configuration of objects and locations.

System: a set of structures working together.

Ecosystem: a collection of related systems.

Chapter 4: Choose a Direction | Page 85

These levels deeply affect one another.

Once you know what level you’re working at, you can zoom in to the appropriate level of detail. Sometimes we need to zoom all the way in on an object. Other times it’s more important to zoom out to look at the ecosystem. Being able to zoom in and out as you work is the key to seeing how these levels affect one another.

When you’re deep in the details, it’s easy to forget your broad effect. When you’re working overhead, it’s easy to forget how your decisions affect things down on the ground. 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. One tiny change can spark a thousand disruptions.

For example, if we owned a restaurant and decided to eliminate paper napkins to be environmentally friendly, that would impact the entire restaurant, not just the table service our diners experience.

We’d need to consider other factors like where dirty napkins go, how we collect them, how often they’re picked up and cleaned, how many napkins we need on hand between cleanings, and if we should use paper napkins if something spills in the dining room.

One tiny decision leads to another, and another.

Chapter 4: Choose a Direction | Page 86

We make places.

You can turn a space into a place by arranging it so people know what to do there. This act is called placemaking. If you arrange a table and chairs in the middle of a room, meetings, meals, study, and play are all potential uses of that place. But if you add a fancy dining set and linens to the table, you’re suggesting that it’s a dining area.

In placemaking, you choreograph a sequence of steps users can take and decide how you want them to move. You can recommend steps, but they’ll move wherever and however they want. They may move the place settings aside and open a laptop for a meeting. You can prescribe the steps, but they do the dancing.

The ways you enforce your way of doing things changes how users think about the place you made and perhaps ultimately, how they think about you.

You could add a sign that says “Dining Only Please.” You could also add waitstaff wearing tuxedos and glaring dispositions. Each of these would say something about you and the place you made.

The way we choose to arrange a place changes how people interpret and use it. We encode our intent through the clues we leave for users to know what we want them to do.

Chapter 4: Choose a Direction | Page 87

There are spaces between the places we make.

When you’re cleaning up a big mess, assess the spaces between places as well as the places themselves.

A place is a space designated for a specific purpose.

For example, if you built a public park, you might make a path to walk on, a picnic area, a playground, some bathrooms, and a soccer field. These areas were made with tasks in mind.

If parkgoers wear down a path through your fresh laid grass, you as the parkitect (ha!) could see it as an annoyance. Or you could see it as a space between places and pave over it so people can get where they want to go without walking through the mud.

A space is an open, free, or unoccupied area.

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.

Chapter 4: Choose a Direction | Page 88

Language matters.

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”.

I once defined and documented over a hundred acronyms in the first week of a project for a large company, only to find 30 more the next week.

I wish I could say that I’m exaggerating or that any of this effort was unnecessary. Nope. Needed.

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.

Without language, we can’t collaborate.

Unfortunately, it’s far too easy to declare a direction in language that doesn’t make sense to those it needs to support: users, stakeholders, or both.

When we don’t share a language with our users and our stakeholders, we have to work that much harder to communicate clearly.

Chapter 4: Choose a Direction | Page 92

Design with, not for.

It’s important to discuss and vet your ontological decisions with stakeholders and users. Talking about language choices gives you a chance to test them.

It may sound obvious, but it’s quite common to think something is clearly defined before talking about it with other people.

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:

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.

Chapter 4: Choose a Direction | Page 94

Create a list of words you don’t say.

A controlled vocabulary doesn’t have to end with terms you intend to use. Go deeper by defining terms and concepts that misalign with your intent.

For the sake of clarity, you can also define:

In my experience, a list of things you don’t say can be even more powerful than a list of things you do. I’ve been known to wear a whistle and blow it in meetings when someone uses a term from the don’t list.

Chapter 4: Choose a Direction | Page 95

Words I don’t say in this eBook.

I’ve avoided using these terms and concepts:

  1. Doing/Do the IA (commonly misstated)
  2. IA (as an abbreviation)
  3. Information Architecture (as a proper noun)
  4. Information Architect (exceptions in my dedication and bio pages)
  5. App as an abbreviation (too trendy)
  6. Very (the laziest word ever)
  7. User experience (too specific to design)
  8. Metadata (too technical)
  9. Semantic (too academic)
  10. Semiotic (too academic)

I have reasons why these words aren’t good in the context of this book. That doesn’t mean I never use them; I do in some contexts.

Chapter 4: Choose a Direction | Page 99

Think about relationships between nouns and verbs.

When you combine nouns with appropriate verbs, the resulting sentences can be referred to as requirements for what you’re making.

From the previous example:

  • An author can write a post.
  • An author can delete a post.
  • Any user can share a post.
  • Any user can read a post.

This list of requirements defines the ideal solution. Each requirement tells us who should be able to do what in the eventual state.

When you take the time to make requirements concrete and prioritize them, you can better understand what you’re actually making.

If you’re designing an interface that prioritizes reading, it will be fundamentally different than an interface that prioritizes writing, even with the exact same list of requirements.

Chapter 5: Measure the Distance | Page 112

Common indicators.

  • Satisfaction: Are customers happy with what you’re delivering against your promises?
  • Kudos: How often do people praise you for your efforts or contributions?
  • Profit: How much was left over after expenses?
  • Value: What would someone pay for it?
  • Loyalty: How likely are your users to return?
  • Traffic: How many people used, visited, or saw what you made?
  • Conversion: What percentage of people acted the way you hoped they would?
  • Spread: How fast is word getting around about what you’re doing?
  • Perception: What do people believe about what you’re making or trying to achieve?
  • Competition: Who has similar intents to yours?
  • Complaints: How many users are reaching out about an aspect of your product or service?
  • Backlash: What negative commentary do you receive or expect?
  • Expenses: How much did you spend?
  • Debt: How much do you owe?
  • Lost time: How many minutes, hours, or days did you spend unnecessarily?
  • Drop-off: How many people leave without taking the action you hoped they would?
  • Waste: How much do you discard, measured in materials and time?
  • Murk: What alternative truths or opinions exist about what you’re making or trying to achieve?

Chapter 5: Measure the Distance | Page 114

Use worksheets to mine data from people.

Once you have a list of indicators to guide you, think about where the data could come from.

A worksheet can help you capture important details that only exist in people’s heads or personal records.

You can fill out a worksheet in a meeting or distribute copies of it and collect them after people have time to answer your questions. To choose the best way to gather the data, keep these considerations in mind:

  • Time: How much are you asking for, and how long might it take?
  • Access: How many sources are your respondents using to find answers? Who else might they need to contact?
  • Bias: Are they applying their own thoughts and preferences, or delivering data?

If your users or stakeholders need a significant amount of time, access, or thought to answer your questions, let them get back to you instead of trying to get through the worksheet together.

Chapter 5: Measure the Distance | Page 116

Flags tell us if we’re headed in the right direction.

Flags are useful because they allow us to know when something important happens. We can attach a flag to most indicators.

These are all examples of flags:

  • Having a loved one call when they arrive at their destination safely
  • A dashboard light that reminds you to get gas in the next 50 miles
  • A weekly email that shares customer service feedback with a design team
  • An email alert when competitors are mentioned in the press
  • A monthly report of how many users drop off at each step of an online registration process

Flags allow us to use data more proactively.

Chapter 6: Play with Structure | Page 125

There are many ways to structure things.

A structure is a configuration. An unorganized pile is a structure. So is a table of contents or a house of cards. Every thing has a structure.

To choose a good structure for what you are making, you need to find one that:

There will always be several structures you can use.

Allowing your content to try on a structure you believe to be bad or wrong can be helpful. When we determine what something won’t be, we often reveal a little more about what it will be.

Don’t settle for the first structure you come up with. Take the same things and arrange them, not in one way, but in two or three ways. Compare them. Iterate. Test. Refine. Combine. Change. Argue.

Chapter 6: Play with Structure | Page 126

Taxonomy is how we arrange things.

When you set out to arrange something, how do you decide where the pieces go? Is it based on what looks right to you, what you believe goes together, or what someone told you to do? Or maybe you let gravity or the alphabet determine the order?

To effectively arrange anything, we have to choose methods for organizing and classifying content in ways that convey the intended information to our intended users.

Structural methods for organization and classification are called taxonomy.

Common examples of taxonomies include:

  • The scientific classification for plants, animals, minerals, and other organisms
  • The Dewey Decimal system for libraries
  • Navigational tabs on a website
  • Organizational charts showing management and team structures

Chapter 6: Play with Structure | Page 127

We combine taxonomies to create unique forms.

Taxonomies shape our experience at every level. We use taxonomies to make sense of everything from systems to objects. It often takes multiple taxonomic approaches to make sense of a single form.

A Form is the visual shape or configuration something takes. The form is what users actually experience.

Even a simple form like this book uses several taxonomies to help you read through the content, understand it, and use it.

A few taxonomies in this book:

Chapter 6: Play with Structure | Page 137

Taxonomies can be hierarchical or heterarchical.

When taxonomies are arranged hierarchically, it means that successive categories, ranks, grades, or interrelated levels are being used. In a hierarchy, a user would have to select a labeled grouping to find things within it. A hierarchy of movies might look like this:

- Comedies

  • Romantic comedies
  • Classic comedies
  • Slap-stick comedies

Hierarchies tend to follow two patterns. First, a broad and shallow hierarchy gives the user more choices up front so they can get to everything in a few steps. As an example, in a grocery store, you choose an aisle, and each aisle has certain arrangement of products, but that’s as deep as you can go.

A narrow and deep hierarchy gives the user fewer choices at once. On a large website, like usa.gov, a few high level options point users to more specific items with each click.

When individual pieces exist on one level without further categorization, the taxonomy is heterarchical. For example, each lettered box in the arrangement in this illustration is heterarchical.

Chapter 6: Play with Structure | Page 139

Taxonomies can be sequential.

Sequence is the order in which something is experienced. Some sequences happen in a logical order, where the steps are outlined ahead of time.

Other sequences are more complex with alternative paths and variations based on the circumstances, preferences, or choices of the user or the system.

These are all examples of sequences:

  • A software installation wizard
  • New patient sign-up forms
  • A refund process at a retail store
  • A job application
  • A recipe
  • A fiction book
  • The checkout process on a website

Like any taxonomy, the categories and labels you choose affect how clear a sequence is to use.

Chapter 6: Play with Structure | Page 141

Hypertexts bridge taxonomies.

We use hypertext to connect things without necessarily placing them together.

Hypertexts are fundamentally different from hierarchical, heterarchical, and sequential taxonomies, because they don’t change where things are located, just how they’re found.

We use hyperlinks to allow users to jump between taxonomies instead of duplicating or moving content. For example, we might hyperlink the bolded words throughout this book. If a user clicks on one of them, we could take them to a definition in the lexicon. We’re moving the user to the content instead of repeating it.

A signpost directing you to a store around the corner is also hypertextual, because it sends you to a specific location without changing the location of the store.

Similarly, websites use hypertext to link to content without needing to repeat it.

Chapter 6: Play with Structure | Page 143

Meet Joan

Joan is the social media coordinator for an airline that recently merged with another airline. Overnight, her team became responsible for twice as much work as before. She’s also now responsible for managing twice as many people.

As the details of the merger iron out, duplicative channels have to be dealt with. For example, they now have two Twitter accounts and two help directories on two different websites. To tie everything together, Joan:

Chapter 7: Prepare to Adjust | Page 149

The sum is greater than its parts.

We need to understand the sum of a lot of pieces to make sense of what we have.

For example, let’s say we’re working on bringing a product to the market. To support this process, we might create:

These are all important pieces individually, but we need to look at them together to answer questions about the whole such as:

Chapter 7: Prepare to Adjust | Page 150

It’s easy to reach agreement alone.

Maybe you’re working on a project independently and you’re the only stakeholder and user.

More likely, you’re working with other people to serve other people. In that scenario, making maps and diagrams alone at your desk is not practicing information architecture.

Your whole team should be able to influence and react to your tools and methods. You should be making prototypes to get feedback from users on language and structure.

Getting everyone involved early is crucial. Every step you take should come from the direction you choose together. If you don’t get agreement up front, prepare for more work later.

When you see the world through the eyes of other people, you can spot weaknesses and opportunities for improvement. Don’t hide from other stakeholders or wait until the end of the project to talk to users.

Chapter 7: Prepare to Adjust | Page 153

We serve many masters.

No matter what the mess is made of, we have many masters, versions of reality, and needs to serve. Information is full of history and preconceptions.

Stakeholders need to:

  • Know where the project is headed
  • See patterns and potential outcomes
  • Frame the appropriate solution for users

Users need to:

It’s our job to uncover subjective reality.

An important part of that is identifying the differences between what stakeholders think users need and what users think they need for themselves.

Chapter 7: Prepare to Adjust | Page 154

Make room for information architecture.

If you find yourself needing to promote this practice, here are some ways you can talk about it:

You: “Wow, we have lots of information floating around about this, huh?”

Them: “It’s a bit unruly, isn’t it?”

You: “Yeah, I think I can help though. I recently learned about the practice of information architecture. Have you heard of it?”

Them: “Never heard of it. What is it?”

You: “It’s the practice of deciding which structures we need so our intent comes through to users.”

Them: “Is it hard? Do we need an expert?”

You: “Well, it isn’t hard if we’re willing to collaborate and make decisions about what we’re doing. I have some tools we can try. What do you think?”

Chapter 7: Prepare to Adjust | Page 156

Be the filter, not the grounds.

When making a cup of coffee, the filter’s job is to get the grit out before a user drinks the coffee. Sensemaking is like removing the grit from the ideas we’re trying to give to users.

What we remove is as important as what we add. It isn’t just the ideas that get the work done.

Be the one not bringing the ideas. Instead, be the filter that other people’s ideas go through to become drinkable:

With those skills, you’ll always have people who want to work with you.

Chapter 7: Prepare to Adjust | Page 159

Meet Abby.

Abby Covert is an information architect. After ten years of practicing information architecture for clients, Abby worried that too few people knew how to practice it themselves. She decided that the best way to help would be to teach this important practice.

After two years of teaching without a textbook, Abby told her students that she intended to write the book that was missing from the world: a book about information architecture for everybody.

As she wrote the first draft, she identified a mess of inconsistencies in the language and concepts inherent in teaching an emerging practice. At the end of the semester, she had a textbook for art school students, but she didn’t have the book that she intended to write for everybody. She had gone in the wrong direction to achieve a short-term goal.

She was frustrated and fearful of starting over. But instead of giving up, Abby faced her reality and used the advice in this book to make sense of her mess.

To get to the book you are reading, she wrote over 75,000 words, defined over 100 terms as simply as she could, and tested three unique prototypes with her users.

She hopes that it makes sense.

Chapter 7: Prepare to Adjust | Page 160

Make sense yet?

  1. Have you explored the depth and edges of the mess that you face?
  2. Do you know why you have the intent you have and what it means to how you will solve your problem?
  3. Have you faced reality and thought about contexts and channels your users could be in?
  4. What language have you chosen to use to clarify your direction?
  5. What specific goals and baselines will you measure your progress against?
  6. Have you put together various structures and tested them to make sure your intended message comes through to users?
  7. Are you prepared to adjust?