Definition: Someone with a viable and legitimate interest in the work that you’re doing.
Also referenced as: Stakeholders (noun)
Related to: Agreement, Assumption, Bias, Direction, Factor, History, Intent, Meaning, Mental Model, Perception, Player, Requirement, Subjective, User, Worksheet
Stakeholders are complex.
A stakeholder is someone who has a viable and legitimate interest in the work you’re doing. Our stakeholders can be partners in business, life, or both.
Managers, clients, coworkers, spouses, family members, and peers are common stakeholders.
Sometimes we choose our stakeholders; other times, we don’t have that luxury. Either way, understanding our stakeholders is crucial to our success. When we work against each other, progress comes to a halt.
Working together is difficult when stakeholders see the world differently than we do.
But we should expect opinions and personal preferences to affect our progress. It’s only human to consider options and alternatives when we’re faced with decisions.
Most of the time, there is no right or wrong way to make sense of a mess. Instead, there are many ways to choose from. Sometimes we have to be the one without opinions and preferences so we can weigh all the options and find the best way forward for everyone involved.
Carl is a design student getting ready to graduate. But first, he has to produce a book explaining his design work and deliver a ten-minute presentation.
While Carl is a talented designer, public speaking makes him queasy and he doesn’t consider himself much of a writer. He has drawers and boxes full of notes, scribbles, sketches, magazine clippings, quotes, and prototypes.
Carl has the pieces he needs to make his book and presentation come to life. He also has a momentum-killing fear of the mess he’s facing.
To help Carl identify his mess, we could start by asking questions about its edges and depths:
It’s your turn.
This chapter outlines why it’s important to identify the edges and depths of a mess, so you can lessen your anxiety and make progress.
I also introduced the need to look further than what is true, and pay attention to how users and stakeholders interpretlanguage, data, and content.
To start to identify the mess you’re facing, work through these questions:
Good is in the eye of the beholder.
What’s good for a business of seven years may not work for a business of seven weeks. What works for one person may be destructive for another.
When we don’t define what good means for our stakeholders and users, we aren’t using language to our advantage. Without a clear understanding of what is good, bad can come out of nowhere.
And while you have to define what good means to create good information architecture, it’s not just the architecture part that needs this kind of focus.
Every decision you make should support what you’ve defined as good: from the words you choose to the tasks you enable, and everything in between.
When you’re making decisions, balance what your stakeholders and users expect of you, along with what they believe to be good.
The meaning we intend to communicate doesn’t matter if it makes no sense, or the wrong sense, to the people we want to reach.
We need to consider our intended users. Sometimes they’re our customers or the public. Often times, they’re also stakeholders, colleagues, employees, partners, superiors, or clients. These are the people who use our process.
To determine who matters, ask these questions:
- Who’s most important to get agreement from?
- Who’s most important to serve?
- What words might make them defensive?
- What words might put them at ease?
- How open are they to change?
- How will this affect their lives?
- How does the current state of things look to them? Is that good or bad?
Reality involves many players.
As you go through the mess, you’ll encounter several types of players:
- Current users: People who interact with whatever you’re making.
- Potential users: People you hope to reach.
- Stakeholders: People who care about the outcome of what you’re making.
- Competitors: People who share your current or potential users.
- Distractors: People that could take attention away from your intent.
You may play several of these roles yourself. Be aware of potential conflicts there.
For example, if you believe your users are like you but they’re not, there’s more room for incorrect assumptions and miscommunications.
Keep it tidy.
If people judge books by their covers, they judge diagrams by their tidiness.
People use aesthetic cues to determine how legitimate, trustworthy, and useful information is. Your job is to produce a tidy representation of what you’re trying to convey without designing it too much or polishing it too early in the process.
As you make your diagram, keep your stakeholders in mind. Will they understand it? Will anything distract them? Crooked lines, misspellings, and styling mistakes lead people astray. Be careful not to add another layer of confusion to the mess.
Make it easy to make changes so you can take in feedback quickly and keep the conversation going, rather than defending or explaining the diagram.
Your diagram ultimately needs to be tidy enough for stakeholders to understand and comment on it, while being flexible enough to update.
Opinions are like…
No matter how hard we try to be aware of opinions swirling around us, it’s hard to remain neutral. But in the end, progress can’t happen without a decision.
When you’re choosing a direction, you may run into these questions:
- What if I disagree with a user need or opinion identified in my research?
- What if I disagree with the way another stakeholder sees a core concept or decision?
- What if I don’t want to do this the way others want me to?
Some people choose to hide from the realities behind these questions. But if you shield your ideas and simply follow orders, you may end up with goal-crushing (and soul-crushing) results.
We have to balance what we know with what we see and what other people say.
We listen to our users and our guts. There is no one right way. There is only your way.
Control your vocabulary.
Are you facing a mess like Rasheed’s? Do your stakeholders speak the same language? Do you collectively speak the same language as your users? What language might be troublesome in the context of what you are doing? What concepts need to be better understood or defined?
To control your vocabulary:
These levels deeply affect one another.
Once you know what level you’re working at, you can zoom in to the appropriate level of detail. Sometimes we need to zoom all the way in on an object. Other times it’s more important to zoom out to look at the ecosystem. Being able to zoom in and out as you work is the key to seeing how these levels affect one another.
When you’re deep in the details, it’s easy to forget your broad effect. When you’re working overhead, it’s easy to forget how your decisions affect things down on the ground. Making changes at one level without considering the affects they have on other levels can lead to friction and dissatisfaction between our users, our stakeholders, and us. One tiny change can spark a thousand disruptions.
For example, if we owned a restaurant and decided to eliminate paper napkins to be environmentally friendly, that would impact the entire restaurant, not just the table service our diners experience.
We’d need to consider other factors like where dirty napkins go, how we collect them, how often they’re picked up and cleaned, how many napkins we need on hand between cleanings, and if we should use paper napkins if something spills in the dining room.
One tiny decision leads to another, and another.
I once had a project where the word “asset” was defined three different ways across five teams.
I once spent three days defining the word “customer”.
I once defined and documented over a hundred acronyms in the first week of a project for a large company, only to find 30 more the next week.
I wish I could say that I’m exaggerating or that any of this effort was unnecessary. Nope. Needed.
Language is complex. But language is also fundamental to understanding the direction we choose. Language is how we tell other people what we want, what we expect of them, and what we hope to accomplish together.
Without language, we can’t collaborate.
Unfortunately, it’s far too easy to declare a direction in language that doesn’t make sense to those it needs to support: users, stakeholders, or both.
When we don’t share a language with our users and our stakeholders, we have to work that much harder to communicate clearly.
Design with, not for.
It’s important to discuss and vet your ontological decisions with stakeholders and users. Talking about language choices gives you a chance to test them.
It may sound obvious, but it’s quite common to think something is clearly defined before talking about it with other people.
A good starting point in exploring ontology is to bring everyone together to make a list of terms and concepts. Ask each person to share:
Go through each term as a group and use this as a forum for educating each other on what you know about language and context. Don’t “uh huh” your way through words you’ve never heard or don’t understand. Instead, untangle acronyms and unfamiliar phrases.
If someone uses a different word than you do, ask for clarification. Why do they use that word? Get them to explain it. Complexity tends to hide in minutiae.
Create a list of words you don’t say.
A controlled vocabulary doesn’t have to end with terms you intend to use. Go deeper by defining terms and concepts that misalign with your intent.
For the sake of clarity, you can also define:
In my experience, a list of things you don’t say can be even more powerful than a list of things you do. I’ve been known to wear a whistle and blow it in meetings when someone uses a term from the don’t list.
Use worksheets to mine data from people.
Once you have a list of indicators to guide you, think about where the data could come from.
A worksheet can help you capture important details that only exist in people’s heads or personal records.
You can fill out a worksheet in a meeting or distribute copies of it and collect them after people have time to answer your questions. To choose the best way to gather the data, keep these considerations in mind:
- Time: How much are you asking for, and how long might it take?
- Access: How many sources are your respondents using to find answers? Who else might they need to contact?
- Bias: Are they applying their own thoughts and preferences, or delivering data?
If your users or stakeholders need a significant amount of time, access, or thought to answer your questions, let them get back to you instead of trying to get through the worksheet together.
Joan is the social media coordinator for an airline that recently merged with another airline. Overnight, her team became responsible for twice as much work as before. She’s also now responsible for managing twice as many people.
As the details of the merger iron out, duplicative channels have to be dealt with. For example, they now have two Twitter accounts and two help directories on two different websites. To tie everything together, Joan:
It’s easy to reach agreement alone.
Maybe you’re working on a project independently and you’re the only stakeholder and user.
More likely, you’re working with other people to serve other people. In that scenario, making maps and diagrams alone at your desk is not practicing information architecture.
Your whole team should be able to influence and react to your tools and methods. You should be making prototypes to get feedback from users on language and structure.
Getting everyone involved early is crucial. Every step you take should come from the direction you choose together. If you don’t get agreement up front, prepare for more work later.
When you see the world through the eyes of other people, you can spot weaknesses and opportunities for improvement. Don’t hide from other stakeholders or wait until the end of the project to talk to users.
We serve many masters.
No matter what the mess is made of, we have many masters, versions of reality, and needs to serve. Information is full of history and preconceptions.
Stakeholders need to:
Users need to:
It’s our job to uncover subjective reality.
An important part of that is identifying the differences between what stakeholders think users need and what users think they need for themselves.