In a previous post about all the interesting things that can derail a UX project, I covered the biggest things that can go catastrophically wrong.

But there was something I missed, because it only causes real problems on a certain type of project.

For the want of a project taxonomy..

There is something that can happen on large-scale, multi-team projects that can result in a team failing to deliver against stakeholder expectations, or at least make the entire process a lot more painful and frustrating than it has to be.

And it is this —

When a project reaches a level of complexity, either in scope and scale, systems and products, numbers of teams and stakeholders, or even all of the above, everyone will start calling things by different names — often meaning different things.

This is where you need a project taxonomy.

Using your IA skills on your own project

A taxonomy, just as with any IA work, is about how you name things and how they relate to each other. So on a project with multiple teams and stakeholders, you need to all be aligned on what you all call things and how they relate to each other.

Essentially this is a case of UX’ing your own project.

Your project is in itself an experience that contains people, processes, products and content. In the same way that you define the architecture of your product, you can also do it for your project.

And the more people, teams, processes, platforms, systems, departments and deliverables you have in your project, the more complicated life is going to be if you don’t all refer to the same things by the same terms.

How do I know I need one?

You can tell when a project needs a shared taxonomy, because you’ll be in meetings or conversations where people spend a lot of time saying:

“So our users…”

“You mean members..?”

“That’s like subscribers, right?”

“What’s the difference again?”

No one wants to spend several months on a project where 25% of each meeting or workshop sounds like this.

Give me an example

Let’s imagine you are working on a SaaS product.

How do you refer to your users?

You’ve got users who subscribe to the service, different tiers such as premium members, corporate/enterprise members, CMS users, support engineers and more. All of these are “users” of some part of the product or service.

So in a meeting, when someone says “subscribers” — who do they mean?

When someone says “users” — who do they mean?

When someone says “members” — who do they mean?

And what is the thing they are using?

Well it’s Software as a Service — so they are using a service, right? Or is it software? How is it delivered? Is it a website? An app? Both? Which of these is the “service”?

Now have a couple of meetings with stakeholders from different teams about how you’re going to redesign something.

Exactly.

The only way out of this is to actually define the terms everyone is using, structure it in such a way that everyone can see the hierarchy of how those terms relate to each other, and document it in such a way that it is used.

I know, this sounds slightly tedious (unless you’re an IA or a BA in which case you will LOVE this). But believe me, you are going to be really grateful you spent time doing this. OR you’ll find you have to come back and do this half way through requirements gathering.

Simple steps to a project taxonomy

To solve this problem you need to do three things:

1. Write the project glossary
2. Create the project taxonomy
3. Use it.

What is a project glossary?

This is a simple as it sounds — it’s a list of the terms usually used on a project to describe, well, anything.

It’s how you refer to end users, stakeholders, departments, products, services and systems.

TOP TIP: Your standard glossary is alphabetical, but for UX projects I would recommend grouping similar subject words together, and even starting to nest the hierarchy if possible, so that you are set with a hypothesis for creating your taxonomy.

An example partial project glossary, for our imaginary SaaS project:

• Customer — a person or company which pays for access to the product/service
• User — any human agent of a product
• CMS — content management system — internal facing only
• CMS User — any human agent of the CMS
• Subscribers — any human agent of the CMS
• Account owner — any business entity subscribing to a product
• Software — all digital products, platforms and codebases that deliver the service
• Product.com — the online website platform that delivers the service
• Product app — the native web platform that delivers the service
• Service — everything delivered by the business to the customer on any channel

And so on…

What is a project taxonomy?

The project taxonomy is how those terms (defined in the glossary) relate to each other.

To draw a parallel with the kind of IA work you might be doing in your UX life, If glossary terms are pieces of content, then taxonomy is your sitemap that holds it together.

Note: these examples are extremely generic and for illustrative purposes only. I would expect a project-specific taxonomy to address the terms used by the actual company and project team.

How to extract and document a project taxonomy

Creating a project taxonomy is not as complex as it sounds, and can be created without hundreds of meetings.

