Working in the software industry, we live and breathe a certain language daily. Terms like discovery workshop, event storming, and wireframes are second nature to us, but these phrases can sound like a foreign language to clients outside of the industry. Some of them might even consider it silly. When we throw around terms that we’ve internalized as an everyday part of our processes, we sometimes forget that for our clients, it’s often their first encounter with this tech lingo.
The issue isn’t the terms themselves, it’s how we introduce them and explain what they really mean. It’s about translating them into something that aligns with the client’s world by drawing parallels that make sense in their context. Believe it or not, colorful post-its and terms like “event storming” can feel more like a playful workshop activity than a serious business process. And when the client’s native language isn’t English, this problem is even worse, especially if you just use a bastardized English word without any explanations.
Let’s break down a few common software terms, and how we might better translate them into something more relatable for the client.
Discovery Workshop → Requirements Gathering
“Discovery workshop” sounds exploratory and, in some cases, it is. But to a client, it might not be clear why they need to sit down for a deep dive into what seems like basics. Referring to this session as a “requirements gathering”, grounds it in something more familiar, as a discussion that is essential for any well-run project, software or otherwise. By simply reframing the name, you’re establishing that this is the solid foundation we’ll build upon.
Event Storming → Business Process Mapping
If you’ve ever introduced event storming and watched a client’s eyes glaze over, you know what I’m talking about. The term may evoke images of chaos, they might confuse it with the more popular Brainstorming, or something overly technical. But really, it’s just a fancy way of saying “We’re going to map out your business process”. It’s a clear, visual way to understand how things work within their organization, minus the jargon. Imagine comparing it to sketching out how you’d organize a factory floor or plan a major logistics operation. It becomes relatable, real, and useful.
Wireframes → Blueprints
Wireframes can sound abstract and technical, but calling them blueprints immediately evokes something familiar to most people. Even though it’s not completely the same thing, it’s close enough to explain the reason for creating wireframes instead of diving straight into Hi-Fi designs. They understand blueprints are the skeletal structure that defines how a house is built. In the same way, wireframes define the basic structure of their future product. This connection makes the process feel more tangible.
Moodboard → Design inspirations
You can think of a Moodboard as a panel for collecting design inspirations. It’s not just pretty pictures; it’s a way to explore visual elements that help shape the project’s look and feel. Comparisons can be drawn with interior designers presenting a board of colors, materials, and textures before starting to work on a space.
Environment, Deploy, Launch → Test, Prepare, Go Live
When you talk about environments or deployments, it can quickly sound too technical. Simplify it by breaking it down into phases that the client can easily grasp: Test, Prepare, and Go Live. By shifting to familiar terms, you’re not overwhelming them with a world of development cycles and servers, but instead, you’re explaining how you’ll make sure the product works and is ready to go.
Retrospective → Project Review
The term retrospective can sound unnecessarily complex. What we’re doing is simply a review of a project (or one of its parts) → looking back at what worked, what didn’t, and how to improve next time. The client is familiar with reviews in other contexts, so you’re relating it to something they already know.
Believe it or not, post-its, diagrams, and “event storming” sessions aren’t intuitive to every client. If we present them without proper context, in some professions they might even come across as childish. But with the right language and comparisons, even the most complex processes become something relatable—and ultimately, something they’ll want to be a part of.
There are hundreds of different examples, just think about Scrum or Kanban (burndown charts, story points, WiP, kaizen, etc.). You might as well be speaking in a completely different language.
Remember, at the heart of every project are real people, clients who (mostly) don’t live in the tech world like we do. While we’ll eventually introduce these terms and educate our clients on the nuances of software development, we must start by speaking their language. Drawing parallels, comparing these processes to ones they’re already familiar with, and adjusting our language in those early stages will ensure that clients feel comfortable and confident.
