Selling Information Architecture
“Nobody gets a nervous breakdown or a heart attack from selling kerosene to gentle country folk from the back of a tanker in Somerset.” – Roald Dahl
I’ll be totally honest with you, the selling part of my job as an independent information architect still leaves my arm pits more moist than I would prefer. It is still the part of the process where I am most likely to feel my impostor syndrome flaring up and it is the only part of the process that I tend to procrastinate around. But fret as I might about selling, it is worth saying that it is a critical skill to develop whether you are a consultant, like I am, or selling your work within an organization, like I used to.
When I meet people at conferences and events, selling is often the biggest single question that they have for me.
It is a seemingly simple question that I have long flung around and been flung many a time. Having given it some time to simmer, I have some words of observation and advice to share.
As IAs have been known to do, I want to comment on one critical word of this piece. This word, while center to the content, almost didn’t make it into this piece: “Selling” In my opinion, IA is not something that needs to be sold. IA is already inherent to whatever someone is working on or has in place. If you are making something, you will be tackling the IA within and around it. With or without me you will “do IA.”
I guess in sales speak we could say “IA is included for free in all projects” — because a system without an information architecture does not exist. Rather than selling information architecture, I find that I do have to “explain” what it is and why it matters so that it can be worked on and improved upon (not ignored or inherited which is all too often the case)
Over the years I have developed language to explain IA that I use in certain contexts. It is important that we not only have one way of talking about something as important as our work.
How to explain information architecture…
“Information Architectures are structures that we use to make sure that the information people need is easy to find and to understand. So when you use a website, a mobile application or go into a store and you can find what you need and everything makes sense, that means the information architecture is doing its job.”
“Information Architecture is something you probably practice yourself everyday as a designer. When you decide the high level structure & flow that something will take and the basic labels and signposts that will be needed to guide your users through the experience, you are determining the information architecture. If you are working on a poster, the IA is all about deciding the read order and visual treatment of the content and prioritization of the elements. If you are designing a website, it is deciding what is accessible from each page and how each page connects to the others. If you are designing a product, it is deciding the features and functionality that you will provide and under what labels and signposts users will find what they are looking for”
“Information Architecture is similar to technical architecture. In technical architecture the goal is to make sure that all the technological pieces involved can understand each other and work together towards a shared result of delivering accurate and timely information to the end user. In information architecture the goal is to make sure that the end user also understands the intended meaning of the information that systems provide.”
“Your business already has an information architecture. The structures that you use to interact with your customer on your _______, _______ and _________ (insert the stuff they have in place today, digital and physical) — are all reflecting your company through the information and services you are able to provide. If your information and services are clear and easy to understand, customers are happier. If either your information or services are out of date, not accurate, cluttered, buried, impossible to find or written in language that only makes sense to people that work within your organization, customers feel under appreciated and/or confused. Ultimately I have seen too many companies that have information architectures that aren’t serving them.”
“Often when we are deeply familiar with the things that we are working on, we can’t see the opportunities for improvement that exist. When reviewing the information architectures that are in place, we can use a set of best practices as well as a wealth of user based research methods to really understand how people use your __________ and in what ways we can improve the structure of what is offered to better help you to reach your goals.”
“There is a lot of efficiency that can be gained if we are able to determine some of the high level structures up front. In the time that it takes to make one full design, we could iterate through several map variations. You can think of information architecture like the blueprints. We need a blueprint of what it is that we are building so that we all know what it is coming together like. If we don’t have the blueprint, we run the risk of building things that don’t fit together later.”
Once I have explained why IA is important, then I have to sell myself as a partner to work on their information architecture. The below represents how I approach that process and the rules I have for myself during the start of a relationship.
Make sure they understand why information architecture is important to think about before talking about what deliverables that may include and how it will all play out on a calendar. If you start with the what or how, prepare for pushback. In the case of IA, the whole is greater than the sum of the parts. So if you describe the parts before the whole is understood, the value can be lost almost entirely.
Show them What you do. Once they understand the “why”, you need something that shows them what you do. A portfolio, a process diagram, a case study, a puppet show, whatever makes sense
Don’t push your language on them. I try to educate my clients and partners while on the job but am careful about throwing new language around too early on. Better to get them to use their words to tell you what is wrong with their IA today. Words like taxonomy, controlled vocabulary, mental model and facets wait until we are a bit further into the working together part. They are all critical concepts, but are often best sold under layman or legacy terms.
Help them to make a diagram of the cross-channel structures that they have today and who they serve via each channel. This can be done on a piece of paper or a whiteboard. It doesn’t have to be fancy or even done ahead. In fact, part of the magic is doing it with them, for them. An act of kindness like this gives them a chance to see your skills and how you think about things. By making a map of their current structures and users, they will likely be able to tell you more about their hopes and fears for the future, and the more you hear about their hopes and fears for the future, the more likely it is that you can help them understand how you and IA can help to get them through this mess of theirs.
Call a spade a spade. If the thing you are being brought in to do is Information Architecture, but a bunch of it is also Interaction Design or Content Strategy — say so. Say the words for what you are doing. Just because you are trying to get more IA work or be known as an IA, doesn’t make Interaction Design work, IA. Put the words on the plan.
Make the myths we all live with end. Please, for the rest of us.
Know when you aren’t right for them, or they aren’t right for you. Then have the courage to say so. This is the hardest piece of advice on this list.
Thanks for reading.