The first part can even be done by a single UX designer, as part of the project’s discovery and requirements gathering phases.

1. Audit all existing documentation — just as you would at the beginning of any discovery phase, as you are going through any existing documentation, make a note of any/all terms that are used
2. Stakeholder interviews — again, part of the standard discovery phase, but as well as using these interviews to write initial requirements, you’re going to take note of the terms used by different stakeholders and what they mean in context. Here you will also pick up on any political situations, areas of conflict and terms that derail meetings!
3. Write the initial glossary of terms — You can do this yourself based on 1&2 above. This is just a list of the terms used, and what you understand them to mean. Highlight any terms you don’t understand or conflicts where the same term is used by different teams/stakeholders to mean different things
4. Run a session — Gather your stakeholders, and include any BA, technical/systems or supplier teams you can. Take them through the glossary, agree or amend your definitions. Use a tool like Miro to affinity map terms and note any hierarchies or nested terms. Note: if this needs two sessions, do it. Let stakeholders argue it out until they are in agreement but ensure that your facilitation skills allow you to be firm in closing down each term’s definition. The last thing you want is to spend 2 hours in workshops and still not have clarity
5. Write everything up — Write up your final glossary, and map the taxonomy in such a way that it communicates meaning and hierarchy. There is no “right” way to do this — it just needs to make sense to the team
6. Keep and communicate — These documents should be kept in the primary requirements or project documentation (for example Confluence or other central portal). All teams should be referring to it, all new teams or team members should be taken through it as part of their onboarding
7. If it changes, change it — Over time new terms arrive, or meanings change. In this case change the documentation, and communicate the changes to wider team.

What are the benefits

We can imagine the challenges of not using the same terms across multiple teams over months long projects, but what are the specific benefits — and how can we justify this time to stakeholders?

Here are some of the positive outcomes which make this exercise worthwhile on complex projects:

• It makes meetings more efficient —if everyone is speaking the same language, and you’re not spending time clarifying what someone means, meetings should be quicker, clearer and more effective in achieving outcomes.
• Easier to brief new team members and partners/suppliers — anyone new coming onto a complex project often has a massive learning curve. The taxonomy provides a map or blueprint to help them navigate discussions and documentation from day 1.
• Consistent easy to understand documentation — if all documents from all parties use the same terms, it will be much easier to follow project decisions and planning
• Identifying danger zones — on every large project there are words and phrases that derail discussions due to internal politics, sensitivities, failed previous projects and more. No one wants to lose 30 minutes of a meeting because someone dropped a word bomb.
• Easier to engage senior stakeholders — knowing senior stakeholders preferred terminology for certain areas of a project can increase comfort levels and make decision-making easier.
• Reduced margin for error — and this is the big one. If everyone understands the same terms, then everyone is working towards the same goals. It is therefore extremely unlikely that at the end of a complex and expensive project, you’re going to have someone asking when <System X> is going live.. only to discover that you’ve been designing <System Y> the whole time.

Not just the big projects

By now you can probably see that even if you have a small/midsized project, there may be value in creating a glossary — even if you just write one for yourself and your own immediate team.

What if you have to hand off the project half way through requirements? What if the project grows in scope and scale further down the line?

Given that the understanding of terms happens as part of the standard UCD discovery/understand phase, it’s probably worth while creating one extra piece of documentation, even without the all-stakeholders working sessions.

Is it UX work?

Yes it’s UX work, but no it’s not user-facing. Remember that unless you’re really lucky (or a full-time user researcher) you’re probably going to spend more time with your stakeholders than your users.

So if you want a positive outcome for users and stakeholders, it’s part of the job of UX to facilitate understanding, communication and positive outcomes.

Doing this piece of work, or even suggesting you do it, shows a desire to keep the project on track. Even if you’re told that the team doesn’t want to spend time in more meetings — write up the glossary yourself, because when the conversations get confusing later on, you can step in and suggest it again.

At which point, the team may welcome the intervention.