What do we mean?

In my thesis class at SVA Products of Design this week, I talked to the students about ontology. Unlike lexicography, which is the collection of meanings, ontology is the designation of a specific meaning within a given context.

In other words:

What do we mean when we say what we say”

– Dan Klyn

• Facebook re-purposing the words “like” or “friends” for their purposes
• The hamburger icon navigation phenomenon flying around the mobile web
• The use of the floppy disk icon to mean “save” far past the use of floppy disks for storage of files
• The “folders” that are used to organize your “files” on a computer

These are all examples of ontological design decisions that impact not just our everyday life but our perception of the world that we live in and the places we spend our time.

At some point the makers of things looked at the potential and relative meanings for those images and terms and claimed or created a specific version for the context in which they interact with us, the users.

For each of the culturally excepted examples I state above there are thousands of examples (millions maybe) that people “just didn’t get.” It turns out that there are many complications and complexities involved in establishing meaning with the intent of it making sense to others.

As some brain food before sending my students to the park with their own ontological dilemmas I gave a short lecture on the lessons I have learned so far about dealing with the establishment of meaning.

The lessons we went over can be found in full in the deck, but in brief I explained to them:

• Taxonomy is a tool of rhetoric: meaning can be lost in the way something is organized just as easily as the way it is presented once found
• Every instance of poly hierarchy potentially reduces meaning: If everything is bold then nothing is, this goes for categorization as well
• Cultural meaning matters: What means something “here”, can mean something different “there”
• Pay attention to grade and reading level: We are not all graduate thesis art school students.
• Beware of homographs and accidental synonyms

In preparation for class I asked them to come prepared with a lexicon of terms that they intended to use in their thesis work and a list of words they intended to not use. They were then asked to exchange lexicons with another student, who was asked to point out any term within each definition that could be further defined, contested and/or unpacked to add more clarity or simplicity to their definitions.

Define the Damn Thing

– Christina Wodtke

Being someone who aims to never give advice I am not ready to take myself, I spent some time dissecting just one of the many definitions that Information Architecture has been walking around with for the last 10 years or so. Not surprisingly, I found a lot of complexity to unpack.

Information architecture (noun) is the structural design of shared information environments.

Structure (noun): the arrangement of and relationships between the parts or elements of a complex whole.

• Arrangement (noun): The order that is applied to the elements involved.
• Relationship (noun): the way in which two or more concepts, objects, or people are connected
• Element (noun): a part of something
• Complex (adjective): consisting of many different and connected parts

Design (verb): to plan something with a specific purpose or intention in mind

• Purpose (noun): the reason for which something is done
• Intention (noun): an aim or plan 

Information (noun): what is conveyed or represented by a particular arrangement or sequence of things

• Convey (verb): to make (an idea, impression, or feeling) known or understandable to someone
• Represent (verb): to state or point out something clearly
• Arrangement (noun): The order that is applied to the elements involved.
• Sequence (noun): a set of related events, movements, or things that follow each other in a particular order

Environments: the setting or conditions in which a particular activity is carried on

• Setting: the place where something is positioned or where an event takes place
• Activity: a thing that a person, system or group does or has done
• Condition (noun): the factors influencing the performance or the outcome of a process.
  • Performance (noun): the effectiveness of something when observed against a goal.
  • Outcome (noun): The way something turns out.
  • Process (noun): a series of actions or steps taken in order to achieve a particular end

Thoughts after this exercise:

• Not sure that non-shared information environments lack information architecture, so therefore the shared part may not be as important to the definition as it is currently. For example: my file system is just for me, yet it has information architecture.
• Weasel Words Alert: What ISNT an “information environment” based on this definition? What ISNT “information” based on this definition?
• Major Accidental Synonyms Alert (Architecture = Structure = Arrangement = Relationship = Sequence = Order)

New Proposed Definition of IA:

Information architecture (the thing): Any method of order applied to the pieces of something to make the whole more understandable to someone.

Examples of Information Architecture:

• The choice of information and distribution of hierarchical vs. hypertext relationships across a brand’s printed materials, website, mobile app and email campaigns
• The alphabetical and cross-referencing system used in a printed dictionary
• The alphabetical and cross-linking system used in an online dictionary app
• The choice of information, labels and display hierarchy of an airport display system
• The choice of information, labels and display hierarchy of a restaurant menu.

Information architecture (the practice): The practice of deciding the order in which the pieces of a whole should be arranged to uphold the integrity of the meaning that is intended by the maker.

Information Architect (the role): A person who works with the makers of things, providing expertise in the practice of Information Architecture.

Examples of “Doing Information Architecture”

• Producing a map of all the pieces of your project and how they should connect together
• Writing a list of words you use to write content, and words you will not use
• Deciding what sections and subsections will be important for making your <insert medium here>
• Working with your intended users to understand how they might organize the things you are presenting to them, and making recommendations based on trends in their mental models
• Changing the label or categorization of something because you recognize that people do not understand it or find it easily.

Wait? Isn’t that that same as _________________?

