Information Architecture has exceptionally broad-reaching consequences. It affects the software we build, the business model behind it, and the way people interact on all sides of a product. No project can afford to leave team members out of the IA circle.
Fortunately, it can be very approachable.
We humans naturally organize how we think about the world around us. We build up definitions for words based on our own experiences and perspectives. We group concepts in ways that make sense to us. The problem is that we mostly do this on our own, with our individual sets of knowledge and experience. Information Architecture seeks to bring more order and precision to that natural process, as well as to make the process more collaborative and the end result easier to share.
To clarify before I dig in too much further, when I refer to IA, I’m not talking about just a sitemap. Sitemaps and similar artifacts are useful and should probably be part of a project at some point, but IA is so much bigger than that. The organization of information happens at many levels, most importantly before you’re even sure a website is the right thing to build.
## Inspiration & Basics
I recently ran across Abby Covert’s book, “[How to Make Sense of Any Mess](http://www.howtomakesenseofanymess.com/),” a wonderfully approachable introduction to, well, making sense of messy information. In the book, there are many points that resonate with our perspective at Atomic Object. In particular, [Drew Colthorp’s talk on “Practical Abstraction”](https://atomicobject.com/resources/papers-and-presentations#practical-abstraction) highlights the power of clear ideas represented well in code.
On that note, it’s also important to have clear, organized terminology to discuss how we organize concepts. Abby discusses these terms in her book:
A collection of unambiguously defined terms that provide a way for people to talk about a particular subject. Words may have varied definitions and connotations in other subjects, but they should be precise within the subject in question.
It’s like a dictionary with only one entry per word.
An ontology, organized into various groupings. There can be a variety of shapes to this organization, and different layers or perspectives. Abby provides [examples of a few shapes in her book](http://www.howtomakesenseofanymess.com/chapter/6/page/117/learn-these-patterns/):
* Hierarchy: relationships forming different levels or tiers
* Heterarchy: a group with only one level or tier
* Sequence: things that have an order
* Hypertext: a relationship that bridges separate taxonomies
Facets are the details about things that are used to form taxonomies. They are the attributes of interest, like the genre of a movie or manufacturer of a computer.
## Build IA with Your Software Product Team
To effectively build IA, it’s best if everyone on the team understands the concepts we just covered: ontology, taxonomy, and facets. Those are the things you’ll be trying to capture with your team.
Abby avoids specifics to keep her book broadly applicable, but I can share a few specifics from Atomic Object’s practices that help us build IA as a team.
#### Draw a business ecosystem.
During project kickoffs, we frequently [draw a business ecosystem diagram](https://spin.atomicobject.com/2011/08/29/drawing-your-business-ecosystem/) with our customer. This is an immensely useful way to kickstart a good ontology and taxonomy with broad participation. We always have great conversations and learn a lot from this activity.
Other collaborative activities and innovation games have worked well for us, too.
#### Listen to users.
We love having direct access to observe users and test with prototypes. Listening to the words people use is a good way to get a glimpse into their mental model of the domain. Pay attention to where they get confused and where they feel confident. Be willing to change.
We strongly prefer working together to working in isolation. Two heads are better than one when it comes to distilling and organizing information.
#### Put time into it.
Words are important. Really important. They form the basis for your ability to develop a shared understanding with your customers and the rest of your team. If you need more perspectives on why spending time on IA is justified, read [Abby’s “Selling Information Architecture” article](http://abbytheia.com/2014/08/07/selling-ia/).
Important things should have an appropriate amount of time spent on them. And good IA does require time–time spent thinking, discussing, diagramming on the whiteboard, and creating resources for sharing. So put in the time.
#### Hang it on the wall.
We like to keep project artifacts visible in our physical space. Diagrams of IA are great for quick reference as we’re doing design and development.
## Start Now
It’s never too late to start improving IA, and anyone can take that step. Build out a little dictionary to define terms; draw up a few diagrams to illustrate important relationships; talk about it. You might be surprised how much it helps the whole team.