How to Make Sense of Any Mess by Abby Covert

Chapter 3: Face Reality | Page 63

Architecture before design.

You can tell complex stories in a diagram with boxes and arrows. A box represents a thing; an arrow represents a relationship between things.

These relationships can be one-way (e.g., dropping a package into a mailbox) or two-way (e.g., calling the postal service to see if it was delivered).

We use a diamond shape to represent a decision point. This allows us to diagram relationships that change depending on the circumstances.

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.

Start by creating a box for each concept, each piece of content, and each process. Arrange the boxes based on how they relate to each other. Play. See what reveals itself as you move things around. Try a few different arrangements before you add the arrows.

Keep it simple. The more you add styling and polish, the less you’ll feel comfortable changing and collaborating on the diagram.

Chapter 3: Face Reality | Page 66

1. Block Diagram

A block diagram depicts how objects and their attributes interrelate to create a concept.

A concept is an abstract idea or general notion that exists in people’s mental models. For example, pizza is a concept on which many actual pies are fired.

Chapter 3: Face Reality | Page 70

5. Venn Diagram

A Venn diagram is useful for highlighting overlapping concepts or objects. The overlap, known to some as the hedgehog or the nut, represents how these things relate. In this example, both pizza and movie relate to Friday night at home.

This same technique can be used to sort things into sets based on how they’re similar. For example, we might make a circle for movies we love and one for movies referencing pizza, and put the movies we love that reference pizza in the overlap.

Chapter 3: Face Reality | Page 72

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

L-brackets, as seen below, tend to be easiest to read, but you may also see hierarchical relationships depicted as trees or pyramids.

Chapter 3: Face Reality | Page 73

8. Mind Map

A mind map illustrates the connections between concepts, objects, ideas, channels, people, and places within a particular context.

These concepts don’t necessarily live under an established hierarchy or sequence. For example, in the diagram above, I’ve outlined the various aspects of running a pizza parlor as the owner (me!) might think about them.

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 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:

• Create a list of terms to explore.
• Define each term as simply as you can.
• Underline words within your definitions that need to be further defined, and define them.
• Document the history, alternatives, and myths associated with each term.
• Review your list of defined terms with some of your users. Refine the list based on their feedback.
• Create a list of requirements that join your nouns and verbs together.

Chapter 4: Choose a Direction | Page 89

Reduce linguistic insecurity.

The average person gives and receives directions all day long, constantly experiencing the impact of language and context. Whether it’s a grocery list from a partner or a memo from a manager, we’ve all experienced what happens when a poor choice of words leads to the wrong outcome. Whether we’re confused by one word or the entire message, the anxiety that comes from misunderstanding someone else’s language is incredibly frustrating.

Imagine that on your first day at a new job every concept, process, and term you’re taught is labeled with nonsense jargon. Now imagine the same first day, only everything you’re shown has clear labels you can easily remember. Which second day would you want?

We can be insecure or secure about the language we’re expected to use. We all prefer security.

Linguistic insecurity is the all too common fear that our language won’t conform to the standard or style of our context.

To work together, we need to use language that makes sense to everyone involved.

Chapter 4: Choose a Direction | Page 90

Understand ontology.

If we were to write a dictionary, we’d be practicing lexicography, or collecting many meanings into a list. 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.

1. Find a flat or upright surface to work on.
2. Write a term or concept that relates to your work on each sticky note.
3. Put the sticky notes onto the surface as they relate to each other. Start to create structures and relationships based on their location.

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:

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

Chapter 4: Choose a Direction | Page 93

Create a list of words you say.

A controlled vocabulary is an organized list of terms, phrases, and concepts intended to help someone navigate a specific context.

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

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:

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