Information architecture is the way that we arrange the parts of something to make it understandable.
causes for confusing information. Too much information Not enough information Not the right information Some combination of these (eek!)
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.
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?
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.
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.
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. When faced with a problem, you reference your mental model and try to organize the aspects and complexities of what you see into recognizable patterns. Your ongoing experience changes your mental model.
Your diagram ultimately needs to be tidy enough for stakeholders to understand and comment on it, while being flexible enough to update.
People often get in their own way by becoming overwhelmed with choices, choosing not to choose instead. Others are limited by frustration over things they can't change immediately or easily.
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.
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.
When we decide that a word or concept holds a specific meaning in a specific context, we are practicing ontology.
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 goal is something specific that you want to do. A well-defined goal has the following elements: Intent: What are the specific results you want to see for your efforts? Baseline: What points of reference can you use to compare your progress with where you are today? Progress: How will you measure movement towards or away from your goal?