Last month, I bought a new book that was a primer on information architecture, based off of reading an excerpt that was published to the web. I even wrote a post about that excerpt, “Knowing is not enough.”
Here is my Goodreads book review:
How to Make Sense of Any Mess: Information Architecture for Everybody by Abby Covert
My rating: 3 of 5 stars
I wanted to like this more than I did. Several of her focus areas interested me, or inspired me, but her writing style and the organization of the book was a bit lacking.
Here are the passages that I highlighted, and my own thoughts on what she said:
- “Part of that [knowledge] includes agreeing on what things mean. That’s our subjective truth. And it takes courage to unravel our conflicts and assumptions to determine what’s actually true.”
To understand our messes, so that we can do something about our messes, we must have a common language, a common set of terms, but most importantly a common set of definitions and usage. I recently wrote about how information architects are often terminologists, which speaks to this point about agreeing on what things mean.
- “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.”
It was this very quote in an excerpt that made me buy her book, and which I already wrote a blog post about this quote.
- In the second chapter, State Your Intent, I highlighted several phrases that I’ll talk about together: (1) “The words we choose matter. They represent the ideas we want to bring in to the world.” (2) “…define what good means for our stakeholders and users.” (3) “Having a strong why will get you further.” (4) “What before how.” (5) “Why, what, and how are deeply interrelated.”
I’m always amazed at how the fundamental journalistic writing principle of “who, what, where, when, why and how” finds its way into so many other areas. I also love that Abby encourages IAs to define their terms (including what “good” means to everyone involved), and use those terms to define why something must be done, what specifically needs to be done, and all of that before you explain or start doing it.
- “As users, our context is the situation that we’re in….Our context is always unique to us and can’t be relied upon to hold steady.”
When architecting information, users are primary and context is a close second. This was a harsh reality to think about and come to grips with, about how unique or wavering a user’s context or environment is. Abby goes on to talk about how “channels” (which transmit information; which I think of as different media or ways in which to deliver information) can “work together to support a single context” or that a single channel “can also support multiple contexts.” Ultimately, because we are trying to coordinate or organize across users, their contexts, and channels, we end up with messes, both big and small.
- Abby spends a good bit of time talking about all the different diagrams and maps that you use to make sense of the messes, with scope, scale, and time all playing a roll in what you depict.
- “Everything connects to a larger whole. Whenever you’re making something, figure out which levels you’re working at…… Being able to zoom in and out as you work is the key to seeing how these levels affect one another.”
To be a good technical editor, you must be able to be both a substantive editor, looking at the big picture and considering how content fits into the whole, and a copy editor, looking at the individual sentences and words, making sure that it is all readable and understandable. To be a good information architect, you must be able to see both the forest and the trees, knowing exactly all the types of trees and foliage that is making up that forest. I loved this idea of zooming in and out and seeing how the levels affect one another. This is so true that you can’t focus on just one level, or you will end up with a mess of one kind or another.
- “When we decide that a word or concept holds a specific meaning in a specific context, we are practicing ontology.” (Wordnik definition of ontology.)
Again, here in Chapter 4, Choose a Direction, she returns to focus on the importance of terminology. She goes on to speak about controlled vocabularies (and eventually taxonomies). The worksheet that she provides breaks the terms down into “Words we say” (with the term, definition, and history of it), “Words we don’t say” (with the term, the reason why not, and the term to use instead), and “Requirements” (breaking them down into nouns and their associated verbs, since she believes that the nouns are created as a result of a verb). Later in Chapter 6, Play With Structure, she says this about taxonomies: “Taxonomies shape our experience at every level. We use taxonomies to make sense of everything from systems to objects.”
- Chapter 5, Measure the Distance, spends a great deal of time discussing setting goals and measuring against them. Among the many, many different types of measurements, she includes “kudos” as well as “complaints,” and other standard web stats or metrics.
- “Ambiguity costs clarity; exactitude costs flexibility.”
This speaks to the technical editor in me, who constantly balances the application of corporate standards, styles, and templates in the name of consistency and exactitude and yet going against those rules in the name of flexibility and hoping for greater clarity.
- “Taxonomy is one of the strongest tools of rhetoric we have.”
As a technical communicator, I received a strong foundation in rhetoric in my studies. Many technical communicators roll their eyes or do not believe that rhetoric plays a role in what we do. I wrote a separate blog post that describes how rhetoric informs all of our decisions.
- “Information architecture is like the frame and foundation of a building.” Also, “When your structure and your intent don’t line up, things fall apart.”
Every book on information architecture draws the analogy to architecture of buildings at some point. It is a good metaphor for describing what this field is all about. Noone wants the building to fall down, and so we work to try to set the frame and foundation by applying the principles of information architecture early and often.
- “Design with, not for.” This quote is actually in the middle of the book in Chapter 4, Choose a Direction, nestled in the discussion of ontology and controlled vocabulary. However, I think it makes a great summary for this blog post. The choice of preposition in this phrase highlights Abby’s focus on language and terminology throughout the process of information architecture. With is inclusive, and for is judgemental (or it is from my perspective). We must work with our users, with their contexts, and with all the knowledge. We need to put our hard hats on and hammer some of those nails, not stay in our suits reviewing reports and pictures of progress.