Definition: To plan something with an intended outcome.
Also referenced as: Designed (adjective)
Related to: Architect, Communication, Concept, Direction, Frame, Intent, Purpose
Chapter 1: Identify the Mess | Page 27
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 2: State your Intent | Page 32
Intent is the effect we want to have on something. We make language-based decisions whenever we talk about our intent.
Our language choices change how we use our time and energy. For every word we use to describe where we want to go, there’s another word that we’re walking away from.
For every amusement park you make, you’re not making a video game. When you intend to be fun for kids, you can use stories but not metaphors. If you want something to be relaxing, it’s harder to make it educational.
The words we choose matter. They represent the ideas we want to bring into the world.
We need words so we can make plans. We need words to turn ideas into things.
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.
Chapter 3: Face Reality | Page 55
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.
Imagine trying to design a luxury fashion magazine using a technical system for grocery store coupons. The features you need may seem similar enough until you consider your context. That’s when reality sets in.
What brings whopping returns to one business might crush another. What works for kids might annoy older people. What worked five years ago may not work today.
We have to think about the effects of adopting an existing structure or language before doing so.
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.
Chapter 3: Face Reality | Page 61
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 64
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.
As you make your diagram, keep your stakeholders in mind. Will they understand it? Will anything distract them? Crooked lines, misspellings, and styling mistakes lead people astray. Be careful not to add another layer of confusion to the mess.
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.
Chapter 4: Choose a Direction | Page 103
Rasheed is a consultant helping the human resources department of a large company. They want to move their employee-training processes online.
Rasheed’s research uncovered a lot of language inconsistencies between how employees are hired and trained in various departments.
He always expects to account for departmental differences, but he fears this many similar terms for the same things will make for a sloppy system design.
Rasheed has a choice. He could document the terms as they exist and move on. Or he could take the time to find a direction that works for everyone.
He decides to group the terms by similar meanings and host a meeting with the departments to choose which terms should lead, and which ones should fall back.
During the meeting, Rasheed:
Chapter 4: Choose a Direction | Page 95
I’ve avoided using these terms and concepts:
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
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:
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 116
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:
Chapter 7: Prepare to Adjust | Page 155
No one comments on the plumbing or electricity of a building unless the toilet is clogged or the lights aren’t working. Then all of a sudden, pipes and wires are a hot topic of conversation.
Similarly, people don’t compliment or even critique information architecture unless it’s broken.
The “information architecture part” is almost invisible when separated from how something looks and how it’s made. For example, we can’t evaluate the quality of the structure of this eBook without considering how it was written, edited, designed, illustrated, typeset, marketed and delivered.
If you practice information architecture for the glory, get ready to be disappointed.
But if you practice it for the clarity it can bring, get ready for some seriously interesting work.