Selling Information Architecture
What’s in a name?
One of the most common concerns I hear from designers who are new to information architecture goes something like this:
I totally get how important semantic structures are to the success of my [ website | app | whatever ], but my [ boss | stakeholder | client | whatever ] just doesn’t get it. How can I convince [ him | her ] of the value of information architecture?
I start from the premise that you can’t convince anyone of anything. People are busy. They have incentives that are different from yours. They interpret persuasion as confrontation. Whatever the case, trying to convince people who are set in their views is often ineffective. What you can do is help them understand.
How does an information architect do this? As the man said, we create the structure or map of information which allows others to find their personal paths to knowledge. In other words, consider your speech act and subsequent dialog an exercise in information architecture. Approach it like you would a design project: with respect and understanding for both the person and the subject matter. Aim to create bridges between the two. Use language they’re comfortable with. Set boundaries.
This requires that you understand the person’s mental model. How do they see the role of design? How do they engage others in conversation? How open are they to new language? If they’re not open to new language, bombarding them at the beginning with challenging terms such as “taxonomy,” “ontology,” and even “information architecture” itself will be counter-productive.
Ultimately, what you’re trying to do is help them see the value of thinking through the system’s conceptual model and how it’s articulated through semantic structures — before they explore user interface directions. Whether they call this “information architecture,” “UX design,” or “whiteboard magic” is inconsequential at this point. What you want is to do the work, regardless of what it’s called. Engage people on their own terms. When they start seeing results you can ease them into the technical vocabulary.
This is not to diminish the value or importance of labels. Generative conversations call for using the right terms; efficiency requires that we call things by their proper names. You’ll arrive there eventually — but only if your interlocutors have first understood for themselves the value of the work.