In general, should you try to visually adhere to default WordPress admin style (button shapes, colors, etc).

Are there any benefits of custom styling except for branding (I suppose that WP teams does some usability tests on their designs)?

  • 1
    Personal preference for me is to stick to the standard styles, Drives me nuts when I come across a plugin that looks totally different to its surroundings. It could be because I often see flaws in 3rd party styling or basic fields are "over the top" and do not function correctly, often making page loading slower for those sections. Functionality and ease of use over cosmetic appeal and branding anyway for a non user facing area. Note, that's an opinion, not a factual statement :) – Randomer11 Oct 26 '17 at 9:41

Following the previous answers, in most cases I would stick to the WordPress default styles and patterns -- for design and also markup, functions, APIs and cod, not only the CSS --, specially if it's a plugin to the general public and to be hosted in the official repository.

  1. As Milan pointed out "There are many cases where WordPress admin styling is not enough."
  2. As said by Mark, "users hate to learn the new "snow flake" UI, especially when they have 20 plugin each with its own "snow flake" design."
  3. Your plugins will be more "future-proof" like. For example, if WordPress changes it's default CSS and styles in the future, your plugin will follow automatically in most cases.

That said, there will be times you will need to tweak, or event change completely, something. My advice is to build upon what WP does and change just what really needed or justified.

My company manages 3 WordPress multisite networks: A for our own clients, B for a specific niche managed sites/CMS/Digital Hub SAAS and C for other boarder niche managed sites SAAS.

  • Everything we make in A follows WordPress styles by the book.
  • On B we dropped most of WordPress styles/patterns for an APP/Material Design like approach. We wanted the user to feel user an app and not WordPress because it makes sense for the service. We changed a lot of design/presentation stuff with CSS but keeping as much of WP HTML markup andPHP/Javascript code patterns as we could.
  • On C we dropped WordPress styles/patterns in a few places.

And for plugins we release "in the wild", most of time we follow WP style/patterns.

| improve this answer | |

It all depends. There are many cases where WordPress admin styling is not enough: complex controls like repeaters with one or more fields, complex nested settings and other things. If you have a lot of settings, default WP styling might be limiting.

On the other hand, there are plugins and themes that use styling that look very alien and over the top, with huge colourful buttons, replacements for default HTML controls and much more. They look very out of place, and can be confusing for the end user.

If you need to create simple controls and settings, it is best to stick to the WordPress default styling (same classes as WP uses), that will ensure that your plugin looks good with all WordPress versions. If your plugin has a lot of settings and you need a better way to organize things, you can develop your own styling that will remain close to the WordPress, but giving you more flexibility.

For all my plugins, I have my own standardized interface library that is based on the WordPress styling with few extra organizational elements, and so far, my users had no problem adjusting to my plugins UI because it looks a lot like WordPress.

| improve this answer | |

This question reminds me the bad old days of the early java versions. java looked good if you focused just on its elements (well, good enough at least), but in the context of any OS it looked like an ugly bastard child.

No wordpress user is likely to avoid using your code because the UI do not follow conventions, but users hate to learn the new "snow flake" UI, especially when they have 20 plugin each with its own "snow flake" design.

UX design 101 is to always follow the conventions of the enviroment in which your code is running, and only if you do something drastically different, use different UX. Frankly even Apple and MS do not always follow this guide when they develop things for their own products on their own OS, but you are unlikely to be that big to not care.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.