A few years ago, I worked with a team that was constantly missing deadlines. And it wasn't because they didn't have good project management, it wasn't because they didn't have enough time, but it was really because they just didn't understand each other. So in my work with them, I asked them to do something counterintuitive. I asked them to slow down. So we paused in their Sprint planning, and instead we spent an hour just clarifying what certain terms that they were using all the time meant. What does it mean to be done? What does a review mean? What about a handoff or even the word urgent? They all meant different things to different people on the team. Now, it was a little frustrating for them, and it felt inefficient at first to slow down this much and have this conversation. But once we clarified what all those terms meant and came to a common understanding, well, within about a week, they were faster.

They were meeting their deadlines, there was fewer revisions needed, there was much less friction, and the whole team was getting along so much better. That's what today's episode is all about, how slowing down to create a shared language really speeds everything up.

Now, in user experience design, we have a principle. Speak the user's language, and it's part of a heuristic that is called making sure that there is a match between the system and the real world. And speak the user's language is just a critical piece of that. But this isn't just about product design. This is about communication within a team, with your customers, across an entire organization, and really how aligning on the words that we use can completely transform the way we work together and make us so much more efficient and effective. Now, again, this idea of speaking the user's language is part of a design principle about making sure there's a match between what's going on in the user's head and the real world, what they're interacting with.

So this comes from one of Jacob Nielsen's original 10 heuristics, and it's about bridging mental models, the mental model in your mind and what you're operating with in the real world, whether that's a piece of software or whether that's your colleagues or your boss or your customers. Now, let me give you an example of something that does not speak the user's language, just to really drive the point home of how critical this is. Now, I'm sure everybody who is listening to this podcast one time or another has had the blue screen of death appear on their computer. You know that blue screen of death that makes you wonder if it's ever coming back. Now, early on, the blue screen of death was accompanied by a message, something like this, that would come up in white letters on top of that blue screen of death. A fatal exception. 0e76534801 occurred in VXD VVM operating system has stopped. To prevent damage to your computer, press any key to continue.

Remember that. Press any key to continue and you would press the key and just kind of like squint and cross your fingers and hope that your computer was going to come back to life. Now, more recently, if you've had a blue screen of death, it's accompanied by a much more friendly message. Now, this still somewhat disconcerting, but a much more friendly message, and it reads something like this, your device ran into a problem and needs to restart. We're collecting some information and then we'll restart it for you.

That makes so much more sense and speaks the user's language much more than a fatal exception. ABCDEFG occurred and the operating system has stopped. To prevent damage to your computer, press any key to continue. Okay, so you see how one of those examples speaks the user's language and the other doesn't. So that's really what we're talking about as we're talking about this UX design principle. Speak the user's language. But if you know me and you know my work, you're going to know that I'm going to say that same design principle translates into a broader organizational lesson and that there's more for us to learn from that and way more ways for us to apply it.

Now, words are tools. We need to select the right tool for the job, and we need to select the tool, the word that is going to be resonant with our end user or the person we're in conversation with, whether that's our customer or our colleague. So words also create reality. And I could do a whole other episode, and probably I will at some point, on the social construction of reality and how the words that we use influence the reality that we're creating with the people that we are working with. And you know, a simple example would be if I frame something as a problem versus an opportunity, it's the exact same set of circumstance I'm talking about. But if I frame it as an opportunity, I'm again constructing a social reality between the two, between the two of us that there is an opportunity here for something versus a problem which has a much more negative connotation. Now again, I've talked a little bit about the speaking the user's language in product development and in software, but let's apply it to organizational life.

What if your user is your boss, your team, your cross functional partner, your colleague? How can we speak the user's language? Okay, so the real problem here is miscommunication. And that was the real problem of that technical team that I was mentioning. It wasn't lack of skill, it wasn't lack of project planning, it wasn't lack of any of those things. It was miscommunication. So we often have this false assumption that delays or confusion or missed deadlines are caused by incompetence. But most of the time, my friends, it is not incompetence that is behind it,  it is misaligned definitions, it is misaligned expectations. Because what I think is urgent and what you think is urgent are two different things. So when we don't have that common language, it is so much easier to have misunderstandings left, right and center.

