How to Set IA Up to Fail

When we started World IA Day we hoped it would ignite a worldwide conversation about information architecture. With 58 locations in 28 countries this year, I could not be more proud of the results. Watching communities like the one here in DC come together around information architecture each year makes me proud to be a part of this community.

I want to thank all the local organizers around the world for bringing this event into your community. You are bringing information architecture to people who need it at an affordable cost in an accessible location — and for that I hope you all are proud of yourselves.

This year, our theme is Information Strategy & Structure. I personally love this theme because it means we are moving forward having completed our initial mission to spread knowledge of information architecture to as many people and contexts as possible. This year’s theme is all about getting down to brass tacks, taking that IA knowledge and actually infusing it into the organizations we work with and for.

As a community leader this is exciting, but as a teacher and public speaker on this subject, this theme is also anxiety inducing. Because unlike the education about what IA is, this is the hard part. The part that gets murky pretty quick. So today I am here to talk to you about failure. Specifically what does it look like to fail at integrating IA into an organization. I wanted to tackle this subject because knowing is not the same as doing. We now have a worldwide community that knows about information architecture, it’s time to make sure they are setup to succeed at practicing IA in their unique context.

When I proposed this talk, I was working as an independent consultant providing IA advice to organizations. The idea behind this talk was the provide advice for organizations like the ones I have been consulting for. But as I wrote this talk, I was also pondering and later confirming a pretty major career change. As of January, I accepted a full time position bringing information architecture thinking to Etsy.

All of a sudden, I was my user. All the uncertainty I had heard about from those I worked for was my uncertainty. When I was considering taking this job, the major reason that pushed me over the edge into accepting was the uncertainty that came along with it. I was certain I could give organizations useful advice to get to the next level of IA thinking, but I never had to stick around and deal with the day to day of it all.

So what started as advice I wanted to share with others, turned into a letter to my future self. I had gotten to a place I feel a lot of us get to. We commit time towards convincing our organization to understand the impact of information architecture. We fight for the teams we work with to think about information architecture in their process. And then we reach this moment, this cliff after which it all becomes less clear: The Now What?

This is the moment when you think to yourself:

“I taught everyone around me what IA is in theory, now I have to show them what it means in practice”

If you are one of the brave souls that has started to scratch past the surface of theory, into the realm of practice the following will feel familiar to you.

TheoryPractice

A controlled vocabulary increases clarity and efficiency within an organizationOur organization has a language that has been created organically over time and is full of messes of both the human and systems kind

A taxonomy is best considered from the mental model of a user and the intention we have setWe already have (many!) taxonomies in place and while they aren’t aligned to what we now know about our users, they are what our users are used to

A good information architecture has a place for everything and rules for why we put those things where they areThings change, organizations merge, new markets emerge, intentions shift, shit happens

With all these roadblocks on our journey, we can take missteps. I have seen many companies get to the critical crossroads of theory and practice only to start going backwards. They recognize the theoretical power of information architecture but relegate it to the realm of “in a perfect world” — this isn’t just dangerous for the field of information architecture, this is something that impacts all industries, jobs and sectors. As a member of this community I think it is important to say this out loud: It is no longer enough for people to know what information architecture is. It is time for our community to dedicate itself to seeing through on our promises of making the world a clearer place to live and work.

All I can do from this podium is try to use my words to incite action, the rest is up to each of you. Whether you are an information architect by title or not, I hope that this talk speaks to the struggles you will face as you take your organization from theoretical knowledge of information architecture to practicing IA in an ongoing, sustainable way.

5 Common Missteps when Implementing IA into Practice

I have spent some time collecting and analyzing the missteps that organizations take when moving from theory to practice of information architecture. I have identified 5 anti patterns so far.

#1 Be afraid to talk about language

Let’s face it, talking about language is scary. Our language most accurately reflects the way we view the world, so having to explain ourselves or being challenged by conflicting viewpoints is one of the hardest parts of being human.

Because of the anxiety that is built in, I see teams and organizations shy away from talking about language. They allow everyone to have their own way of saying things, labeling things and communicating things.

I can tell you from experience, that this is fine but only to a certain point. Disagreements about language tend to be like barnacles on ships.

