In building software – especially at the enterprise level – one phrase that’s used to describe the work that goes into understanding what all needs to make up an application is that of the “problem space” or the “problem domain.”

This is important because part of the process of understanding the problem domain is learning the language, the terminology, and the concepts that go into building an application.

For example, say you’re building a job board. You’re likely to have something like:

  • Job Posts
  • Resumes
  • Recruiters
  • Employers
  • Employees
  • Candidates
  • …and so on

These ideas are then taken and ultimately converted into code.

Sometimes, developers will use the terminology associated with the problem domain (and this is part of domain-driven design) in their code; other times, the problem may get solved but the code may not completely reflect the problem space at the code level.

At any rate, one of the things that I see – as designers and/or developers – doing is using terminology that is more frequently associated with how we view WordPress than how users do.

The Facets of the Domain Language

First, the entire idea behind this post is to urge us to do a better job as using the terminology associated with WordPress as users and customers do, and not the other way around.

By that, I mean that when we’re writing articles, giving presentations, and talking about WordPress to users and customers, we need to make sure that we’re using the terminology that they see used throughout the application and the documentation – not the terminology that we use.

"What does that even mean?" They ask.

“What does that even mean?” They ask.

For example, I often see more advanced users – that is, developers, designers, and other similar people – using terms such as “The WordPress Admin” or “Taxonomies” or “TinyMCE” but to our users, this is jargon.

And I’m sure that anyone who has worked closely with users, produced educational videos, or listened to some of the frustrations the other users have understand why this terminology is confusing.

In keeping with the previous terms, we should be using terms like the following:

  • The WordPress Admin is the Dashboard, unless you’re talking about the actual admin user; otherwise, the user may not know what you’re talking about.
  • Taxonomies is a word for classification or categories. Depending on how you’re walking users through a project, it’s okay to use another term such as a category or a tag (or whatever their relationship may be to a post or a post type).
  • TinyMCE is just the editor. Calling it anything other than that puts us on the track for having to go off on a tangent explaining the name, and possibly explaining why it’s named that way, how it relates to WordPress, as so on.

The bottom line is that, to users, it’s all WordPress. Overloading terms (like the WordPress Admin when there is a Dashboard and an Admin User) can be confusing and doesn’t do a great job of explaining an idea to those who are reading, listening, or working with us.

Ultimately, our goal should be to make sure that we’re talking on their terms – we should not expect them to understand our terms, and we definitely shouldn’t use our terms to talk to others (and people do do this) for the sake of sounding more experienced, educated, and so on.

And I believe this if for no other reason than that the idea of simplifying a complex idea and making it easier for someone else to understand is the mark of a good educator.

Domain Language in Development

As I said at the beginning of this post, the idea of using a domain language is usually used more in conjunction with writing code in the problem space (or the problem domain), but shouldn’t be solely limited to that.

After all, everything that goes into providing a solution is related to the rest of the tools, applications, and things oriented around solving the actual problem. To that end, it’s important that we talk in their terms and not ours.

In a follow-up post, I’ll talk about the importance of using the domain language within the context of our code – from class names, function names, and variables – in order to show how the code should help mirror the terminology used in explaining and solving the problem.

But, for now, I urge all of us who are involved in writing, education, and helping others learn WordPress to refine our terminology to that it meets the user where they are (rather than expecting them to move on from there).