It turns out that when defined this simply, any designer worth their paycheck is already doing his or her own information architecture work or requesting that it be done by someone else. Many other job titles are producing information architecture too. Product Managers, Strategic Planners, Business Analysts and Project Managers are three common examples that I run into. To me (and many other practicing IAs) this is a “well duh” statement. To others this might be seen as heresy to state clearly.

I fully admit that most people doing IA today might not (and probably don’t) call these basic choices behind their designs: information architecture, but I can assure you that they are in fact “doing” information architecture.

They are carefully choosing what to show when, to whom and towards what end. More so, they are likely doing this AFTER the strategic “why are we doing this” part but BEFORE the more “designer-y” part.

There tends to be five worth-differentiating roles that one person can play on any given “design” project, but are sometimes designated across many people for one project:

• Researcher: Come up with the insights that assure that you aren’t wasting your time/money or anyone else’s.
• Strategist: Come up with the reason to believe in the thing that you are making and the steps you need to take to bring it to life.
• Architect: Come up with the list of pieces as well as the relationships that those pieces have to have to one another in order to make sense to the intended audience in the intended context.
• Designer: Come up with the detailed plans for an execution that brings your intent into the intended mediums
• Maker: Make it Happen

Under this new simpler definition of IA as it relates to the other pieces it affects it is harder to deny that we use, influence and create new information architectures everyday.

That time you decided to reorganize your closet to make it easier to get dressed for work, or reorganized your pantry to better maneuver packing lunches for your family each morning, the chore chart you made for your kids, or the time you combined records with your spouse and disagreed about whether to file Michael Jackson’s Thriller under “M” or “J” (ok, that was just me) or the last time you commented on how hard the subway map, bus map, city map, mall map, mobile app is to understand. These are all everyday examples of information architecture choices affecting our real lives.

Because there is a secret truth about information architecture: It never doesn’t exist. Whether you put it there or not, it is behind every designed thing, and therefore is behind almost every thing. Information is everywhere even where physical things are not.

Think about a product not being on a shelf that it normally is on. This arrangement could produce the information that this item is A) sold out B) popular C) both, depending on who is perceiving it.

This is about the time when I expect to get the tried and true “when you’re a hammer, everything looks like a nail” retort. In response to that I want to be clear that yes I am “a hammer” (and a damn good one) BUT I am not saying that you need an information architect in every design exercise out there.

I am however saying that if the makers of things knew more about the core concepts behind producing quality information architectures to work in real contexts, their work would only get better. Maybe it is too sunny of me but I can’t see how anyone would be worse off if they could identify information architecture problems separate from those of strategy, design or construction.

If they can see it they can be it

The best news is that learning IA isn’t like learning rocket science, it is based mostly in attention to detail, common sense, empathy and sense-making/inference skills that some people are really good at naturally.

Many things out there that we would describe succinctly as “bad design” actually have weak information architecture to thank for much (if not all) of the lack of clarity we feel when we interact with it. Yet more often than not, people lack the words to describe this part. What do you call something you like the look and idea of but fail to actually understand easily or fully?

It is said that in the mid-nineties, before the bubble burst and the tribes splintered, web designers called this phenomenon “the pain with no name” – and it was generally used to describe that all too familiar feeling that the makers of things feel when the users of things “just don’t get it.”

But for whatever reason, information architecture is one of those things that pretty much everyone hates to talk about, especially if talking about defining it to be further explored. Maybe that’s because it feels like it is everything and nothing all at the same time.

One approach to dealing with ambiguity is succumbing to it. To that end, I do hear the “it’s all design” retort used against further defining terms and job roles quite commonly. I can also agree that this is absolutely the easier way.

But taking the easier way forward means that under-defined, often-confused terms stay under-defined and often confused. As an Information Architect, I pride myself on making unclear things be more clear and in my experience this refusal to define the pieces of our work and their arrangements to each other and to the whole is leading to some pretty serious implications for our users:

• Businesses don’t know the words for what is wrong, missing or weak and therefore lack the ability to find a way past it.
• Teams don’t know “who does what and how” when it comes to the construction of places made of information. When no one owns the IA it can grow naturally from the pieces, you can imagine the mess this becomes when time is added. And contrary to popular belief, this isn’t just a digital issue. I recently did some work with a restaurant chain’s print menu that proved to me the similarity in the complexities of the print medium. The designers and strategists were more than thankful to have someone to figure out “the architecture part” as they had their hands full with “the design part”
• Students report feeling overwhelmed and confused with the multitude of expertise that are needed to master the “it’s all design” goal post and the junior jobs that are listed against those expectations.
• Communities that were formed around general likeminded-ness are starting to splinter and argue in reaction to the market’s need for us to stake claim to team members, projects and methodologies.

I know this isn’t the first “define the damn thing” post and it wont be the last. I know we have a lot of work to do to make this be clear. Many have tried to walk down this path before and turned back because it is more than clear that this is not the easier way.

If you already have love for this thing called information architecture I hope to hear your thoughts. If you are new to these words, I am quite eager to hear how clear these thoughts are from the outside.

Thanks for reading.