• They are unavoidable.
• They don’t start to slow down your ship until they reach a critical mass.
• The bigger the ship, the more barnacles
• The smaller the ship, the fewer barnacles are needed to slow you down

If you avoid talking about the disagreements you have around language, the scaffolding on which you stand as you construct your IA will always be wobbly. Without fearlessly tackling this, the people in your organization may discredit (or even worse undo) the work you do because you have failed to change the way they see the world.

I know that sounds big and philosophical (and more than a tad bit political) — but I mean it to. I started with this anti pattern because it is the #1 issue I see within organizations. I see group dynamics, power dynamics and struggles of motivation and intention all laid out in one critical failure: Not knowing what we mean when we say what we say.

Language seems like such a large topic to tackle, that it can end up on the perpetual “We’ll get to it later” list — but by being afraid of talking about language, organizations are setting themselves up to fail.

#2: Don’t open cans of worms

The second misstep pays homage to the single thing you can say to really get my blood boiling: “Oh we don’t want to open up that can of worms”

WHY NOT? Perhaps that can of worms needs to be opened now, lest it haunt us months or even years from now. Shying away from understanding complexity is the surest way to allow it to complexify.

Mess + Time = Messier

I often have to remind my clients and colleagues that the messes we have today will only get messier if given time. When we put off exploring or understanding the complexities we face, we are doing a massive disservice to our future selves.

I have seen data architects break down because a can of worms gets opened and forever alters their way to thinking about a problem. I have see design teams have to throw away weeks of work because a can of worms was opened too late. I have seen critical business application projects get scrapped because cans of worms were ignored until revealed in user acceptance testing.

Here is what I have learned about cans of worms:

• It is always impactful to open them
• The later in the process you are, the more impactful it becomes
• If you open them earlier, you throw out less work

When organizations shy away from complexity, they create risk, uncertainty and a much less happy and stable future. We can create entire visions that are deluded by our lack of knowledge about the truth. As a teacher, opening cans of worms is the hardest lesson to impart on my students. Especially when they come in fairly junior in an organization and those above them are the ones avoiding the complexity. No matter what level you are at it is hard to be the one who calls out that a level of complexity isn’t being explored, but when no one does, it will come back to haunt the whole team.

#3 Think change will happen over night

The third anti pattern is about time. On my very first day at Etsy I ran into someone who I had met during my time consulting for them.

They joked with me:

“Oh great! We hired you, so it’s all fixed now right?”

While this was a joke, this statement reminded me about the power of selling people the theory of IA. Once people understand what IA is and how important it is in terms of their ability to achieve their intention, they want it and they want it NOW.

As someone in the driver’s seat, this can feel daunting. If it took this organization years to get the IA that they have in place, how can I personally uproot it and fix it in the length of a project? The truth is I can’t and neither can you.

Even more so, if we could, doing so might be irresponsible. You can’t often just level a whole organization and start from the ground up. Business can’t just cease to function while you think through ways to improve an IA. This is where we differ significantly from those working in physical architecture. When was the last time you heard about a major renovation of physical space where all the inhabitants and furnishings would stay put as the renovations occurred?

In my experience, one of the worst things you can do is make major renovations to your IA without consideration for how it will be rolled out and communicated to users. It can be very exciting to launch a major improvement, but when users are used to something (however flawed) it is sometimes better to slow your roll-out.

When we do major renovations to an information architecture, we are working within what exists while inventing what will exist. It is work that is best done with a sensitivity to the short term while working out the long term. When organizations expect that the mere existence of an information architect will be like a magic wand, they are setting that person up to fail.

#4 Aim for perfection instead of progress

Sometimes the problem can seem so big it will never get solved. Sometimes the steps to take to get there are so numerous that the gantt chart can no longer fit on a presentation slide. When this happens it is hard to even start. When we have spent the time to define what ideal looks like it is hard to start over in terms of taking the steps to actually get us there.

This is why I try to encourage progress over perfection. Because in reality, things will change as you take the steps towards your vision and then the subsequent steps will have to change as well. For the perfectionist in me, this is painful to live through but is also a reality of any project you take on, IA or otherwise.