I'll share just a quick example from my own work of a situation where I thought that the other person I was working with and I were in agreement on something, but we really weren't. So I use a CRM, a customer relationship management, to track various leads for conferences that I might speak at, deals that I have closed, all the things just to make sure that everything runs smoothly. So again, it helps track leads, but then when business is closed, it helps, it helps us track and plan for that as well. And so an assistant that I have who works in this CRM with me, we were talking and I said, you know, it would be really helpful, I think, if we also had the location in the, in the CRM. Now what she does is a lot of backend research to find conferences and find companies that I might be a good fit for. And then we put together a strategy about how we might approach them or if there's somebody already that works in that organization or is a conference planner for that conference that we already know and you know, find a way to, to approach them and So I said, I think it would be really helpful if we had location. And as one of the fields in our CRM, now it comes, you know, standard, but there's all these modifications that we can easily make to the user interface and to how we use it. And so here's what my use case was.

And I did not explicitly state this use case, but my use case was thinking this. If I'm speaking in, let's say, Boston, and I know I'm speaking at a conference in January in Boston, then I could reach out to other places that I know in Boston, other opportunities, maybe places that were going to hire me, but then their budget got cut short or, you know, various opportunities, either from the past or just places that I think I might be a good fit, knowing that I'm going to be in Boston, to reach out to them and say, hey, I'm going to be in Boston in January. You don't have to pay my travel because that's already covered. But if you think I might be a good fit for doing a workshop or an event in your organization, or if I know that there's another conference that I might be a good fit at, that's that sort of thing. If I knew, oh, we've got Boston in here. Let's find other places in Boston. Because, you see, the client might not necessarily be in Boston. They might just be having their event in Boston.

They might be based in Chicago and hosting a conference in Boston, or hosting a user group meeting for the users of their software in Boston, but they're based in Chicago. So I said we should add location. My assistant thought, yes, absolutely, it's brilliant. We should add location. And so we added the location field to each record in our CRM. And I started noticing that, like, I'm speaking in Boston, but that's listed as St. Louis as the location. Why is that? What's going on? Well, we had completely different ideas about what we meant about location.

Now, I just explained to you the whole use case behind why I wanted location in there. I did not explain the use case to my assistant. And so when we added location, she thought I meant the parent company's location. So the conference planner's location or the, you know, the headquarters location, not the location of where the event was. So we both thought we knew what we were talking about because location is a pretty understandable word. It's not even technical jargon. And still we were missing each other. So that's what I mean.

We have to, like, really get down into the nitty gritty and define some of these terms in order to work effectively together. And, and that's with somebody that I work closely with. Imagine somebody that I don't work that closely with or working across different divisions of an organization or different verticals inside of, inside of the same company. So it'd be really even more likely that we would be missing each other there. Now, another element of speaking the user's language comes down to communication styles. And I have an assessment that I do with organizations on communication style. And people find out what their style is and then they realize how, when they're communicating with somebody else who has the same dominant style or default style, that they do things so flow so easily and so quickly. And when they're communicating with somebody who's got a different style, especially if it's a radically different style, then things are much more stilted and miscommunication is much more likely to occur.

So when we think about doing a communication assessment like that, what we uncover is that there are organizational sub languages that different people, even in the same team speak. So here we can think about, you know, one person might be very detail oriented, using very risk averse language, while another person is communicating with big picture brainstorming, idea generation and high speed style. And these two styles just don't effectively work together. Now, just because one style is our dominant style doesn't mean that's the only way we can communicate. It just means that's the way we communicate when we don't put any extra attention or effort or intention into our communication.

And when we have these, you know, when we're all operating from our default and not making these subtle adjustments to meet each other where we're at, it's much more likely that we're going to have miscommunication, misalignment, even when our intentions are very, very good. So when we know what our own style is and when we know what our coworker style is, we can just do these small shortcuts that help us translate and align more effectively so that we're speaking the other person's language again, we're getting into trying on their sub language within the, within the organizational culture and just tweaking a couple small things, it just makes our, our message land so much better. Now, when I have a longer time to do this communication styles assessment and workshop with a client, one of the more advanced pieces that we get into, and this is why the podcast is so much fun, because I can take an extra couple minutes and tell you some of the advanced pieces so when we have, again, a longer time to work with this, we'll get into the work of Virginia Sater.

So she's a psychotherapist who's done incredible work on human language and human communication. And one of the things that she talks about is how we each have a sensory, like a sense, one of the five senses that we privilege in the language that we use. It's fascinating. So, you know, you think of the five senses. Taste, touch, smell, hearing, and sight. And there's not as much with taste and smell, although I can give you a couple examples of those. But let's. Let's look first at auditory.

So listening and hearing. Um, so if you privileged the auditory sense in your communication, you might use a lot of metaphorical language, like, oh, I'm hearing what you're saying. Oh, yeah. Oh, that totally resonates for me. Okay, a couple of hearing metaphors there.

Now, if you are more. If you privilege the visual sense, instead of saying, oh, I'm hearing that, you'll say something more like, oh, I see where you're going with this, or, oh, yeah, I think we have a shared vision on that. And you're using the visual metaphors to indicate agreement, disagreement, whatever it might be that you're communicating.

