One particular recurring theme comes up for me regularly when building products -in particular WordPress plugins- is to consider the parts as part of the whole. Consider the context your product fits into. This one concept is critical to building successful products.

I apply these concepts when building and reviewing WordPress plugins.

To my mind, a WordPress plugin should feel like part of WordPress. This guiding principle has helped to inform how I consider decisions when building and reviewing WordPress plugins.

User experience and benefit

Your product should best suit it’s user’s needs, fitting into the existing structures as a default, and slightly bending those structures only when the benefit to the user is greater than the constraint offered by the context the product fits into. Admin menus in WordPress is a great example of this, which we’ll discuss further a few paragraphs ahead.

If your product isn’t benefiting it’s core set of users, take it back to the drawing board, even if the code is elegant and beautiful.

Donald A. Norman captures this well in his principles of design:

“Principles of design:
1. Use both knowledge in the world and knowledge in the head.
2. Simplify the structure of tasks.
3. Make things visible: bridge gulfs between Execution and Evaluation.
4. Get the mappings right.
5. Exploit the power of constraints.
6. Design for error.
7. When all else fails, standardize.”

― Donald A. Norman, The Design of Everyday Things

In practice

I spend most of my day inside WordPress. I’ve spent most of my day inside WordPress since around 2007 (at the time of writing, 16 years and counting). I’ve reviewed hundreds of WordPress plugins, from features through to code and execution of the core idea of the plugin. I regularly apply these learnings to a starter plugin project (patches welcome) I’ve been iterating on for several years.

WordPress is very empowering and forgiving. One can build almost anything inside a WordPress plugin, and WordPress itself will receive that code with open arms. There is, however, a certain elegance which sets certain plugins apart from the thousands of plugins available today. Plugins which execute well on their core idea, with elegance and attention to detail.

There are several unspoken details within WordPress which I’d like to highlight here as examples.

Integration into admin menus

When your plugin is installed, it should feel like part of WordPress that has always been there. It should fit neatly in alongside other plugins and alongside WordPress itself. Pay attention to the way admin menus and existing screens within WordPress are named. Pay attention to the patterns and conventions used. Use existing code and APIs as a default.

For example, the “Posts” menu used to include an “Add New” menu. This menu is now called “Add New Post”. If your plugin has an “Add New” menu, change it to read “Add New [thing]” where [thing] is your content object being added.

If your post type is hierarchical, place is below the “Posts” menu. If it sits as part of an entirely different function of your site (ecommerce, for example), consider placing the navigation menu alongside your other ecommerce menus, and adding separators above and below the group to denote a switch in context from “site” to “store”.

Naming of taxonomy terms and their admin menus

It’s common to want to add categories, tags, or other taxonomies to your post types. There’s no need to set the admin menu text to be “[thing] Categories”. It’s already inside a menu called “[things]”. When naming the slug of the taxonomy itself, also keep the convention in line with WordPress. [thing]-category and [thing]-tag are fine. Note also that the slug is singular, rather than plural, in line with how WordPress names slugs for core taxonomies.

Settings screens and headings

There is no need to mention anything other than the purpose of the screen as a screen heading. “Special Settings for WooCommerce” can simply be “Special Settings”, if the screen is placed in the correct context.

It’s also totally okay to place your screens in the most logical place within the admin menu. If your screen is for settings, give it an appropriate name and place it as a sub-menu under “Settings”. For tools, place the screen under “Tools”. This approach helps your plugin to feel directly integrated into WordPress, rather than a separate tool added on top of WordPress.

WordPress provides easily used UI and UX flows which can be used in your own plugin code as well. Rather than re-inventing the user interface, use the pieces which already exist, especially if your admin screen is for settings, like many other screens are.

If your screen is for something other than settings or adding a content type (as shown above), use WordPress UI components and UX patterns. Browse similar screens in WordPress itself and in other plugins to draw inspiration.

Every piece of extra CSS or JavaScript increases the page load time for your users, and increases the opportunity for bugs and user interface discrepancies to creep in and interfere with the user experience.

In the above screenshot, you see two settings tabs. When switching tabs, the page reloads. This is totally okay, as it is the same behavior as across most legacy settings screens. If you visit “Settings > Reading” and click “Save Changes”, the page reloads.

Building with the future of WordPress

WordPress is embarking on a full redesign. While there will no doubt be updates required for plugins to fit into this revised design, consider how much of the legwork is already done when a plugin follows the existing UI and UX conventions within WordPress today. The new components are made available via NPM packages, and can be reliably called upon within WordPress settings screens. Going from a completely custom screen into the new design will be a much larger task than moving from the existing design to the new design. For users of the product, there will also be less of a switching overhead involved, as the screens will all have continuity.

There is of course a lot more which can be said about how to build sustainability into WordPress plugin development. What else have you observed when building WordPress plugins with the context and the future in mind? Please share your thoughts in the comments section, and lets discuss.