It’s kind of a Catch-22: When we start something, we need a vision and a set intention. But as we move towards that vision our intentions might change, which in turn change our vision. For a strategic function like IA this is a hard fought reality to deal with. If your job is to define the vision, but the thing you create at the end never looks like how you defined it in at the onset, what’s the point? This reality keeps many organizations from ever creating a vision at all. But maybe worse than that it keeps organizations that have created a vision from taking steps forward – because they can’t see a world where perfection will ever be possible. So they throw the baby out with the bathwater.

#5 Fix it, then forget it

The last pattern only reveals itself in the lucky few who have battled all the others. Let’s say you actually do work to dramatically improve your information architecture. And for one beautiful day, week, month or maybe even year everything is clear and has a place where people can find it and understand it. You have ironed out all the creases, you have a system that makes sense. Congratulations, you can now start your real job: keeping it up.

Have you ever spent a whole day or weekend cleaning and reorganizing your home only to have it all undone just a few days or weeks later? Yeah, we have all experienced this kind of backslide. It’s normal.

This is because in reality, systems are in constant flux. When we think our IA is a set it once and forget it activity, we will end up with a messy system again. It’s as simple and heartbreaking as that. When organizations make IA a project with a due date, after which it is considered done, you can set an alarm clock for when they will wake up to a messy system down the road.

Tips to move from IA theory to practice

In order to avoid these missteps let’s counteract each with the checklist of things you should be doing instead.

#1 Talk about language as a shared asset

It is very tempting when bringing IA into an organization to try to own language. But when the thing you are trying to own comes out of people’s mouths, gets typed into everything from lines of code to marketing copy to interface elements, attempting to have someone or a group of someones owning language will become impossible.

Instead I recommend you talk about language as the single shared asset that your organization has. Everyone uses language in their work and therefore everyone needs to take part in making major renovations to the language of an organization.

I know that in most organizations, getting everyone involved is not ideal or even possible. What I recommend instead is to build a cross functional team that cares deeply about language. This team should represent all the different groups or types of roles within your organization.

Do you have safety captains at your workplace? You know, the people in charge of directing their co workers in the event of an emergency. I like to think about members of this language team like that.

• They hold the knowledge that is needed to direct people when they are unsure where to go or what to do when it comes to making linguistic decisions.
• They are the people who point out when something language-wise feels wrong based on the intention that the organization has set out to work towards.
• They communicate changes to language to people who work most closely with them.
• They are responsible for representing their domain of expertise when discussions about language take place
• They bring issues up the chain to the larger language team

By creating a collaborative team to talk about language within your organization, you invite open communication lines throughout all levels and roles. In my experience this is an exercise that brings a lot of clarity to how language is actually being thought of throughout the organization. As an IA, organizing groups like this helps me to better understanding with my colleagues around why things are the way they are and the impact of making sweeping changes (both negative and positive)

#2 Help Others Embrace Complexity

I suspect that in a room full of people who gave up their Saturday to attend an event like World IA Day there aren’t too many of you who shy away from complexity. That said, I think it is our job to spread our ability to embrace complexity to those we work with. As people who can make unclear things be clear, we have a super power that can help others feel more secure in their role and more able to meet their goals.

How do we do that? By being the ones who are unafraid to open the cans of worms. When things are complex, people avoid them.

We can start to swirl through the list of common excuses:

• We don’t have time for that right now
• We don’t have the right people in the room
• We don’t know how the world is going to change around this matter
• We don’t see an obvious solution, so why try

The problem with allowing these excuses to get in the way is that complex things always look way scarier in our heads — and with each of us in our own heads there are actually many different versions of this monster we all face.

By being the one who embraces complexity we can start to wrangle those monsters into a single version that everyone can see and agree on. Through the process of doing so, we start to realize that we now outnumber it and our team starts to feel more sure of our collective ability to take it on.

Someone recently said to me “it is your job to make the overwhelming, whelming.” — and while whelming might not be the most glamorous of goals it is something people need. Something we feel we can actually take on even if it will be hard and take time.

#3 Take the time and space needed

When we finally get the right people in the room and have permission to unravel some tangled web, it is easy to attempt to finish the sensemaking part really quickly. When we do this, we are doing ourselves and our organization a disservice. We end up mapping things in an overly simplified way or in a way that is only reflective of the people who were involved.

Sometimes the thing we are trying to figure out takes more than a single workshop to work out. That’s ok. That’s good actually. We have to remember that in the practice of IA our brains are churning through other people’s intentions, processes and historical accounts. This is delicate thought-based work.