Now, if you privilege tactile or touch, you might say things more like. And use metaphors more like, oh, I have a gut feeling about this, or that rubs me the wrong way. Or, you know what? Let's run that idea up the flagpole, or let's take that idea for a spin. So these are operations in the physical world. You may be touching them or doing something with them. So that was auditory, visual, tactile, or touch. And then I will just give a passing nod to taste and smell. They don't come up as often.

And usually somebody has one of those three that I just covered as their dominant sense that they use the language around. But you might hear somebody say something like, you know, that smells fishy to me, or that's got a bad. That left a bad taste in my mouth. So sometimes the people will use those metaphors, but those. The other three that I covered first are much more common. So the advanced skill level here is that when you get good at listening for other people's sensory language and use their same sensory language back to them, so they might say, oh, let's run this up the flagpole and see if it works. And you might then say, yeah, let's take that idea for a spin and see what happens, as opposed. And that would.

That would create a lot more agreement and momentum and action based language as opposed to if they said let's run this up the flagpole and see if, and see if this idea works. And you said, yeah, let's, let's see if that resonates. Well, resonates. Not running something of the flagpole, running something of the flagpole again is very tactile reference. The resonance is more like something that we hear. So when we can get aligned on the same sensory metaphors in our language as somebody else, it really again can make a difference in terms of establishing rapport and agreement and momentum. Now just a cautionary tale, a cautionary word before I leave this and that is that if you are in a high stakes conversation with let's say your boss or your boss's boss and you're trying to listen for those sensory words, well I'm going to say maybe don't do it then because you might miss the forest for the trees because you're be. You'll be so intent on listening to hear what those sensory words are that the person is privileging or using as metaphorical language that you miss the entire point of the conversation.

So practice this in low stakes conversations, especially if it's somebody like a co worker or your boss, somebody that you communicate with regularly, it's quite likely that if they're dominant in visual, then it's going to be all visual from here on out. So listen in those lower stakes conversations to see which metaphors they or which sensory metaphors they're using and then try to match those. Okay, now one more, I want to give you one more example before we leave this. And this goes back a little bit to communication styles. So I was working with a business partner on a project a while back and this person that I was working with was far more risk averse than I am and we were at an impasse. We, I felt like we actually agreed on something but because of the risk language that was being used, it didn't sound like we agreed. And so I said, hey, let's just pause for a moment and take a step back and look at this from a different perspective. Now here's the thing too.

I knew this other person to be a visual person. So I said let's take a step back. Now taking a step back is tactile and that would be me. Cause I'm always like we're not on the same page. Tactile reference to a book. So I'm going to say let's take a step back. That's my sensory reference. And look at this in a new way.

That was their sensory reference. So we've got these two sensory references in play. And I said, I think we have different levels of risk tolerance. And the person was like, okay, kind of like, you got me, I'm interested. This is making sense. And so then I put another metaphor to it. I said, you like to circle the wagons and count the beans? And this person said, absolutely. And I said, that's your level of risk tolerance and that makes perfect sense.

And I said, and my level of risk tolerance is different. Instead of circling the wagons and counting the beans, I want to go fishing. I want to look for the next new opportunity. I want to go find something else that we haven't uncovered yet. And this business partner was like, I know that's what you do. And so then I said, okay, if the two of us are going to work together on this venture, I have to acknowledge that you'd rather circle the wagons and count the beans. And you have to acknowledge that I'd rather go fishing and that neither one of us is wrong. And the truth for this joint business venture that we're working on lies either somewhere in between or with some of each.

Some of, let's protect our assets and circle the wagons and count the beans to a certain extent. But at some point we're going to need to go fishing if we want to find the next new opportunity. And just using these two different metaphors and putting this language in place was really helpful for us to see we really were closer to agreement than we initially thought and that we had some different perspective about how we were going to approach risk in this project together. So I invite you to try that on or think about how you might be closer in alignment with somebody that you than you necessarily think you are. But you just need to change up the language so that you can realize that that gulf isn't as far apart as possible. Now, let's just look for a minute at why having that shared language increases speed and makes us more effective and efficient. And I like to, you know the, the story I told at the beginning about that organization where I got them to slow down and define some terms and slowing down allowed them to speed up. Well, this is one of my favorite stories and it comes from my youngest son's basketball coach when he was about seven, Coach Mark and if you've ever seen seven year old play, seven year olds play basketball, you know that the minute they get the ball, they race down the court thinking that they're the next Michael Jordan and that they're going to make a layup, but they get running too fast.

