What’s in a Name?

Every discipline has its own names, lingo, and jargon to talk about what they do and how they do it. The world of UX has its own jargon too, but a complicating factor is that UX professionals come from such different backgrounds that our jargon often doesn’t match. We think we are all on the same page, but are using the same term to mean different things, or using different terms to mean the same thing. These confusions can even make or break the success of a project. Here are some examples from my life as a consultant:

Every discipline has its own names, lingo, and jargon to talk about what they do and how they do it. The world of UX has its own jargon too, but a complicating factor is that UX professionals come from such different backgrounds that our jargon often doesn’t match. We think we are all on the same page, but are using the same term to mean different things, or using different terms to mean the same thing. These confusions can even make or break the success of a project. Here are some examples from my life as a consultant:

Terminology Gone Awry

“What’s a template?”

The project was going smoothly. We’d done our user research, designed a set of 15 template screens, and were preparing the deliverable to show to the client. We thought we were almost done. All we had to do is get the client feedback, iterate the templates one more time, document the templates, and then we’d be done. In our minds, being “done” meant having delivered a full set of templates: a set of screens that defines the navigation, interactions, and visual design. All the detailed design screens could be created by taking one of the template screens and customizing it for that particular screen’s task.

We had brought together our main client contact and some of the project’s lead developers to present the templates we’d created. Everyone seemed satisfied; they only asked for a few changes to a few interactions. But as we are packing up someone asked, “So what’s next? When will we get the rest of the screens?” It turns out that the developers on the project never really understood what we meant by the word “template.” They thought we were designing all 200 screens in the application!

“Of course we have personas.”

Before a project even starts, I ask our client whether they already have personas we can use, or if we have to add persona development into the project. The answer is, “Yes, we have personas.” But, as we later discover, what they actually have is a short list of the general demographics of their current customer base with no details and no information about who the users are for this particular part of the website or product. Since we don’t have actual personas, we have go back and figure out how to get them into the project even though time and budget weren’t allotted for that work.

“Why do you need to do user research and stakeholder interviews?”

I was walking through each of the activities planned for a potential new project: a meeting to plan the project, then interviews with key stakeholders within their organization, and then user interviews and observations. The client stopped me and asked, “Wait, the stakeholders and users are the same people, right? So why do you need to talk to them twice?” I’m so familiar with these two terms that I don’t realize the distinction between the two might not be clear to others.

“But we’ve already done use case scenarios…”

I’ve also confused clients by saying I planned to develop user scenarios as part of the project. Eying me with suspicion, they say, “Look, we’ve already got use case scenarios.” But what they have is just a set of 350 small use cases—combinations of user actions with the system’s responses, and all the associated behind-the-scenes processing. The term use case has had such a long (and tortured) history and so many disparate definitions that I try not to use the term at all. I prefer the term user scenario instead, which I define to be a description of how the users will use the product I am designing. A user scenario takes into account the particular personas and the task the users are trying to accomplish, as well as information about the environment they are in. I usually create about a dozen user scenarios for a product I’m working on. These keep a high-level focus on user behaviors, rather than a detailed, granular, and technical focus on 350 small use cases.

“But where’s the site map?”

One of the deliverables on a project was a site map that documented the navigation of the website, showing the top level all the way down to the third or fourth level. Our documentation was about five pages long, with about 10 to 30 “boxes” per page designating certain content categories. “This is a great diagram of the navigation,” said the client, “but where is the site map?” For him, a site map meant a detailed description of every page in the site. For me it meant the high-level navigation.

Top 10 Ways to Avoid Terminology Problems

These are a few instances where terminology caused problems, but fortunately most of the projects I’ve worked on over the last several decades went very well. These terminology problems stick out in my mind because they all could have been avoided. And the problem is likely to compound as businesspeople get more hands-on in projects, and now that more and more people are entering the UX field coming from a broad diversity of educational and professional backgrounds.

So how can terminology problems be avoided? Here’s my top 10 list. Do you have any more you can add to the list?

1. Don’t make assumptions. Don’t assume that people know what you are talking about. Don’t assume that the term you are using is understood, or that it means the same thing to the person you are talking to.
2. Go over the plan more than once. The people you initially plan the project with may not be exactly the same as the team of people you work with over the course of the project. You will probably have to walk through the planned deliverables more than once to more than one group.
3. Show examples. Don’t describe in words what a particular deliverable will be. Instead show examples of what it is and maybe even what it is not.
4. Provide incremental deliverables. Rather than waiting until the end of the project to deliver a big finished product, give lots of deliverables along the way. That way any misunderstandings can emerge much earlier.
5. Be alert for new people joining a team. If you are working on a project for more than a few weeks, it is very likely that new people will join the project in some capacity. You may need to explain terms to them, as they have missed the definitions and examples you provided early in the project.
6. Make sure your team is using the same terminology. If you have a UX team that is working on different projects within the organization, make sure they are using the same terminology. The confusions in terminology could be emanating from your own UX group.
7. Make sure you are using consistent terminology. The problem may be very close to home—maybe it’s you! UX terminology has changed over time. If you’ve been doing UX work for a long time then you have probably changed what you call things. Chances are you revert to a previous name or use different words interchangeably to refer to the same thing. You understand what you mean, but it may be confusing to others around you.
8. Create a glossary to share within the UX group and with your clients. It’s probably more work than you realize, because you will find that you are discussing (even arguing!) with members of your team about what the terms mean. But that’s a good thing because it will point out where the discrepancies are. When you have the glossary completed, include examples and pictures of the different items and then publish it to your intranet and encourage your clients to use it too. Remember to also include processes in the glossary. For example, what does it mean to do card sorting? Usability testing?
9. Print a set of cards that you can use in conversations with the stakeholders and project team. On one side of the card is the term and definition, and on the other is a picture or example. Now you can pull out the card for wireframe and put it side-by-side with the card for visually treated screen and show the difference.
10. Revisit your glossary and keep it updated. The UX field changes. Once a year, take the glossary out and revisit the terms. It’s an opportunity to make sure your UX group is still in sync.

Terminology issues may seem at first to be just an annoyance of miscommunication, but defining, describing, and communicating clearly what we do and how we do it is the hallmark of a mature practice. And it will save you lots of headaches and time by not having disappointed or upset clients.