Plugins and the WordPress design language

55,000 plugins. Fifty five thousand. That’s the number of plugins available in the official WordPress plugin repository. Isn’t that amazing? These days you can find a plugin for almost everything. SEO, social icons, music players, page builders, custom widgets, e-commerce, contact forms, custom fields, you name it. It’s in there.

What do they have in common?

Well, most of them are trying to solve a problem that WordPress itself can’t solve. Some of them are trying to make money as well, mostly through the freemium model. Which is great, I mean, why not? It is obvious by now that users will happily pay for a premium WordPress product. What is not so obvious though is the fact that people want to use your plugin but they are not willing to learn a new language.

A new what?

A new language. A design language. They have already learned one. The WordPress design language. It’s not official, it doesn’t have documentation but it is spoken by a staggering 33%+ of the web.

Navigating the vast realm of WordPress plugins indeed highlights the creativity and problem-solving capabilities of developers worldwide. However, amidst the plethora of choices, it becomes evident that users prefer solutions that seamlessly integrate with the familiar WordPress design language. This preference stems from the fact that users, particularly small businesses, seek simplicity and ease of use when enhancing their online presence. They are on the lookout for intuitive tools that effortlessly align with their existing knowledge. That’s why offering tailored Web Design Services for small businesses is essential. By understanding the nuances of the WordPress design language and catering to the specific needs of these users, web designers can craft plugins that not only solve problems but do so within the comfort zone of the users they aim to serve.

Take a look at the following image:

Now show it to anyone who has ever used the WordPress dashboard and tell them to add a caption to it. I’m sure most of them will swiftly respond with a “It’s the WordPress dashboard of course” or something along these lines.

We’ve been using this language since its introduction back in 2013 with WordPress 3.8 and based on its longevity (almost 6 years now) we are generally happy with it. It has received numerous improvements over the years but the concept, the core language, remains the same. Even WordPress 5.x, which introduced a radical new concept of creating content, speaks the same language. The sidebar is still on the left (or the right for our RTL friends). The toolbar with its handy shortcuts is still there. The content area for the majority of the default WordPress menu options, again, still the same.

A language within a language

I’ve met some really talented WordPress developers all these years. I can’t write production-grade WordPress code but I can easily distinguish it from half-baked solutions. What strikes me as odd tough, is that the exact same people seem to undermine the value of a consistent user experience. Thus, new design conventions are being introduced all the time. From various discussions with some developers who fall in this category, I’ve come to the conclusion that it’s not their intention to fragment the user experience within the WordPress dashboard. The luck of a proper pattern library simply makes them think that an extra set of simple styles for their custom options screens wouldn’t hurt.

Well, it does and here’s why. Basically you create additional work for your users. First they have to familiarize themselves with a brand new language (your custom interface elements) and then learn how to actually use it. Here’s a simple example:

I can already hear someone from the back row yelling at me “Come on, I totally get that screen, it’s not a big deal”. Agreed, it’s not. Here’s a question for you though. What happens when you click the delete button? Will you get a delete confirmation or simply delete the row? I don’t know. As a user though, I should know. Tables are one of the most used components throughout the WordPress dashboard. Users are already familiar with their components. They are predictable. They know exactly what happens when they click the edit button. They are battle-tested against multiple operating systems and devices. They are part of the WordPress design language. Why not use them?

Here’s another one. This one is great.

See that red arrow pointing at a radio button? I repeat. A radio button. Guess what, it’s not a radio button. It acts like a checkbox. On off. Blip blop. What? Why? I don’t know, you tell me. If you saw this screen outside the WordPress dashboard, would you ever be able to tell that we are talking about a WordPress plugin? Do you understand how it works? I don’t.

Here’s another example, a good one this time.

If Advanced Custom Fields with more than a million active installations can get away with an interface that screams WordPress, your tiny plugin could too. If you are a plugin developer but not familiar with ACF (not possible I guess, but you never know) just download a copy and have a look. It could be considered part of the vanilla WordPress installation and that’s simply great for their users.

Agreed, but I don’t have time for that

You have plenty of time. You came up with a completely new user interface and it definitely took longer to implement. It will be much easier for you to spot reusable components within the WordPress dashboard and use them instead of making new ones from scratch. You’ll save time and your users will keep speaking WordPress.

Agreed, but we don’t have a pattern library available

True. At some point a few years back this came up but it seems abandoned & incomplete. The WordPress dashboard itself and the inspection tools of favorite browser are your friends for now.

Maybe we should/could revive the pattern library project and bring it up to date? Maybe. What do you think? Do we need it?