At the end of a day full of workshops it is common that your body is on empty and your brain is on full. This isn’t a great time to make decisions or recommendations. Instead this is a good time to stop and let your brain take a break.

I see way too many people trying to cram a whole month’s worth of thought work into a two day workshop because of the pressures to Get Things Done. But if you end up getting the wrong things done, does it actually matter?

Even worse than exhausting yourself, this is the surest way to prove to people that this whole IA thing is a waste of time. So lobby for the time and space you need to actually explore the areas you need to explore.

One exercise I recommend highly is to spend 30 minutes individually with every person you will be workshopping with. I generally do this the week before the workshopping part starts. By doing this you are priming your brain to their personality and viewpoints. It allows your brain to gently warm up to the subjects that will be discussed instead of running full steam ahead in front of a cold audience.

#4 Prepare to Govern

The last tip I have for you is the single most important because no matter how good you are: Things will change. People will come and go in your organization, groups will restructure, technologies, trends and methodologies will emerge while others will fade into oblivion. Just as you think you have your arms wrapped around something, that thing will get bigger.

Governance is not the most glamorous part of doing IA work, but it is the most critical. Because without it you will eventually look up and realize all that hard work you did has been undone.

I won’t stand up here and pretend that governance is easy, it is not. But it is easier than starting all over again down the road.

Here is a short list of what I think you need to govern:

• A governance committee : A cross functional group of people who are willing to discuss language and structure on an ongoing basis to assure adherence and flexibility in equal measure.
• A plan for succession of group members: People will move on and off this team, so you need a plan by which members are replaced as well as procedures for how they are on-boarded
• A cadence of committee meetings: In order to get people engaged, you need a standard time that they know they will commit to this activity. If you leave this as an ad-hoc meeting to be used when needed, you won’t end up with the level of engagement that is necessary for real governance work to get done
• A source of truth: You need to establish a place where the truth is documented and kept up to date when things change. This is an important piece because no matter how smart members of your team are – keeping all this information in their heads alone will lead to inconsistencies and variations over time.
• A process for change: A documented Set of steps the group will take when identifying potential needs for change AND implementation of that change.

I will not espouse a single methodology or tool that will work for each of these things, because there isn’t one. Each organization is going to have unique needs and therefore make each of these choices differently.

BUT I will give you some tips I have learned over time:

• Committee meetings should not be short in length, the discussions that are had here are best described by a recent client of mine as “brain melting” — I suggest you aim for at least 90 min every month
• Your committee should be incentivized to be part of this, that means it can’t be a labor of love. Their managers need to know this is a part of their job and respect that, otherwise it will always fall off the back of their to-do list.
• The source of truth should be a place people at your organization already frequent. If you use something that requires yet another login or install, good luck on getting anyone to use it

With these guidelines and ideas, I hope you can start to think about what it would mean to govern your organization’s information architecture. I will warn you, it will be slow going to get into the groove of doing this kind of work. But I can also tell you that in the organizations I have helped with governance, the team members who are involved often find this work incredibly rewarding. Don’t be surprised if you start growing information architect wannabes in the ranks.

The most powerful part of governance is getting the whole organization bought into the idea of working together towards a more clear future. When you start hearing things like “we should check the lexicon of approved terms before we name that” or “maybe we should ask the language team to review this before it goes out” – you will know you are doing the job right.

To close out my time with you today, I want to review the checklist of dos and don’ts I have proposed today.

• DON’T be afraid to talk about language
• DON’T ignore cans of worms
• DON’T expect change overnight
• DON’T aim for perfection
• DON’T fix it and forget it

Instead:

• Talk about Language as a Shared Asset
• Help Others Embrace Complexity
• Take the Time & Space Needed
• Prepare to Govern

For those of you who are new to IA, I hope you are starting to understand the depths that have to be dealt with in order to do this work in reality. For those of you in a similar place to me, my hope is that with this advice you can move information architecture from theory to practice in your organization. I know I will need to refer to this list as I embark on my journey from external consultant to internal team member. The journey I have ahead of me is excited and terrifying, but I wouldn’t be doing this if it was any other way.

I want to leave you with a final thought best summed up by a quote whose authorship has been argued about for decades:

“In theory there is no difference between theory and practice. In practice there is.”