Ubiquitous language for product teams

Ubiquitous language is an idea that says products should have a clearly defined vocabulary (language) that is present everywhere (ubiquitous) deeply embedded in every aspect of the product. Your marketing, interface, even your code should speak this language that your users speak. This idea was introduced by Eric Evans in his book Domain Driven Design.

Despite its huge relevance and popularity among software architects and technical leaders, this concept is not well known outside of those groups. All people working in product teams can benefit by integrating this into their process.

Coming up with a ubiquitous language

At the time you are designing your product, come up with a list of terms that are common in your domain. For e.g, if your domain is food delivery, you would need to write down things (nouns) that your users understand and speak – food, delivery, order, restaurant, delivery charge, bill, dish. Also include actions (verbs) – ordering, cooking, delivering, paying, waiting, and how they combine with the nouns – e.g. delivering an order.

This should come from your users, don’t guess blindly. You should include user-facing roles – customer support and success, sales, user research, marketing research teams into this exercise.

Try speaking this language out loud in your discussions about the product. While you are doing so, look out for possible refinements –

• Is the language simple to understand? Are there any ambiguities?
• Is the language complete? Are we able to combine existing elements to express complex ideas or are we introducing new terms?
• Are there duplicates (two terms that explain the same idea) or inconsistencies (same term used to mean different things)

How should you use it?

Once you’ve settled down on a consistent language, you should use it everywhere. Some of the places which can benefit from a ubiquitous language are –

• In your UX copy. Also, make sure your interface reflects the models in your language. If a user is “picking” a “player” for his “team”, the interface should feel like it.
• In your notifications and other product communication
• In your marketing copy and sales pitches
• In your code, e.g. names of your services, functions, even variables. This will make it easy for the rest of your team to understand the code. It also makes it easy for non-developers to understand developers.
• In bigger software systems, this can also inform where your code boundaries lie. Your software should ideally reflect the models in your language.
• In your PRDs (product requirement document) and other internal documents
• In your meetings where different functions are talking to one another

Why should you care?

• It allows different people in the team/organization to understand each other more easily, making mistakes less likely.
• Having a common language and understanding increases your team’s agility towards a common goal.

If any of this sounds interesting and useful, definitely go check out original content in Domain Driven Design. I’ve bastardized the idea quite a bit to make it easy to consume.