A good language for critique

Garrett says we don’t have a good language for critique. So, what makes a good language for critique?

That word, “critique” is so pretentious. I picked it up: late high school or early college during what Jonathan Korman christened the “critical theory wars”.

I promise, we’ll try and abandon big tower words for good, dirt terms that really mean something.

Back in the 90s, I spent the critical theory wars at the University of Texas at Austin. My very first class on my very first day I met one of my very best professors. She was late to her own Intro to Criticism class, breezed through the door in a formal, crimson dress that was way too hot for Austin in August.

She began the class with a directive: when you read something, ask yourself:

• who is the author

• what did they say, and

• why did they say it?

Keep that in mind while I explain what I believe makes a good “language of critique”.

A good language for critique:

• Should not make assumptions about what is good or bad.

• It should focus on outcomes, not the design: but on the experience the IA enables.

• A good language of critique should apply to any information architecture in any environment.

• And, it should be as useful at your day-to-day job as it is at the academy discussing theory.

I still dislike that word, “critique”, but here, “critique” is the right word for right now.

When Garret says, “we don’t have a language of critique”, he means we don’t have the words for a disciplined, systematic study of information architecture.

That’s crazy, right? Thousands of words, phrases, articles, presentations, plenaries, and books about information architecture, but they’re not the right words.

Since that 2009 plenary, we’ve worked on it. We have heuristics, rules of thumb, general principles to generate “good” IA. And we have poetics: personal philosophies for principled IA. These prescribe what is good.

However, when Garrett talks about the “qualities of an information architecture”, he’s not talking about the quality.

The qualities of an information architecture are not what makes it good.

The qualities are characteristics and properties, and attributes that help us differentiate one information architecture from another.

And these properties and attributes should be:

1. Neutral, so they help us distinguish one information architecture from another, but not distinguish good from bad. They should describe what it is, not prescribe how to make it good.

2. These properties should be agnostic, so they apply to any environment where we work: whether it’s digital, physical, visual, aural, tactile, social, or something else.

3. They should focus on outcomes, so we understand the kind of experience the IA enables, rather than the design of the system, and

4. The language should be useful, so academics and practitioners speak the same language with clients as they do with each other.

***

Those four principles drove the design for the “language of critique” we’ll see here. So I wanted to lay these principles out front. If you disagree with these constraints, if you think they’re wrong, then you’re off the hook. Stop now. You won’t agree with what comes next. But, if these seem reasonable, maybe even useful, then now we have a way to evaluate our language of critique. We have a way to.evaluate the words we use when we talk about IA. And I propose we talk about IA in three ways:

1. We understand the scale of information architecture.

2. We describe how people experience the information architecture.

3. We map the differences between information architectures. How can we describe the information environment?

You can see: these three languages only describe information architecture, they don’t presume what makes it good. They apply to any environment, and they focus on outcomes rather than methods or activities.

With these three areas mapped, we can create a good “language of critique” for each one.

Next: Information architecture works at different scales