As I’ve been working through a number of different plugins both for myself and for client projects, one of the things that has started to become glaringly apparent over the last few projects is just how unintuitive WordPress plugin settings can be.

I know, isn’t a new idea, but bear with me because I’m not talking about your standard run-of-the-mill plugins that have a settings page or that may add some type of shortcode functionality to the editor (though that’s unintuitive unto itself).

Instead, I’m talking about plugins that include a little bit of both: settings pages, additions to custom post types, perhaps the additions of shortcodes or buttons to the editor, and so on.

WordPress Plugin Settings

To be clear, when you have a single plugin with options that exist on a single page, it doesn’t get much simpler than that.

Sure – there are developers who can make that more cumbersome than necessary – but those who use the proper type of input elements, context help, and so on go a long way in helping the user understand how to configure the plugin.

On top of that, even if a plugin settings page contains subpage (such as with tabbed navigation), the same can be true.

WordPress Plugin Settings should be more intuitive.

These are our users. Cute, but clueluess and it’s all because of us.

But what happens when a plugin’s options are spread across a settings page, a post page (or a post type page) or that even do something that isn’t immediately obvious to the user?

Throw It in the Menu

As much as I absolutely love WordPress, it’s extendability and all of the jazz, I think that we – as a community of developers – have gotten so comfortable with how it works that we’ve developed a type of tunnel vision as to how complicated options can actually be.

A complicated menu from some software I once knew.

A complicated menu from some software I once knew.

For example, let’s say that you’re creating a new plugin and then the plugin has it’s own settings page. The options that you have available are:

  • Add the options to an existing page
  • Add the options to a new settings page and a submenu item
  • Add the options to a new settings page and a new top-level menu item

Each of these has their advantages and disadvantages, and though part of me wants to go into the details of the each of these, the sake of time and length are dissuading me from doing that.

So, with that said, let’s say that we opt to throw our plugin options into a submenu until the Settings menu. Great – now we have a place for a settings to live and we can always refer to our users and/or customers to that point.

But wait. The plugin has more functionality that was resides in the settings page.

Fragmenting the Options

Assuming that we’ve educated our customers on how to locate and modify the settings that exist within the plugin’s setting pages, but what about the functionality that exists throughout the rest of the WordPress dashboard.

By that, I mean let’s say the the plugin does one of the following:

  • It introduces to page templates to the theme that are accessible via the Templates meta box
  • It actually creates new pages with content and other functionality under the Pages menu
  • It introduces a meta box or two or three to post type editor pages
  • …or something more

And not only that, let’s say that some of the functionality that exists on, say, some of the templates is contingent on options that are configured on the plugin settings pages.

At this point, it even feels like we’ve created some type of spaghetti application and we’re the ones who are actually talking about the plugin.

Some of our plugins are as organized as Atlanta traffic.

Some of our plugins are as organized as Atlanta traffic.

So what are we to do?

Go Beyond the Instructions

One of the most common answers that we often hear are to include to information in a manual or in an instructional video. And sure, that’s great – we should be doing that – but when’s the last time you sifted through a manual or watched an eight minute product video?

And we expect our customers to do that.

There’s so much more low hanging fruit that we can introduce and that can work directly within the WordPress dashboard that can help guide our users and maybe they won’t need a manual, a video, or a tutor.

In continuing with the example above, let’s say that we’ve split the functionality of the plugin from a Settings page to Templates or a to a new meta box that affects the templates.

What then?

  • Why not make sure we’re adding more verbiage to the settings and options so users know how each element affects the plugin.
  • What about adding an anchor to the meta box that links the users back to the settings page to have easy access to the global options?
  • On top of that, why not add a context-aware anchor that will return the user back to the page from which they came complete with a description of what’s going on?
  • What about also trying to provide prompts – or placeholder attributes – in input elements where appropriate?
  • …and so on

Ultimately, the goal is to provide guardrails of sorts such that the user never feels lost within WordPress and within the options that our plugin is providing and the functionality that it’s introducing into WordPress.

I Am Not A Usability Expert

Perhaps I should’ve mentioned this at the beginning, but my background is not is usability or user experience, and so I’m not even sure if the suggestions above are terribly great.

But from first hand experience, this is what I’ve learned:

  • WordPress plugin settings are often not intuitive
  • Users easily get lost and/or confused in the settings that they are working with and don’t often understand what happens when they manipulate an option
  • Though this is really just conjecture, I think that there’s an exponential (rather than linear) increase in complexity when we split plugin settings from having a settings page and options that exist elsewhere in the dashboard
  • We should never want our users to feel lost or confused
  • Manuals and videos are time-consuming and frustrating for many people
  • Providing even the simplest form of prompts to guide the user through the plugin helps greatly

Sure, there’s a little more that could be discussed, but those are the high points.

know that we can do a better job at it, but because of our nature we have a tendency to maintain the tunnel vision that comes with being not only familiar with WordPress, but with what we’re actually building.

To that end, we’ve got to do a better job of making WordPress plugin settings more intuitive especially given the rise of the plugin economy that we’re seeing. But that’s content for another post.

Category:
Articles
Tags:

Join the conversation! 4 Comments

  1. And if you’re progressive, making this all happen in the customizer when needed.

  2. Couldn’t agree more. It’s often frustrating dealing with setting in both themes and plugins, especially when they deviate from the standard UI. It’s understandable that you want your plugin to stand out and look unique, but its also degrades the inherent usability of the product.

    I love the Office example you posted, its is a great example of over blown feature sets… yet, in context also an example of solid add-on UX. If I was to build a plugin of Word the best UX decision I could make is to create a ribbon menu for it; because thats what the customer is familiar with. Thinking that your plugin is so important that the customer is going to take the time to thoroughly learn your UI is not only arrogant, it misses the bigger picture. Your plugin is only one piece of the puzzle, the best thing you can do to make it fit with the other pieces.

    The truth is that the UX of a plugin is directly proportional to the discernment of features/settings. If we are designers / developers take the time to consider if the feature truly fits in the plugin, or should be crafted as its own plugin. Whether a setting is truly necessary, or just bloat. We will field less support requests, create less bugs, and the whole ecosystem will be better for it

    • Couldn’t agree more. It’s often frustrating dealing with setting in both themes and plugins, especially when they deviate from the standard UI.

      Agreed. This is something that absolutely needs to stop. It won’t because others think it’s cool, but it should stop.

      I love the Office example you posted, its is a great example of over blown feature sets… yet, in context also an example of solid add-on UX.

      I used the example primarily as a bit of humor, but I do think Office is bloated, and there’s a story as behind why it is the way it is, but I digress on that for the time being. Perhaps another time.

      Still, it doesn’t change the fact that trying to navigate the array of array of array of arrays of options is near hopeless. If developers get frustrated, the average user might as well just use Notepad.

      The truth is that the UX of a plugin is directly proportional to the discernment of features/settings.

      I’m sure there’s research on this and there are far more educated people who can speak to this, but I bet the proportion isn’t even linear. I bet the level of complexity is even greater than that in some cases.

      We will field less support requests, create less bugs, and the whole ecosystem will be better for it

      Bingo. That’s the ultimate goal.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.