The word define was used 36 times across 16 pages
If you rip out the content from your favorite book and throw the words on the floor, the resulting pile is not your favorite book.
If you define each word from your favorite book and organize the definitions alphabetically, you would have a dictionary, not your favorite book.
If you arrange each word from your favorite book by gathering similarly defined words, you have a thesaurus, not your favorite book.
Neither the dictionary nor the thesaurus is anything like your favorite book, because both the architecture and the content determine how you interpret and use the resulting information.
For example, "8 of 10 Doctors Do Not Recommend" and "Doctor Recommended" are both true statements, but each serves a different intent.
Language is any system of communication that exists to establish shared meaning. Even within a single language, one term can mean something in situation A and something different in situation B. We call this a homograph. For example, the word pool can mean a swimming pool, shooting pool, or a betting pool.
Perception is the process of considering, and interpreting something. Perception is subjective like truth is. Something that's beautiful to one person may be an eyesore to another. For example, many designers would describe the busy, colorful patterns in the carpets of Las Vegas as gaudy. People who frequent casinos often describe them as beautiful.
However good or bad these carpet choices seem to us, there are reasons why they look that way. Las Vegas carpets are busy and colorful to disguise spills and wear and tear from foot traffic. Gamblers likely enjoy how they look because of an association with an activity that they enjoy. 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.
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.
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.
Your why may be "because you want this checked off your to-do list" or "because you want to play with certain materials or ideas."
Your resulting what might be to "start making the first thing that comes to mind."
They may not be lofty in intent, but the intent has been stated. These are valid answers to why and what that will serve as a guide for how you define what is good. Your actions will be the result of your answers.
How long would you spend on a task without understanding why it's important or what you are actually accomplishing? Constantly answering these basic questions are a big part of our everyday life.
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.
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.
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.
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.
When I was in grade school, we did an assignment where we were asked to define terms clearly enough for someone learning our language. To define "tree" as "a plant that grows from the ground," we first needed to define "plant," "grow," and "ground."
It was an important lesson to start to understand the interconnectivity of language. I like to apply this kind of thinking in my work to uncover terms that are nested within other terms and their definitions.
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?
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.
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:
Goals change what's possible and what happens next.
Whether big or small, for today or this year, goals change how you spend time and resources.
The ways you set and measure goals affects how you define a good day or a bad day, valuable partners or the competition, productive time or a waste of time.
Goals are only reachable when you're being realistic about the distance between reality and where you want to go. You may measure that distance in time, money, politics, talent, or technology.
Once you figure out the distance you need to travel, momentum can replace the anxiety of not knowing how to move forward.
Most things can be measured by systems or people.
Indicators tell you if you're moving towards your intent or away from it. A business might use averages like dollars per order or call response time as indicators of how well they're doing.
It's not always easy to figure out how to measure things, but if you're persistent, you can gain invaluable insights about your progress.
The good news is the work it takes to define and measure indicators is almost always worth the effort.
To find the right indicators, start with these questions:
Examples of indicators follow.
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.
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.
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.