And what do they do? Well, they lose control of the ball. And so coach Mark told these boys over and over and over, you have to slow down to speed up, slow down, take the ball down the court slowly and under control, and then stop, line up your shot and take your shot. And that will speed up the score and it will also speed up how the game feels. And it's progressing as well. So slow down to speed up. Straight from the, from the wisdom of coach Mark. Now, when we slow down and create a shared language in our teams and in our organization, then there's no need to retranslate things. We're going to miss each other far less often.

It's going to reduce friction, and again, it's going to really speed things along. Decisions will get made faster, feedback is cleaner, cleaner and clearer. And the need to go back and rework things or, you know, clean up missed deadlines or decreases. Also, when we have that shared language, it reduces cognitive load. Now, what I mean by cognitive load is how much do you have to think about something? How much mental processing goes into understanding something? When cognitive load increases and things are complex and challenging to understand, well, that takes, that takes more work from our brains. So when we can reduce cognitive load because we both know what each other means when we use this particular term, then it just makes our work so much easier. Okay, so a couple of ideas here to just leave you with as we wrap this up. So what I'm doing in this episode, when I'm talking about that match between the system in the real world and use in speaking the user's language, this is UX thinking using shared language for teams.

It is straight up right out of the UX design textbook. But we're taking that UX thinking and applying it to teams, applying it to human communication, applying it not to product development, but to organizational life in general. And when we start to use UX terms like this in, not just in product design, and by all means we're going to keep using them there, but also using them to explain what's happening in organizational life, it creates something that is, it allows us to describe complex interactions more clearly. Clearly, it allows us to design interactions for our co workers, for our boss, for the people who report to us, for our customers. Design those interactions in a way that is fluid and easy and accelerates the momentum and accelerates the work that we're doing together. Now, you don't need a Huge glossary of shared terms. You just need to make sure that some of the key terms that you're using are well defined and make the exact same sense and have the same meaning to, to all in the organization. So how to do that? How do we get that shared language? Well, the first thing that you can do just on your own is you can listen closely in conversation with your colleagues, in conversation with your boss, with your customers, and as well as in meetings, listen closely for what terms are used repeatedly and where's their fuzziness or confusion? And when you see that fuzziness or confusion, what I want you to do is to speak up and to ask, and when you say, what do you mean by velocity? We need to get this out with velocity, does that mean like in two weeks, does that mean next quarter? Does that mean in 2026? So again, questioning any sort of language that might have fuzzy assumptions behind it.

Now, another way that you can put this into action is to be intentional in how you communicate and adjust your language to your audience. So if you're speaking to an engineer on your technical team, talk in terms of systems, use their language. I mean, don't speak out of turn. If you don't know their language, don't use their language. But the, to the extent that you do know some of their language, use those terms. If you're talking to a customer, talk to the customer in layperson's language or in terms of the benefit that the product or service provides to the customer, or the name of the feature that you're discussing, or whatever it is, but use their language. And if you're presenting something to your boss, again, you want to manage up and use results oriented framing of whatever it is you're talking about, so that your boss sees you as on a positive trajectory towards fixing things or making things better in the organization instead of coming to them with problems. So you want to speak their language, not just yours.

So when we don't have this kind of alignment in our communication and in the terms that we use, it requires rework. There are delays, missed deadlines, unnecessary meetings, and all of this stuff that makes organizational life frustrating. People feel like they're working hard but not making any actual progress. And that is so demoralizing and it chips away at trust, all the things. So alignment, on the other hand, it doesn't happen by accident. It happens with intention. It's designed one word at a time. So I want you to think about shared language as being strategic and that it is the foundation of, of working with greater momentum, working in ways where we understand each other and we are effective and we are efficient in our work.

So in your next meeting, I want you to slow down, ask at least one clarifying question. When you say X, what exactly do you mean? And I guarantee other people in that meeting will be sitting there silently thanking you because they didn't know that that's what it meant either. So reframe some of those communication challenges using the idea of speaking the user's language. Pay attention to how you show up. Are you speaking your language or are you speaking the other person's language? So slowing down to use the other person's language or clarify language or get on the same on the same page may feel inefficient initially. But if you want to move fast and move fast together, and that's where you're going to need to start. And in the words of coach Mark, slow down to speed up and don't just think about it, I want to invite you to road test this idea this week, try it out and see what happens. Now, as we close, let me just remind you that if you are in a position to make a recommendation for a keynote speaker or a trainer for an upcoming workshop or event who is able to connect the dots between UX thinking and leadership, please pass my name and my website along.

Details are [email protected] thanks so much for listening and I'll catch you next week.