I made my first theme for WordPress about 3 years ago. It sucked. Not just because of the actual style / functionality of it, but more specifically, the admin experience was an awful, unthought-out, careless disaster.
I designed a settings panel to try and make the user’s life easier. Instead, it destroyed it. Well, their life probably wasn’t destroyed, but their user experience definitely was.
Since that time, I’ve probably built about 25-30 plugins and learnt a few things about designing a (WordPress) product for the user.
Decisions, not options
What better place to start than the core WordPress Philosophy? You should focus on making the decisions that will benefit the majority of users, rather than providing countless options to please the very few that may want them.
When possible, don’t include any options at all. If a plugin is meant to add Schema.org markup to posts, is there a need for options? The user has installed this plugin with the expectation that Schema.org markup will be added to their posts. It should just be that simple.
Make predictions for them
You can actually be really smart about the options you do provide. Based on the user’s current settings and how they actually use your product, you could potentially create options that are only shown for certain environments.
Let’s say you’ve created a plugin that disables comments. Inside the plugin are a few settings, one of them allowing the user to choose for which post types to disable comments.
If a user has checked every single post type and then later adds a new post type to their site, shouldn’t the option to disable comments on that new post type be already checked? We know the user wanted to disable comments on all post types before, so we can presume they want to disable it on the new post type too – at least by default.
Every extra decision the user has to make hurts their experience
This is one I’m really passionate about. I like to think that every time you present a user with an extra option – an extra decision – it’s hurting their experience.
If you’re filling in a form that requires your name, it’d be a lot nicer to be presented with one field – Name – rather than two fields – First Name & Last Name. By giving you just one field that does the same thing as two fields, I’ve prevented you from having to make one more decision.
Or let’s take the search form on CodeCanyon for example. As you to start typing, an ‘x’ appears:
Why is there a need for this?
All it does is allow the user to erase their already-typed search terms. Simple enough. But while using it, I had to see it and process in my mind, what it was, what it did and why it was there. That’s stopping me from actually making my search, finding an item to buy and eventually buying it.
Design for users, not for you
When we built a product, it’s often because we’ve been faced with a problem that we needed to solve. It starts off as our problem. However, when you sit down and start to build the solution, if it’s a solution that others are going to use, stop solving it just for you.
It started as your problem, but now it’s theirs.
As soon as you decided the solution you were building was going to be a product, released to others, the problem stopped be yours and started being the user’s.
As such, you should actually be shaping the solution for them. Just because you specifically needed the solution to do something particular, doesn’t mean that the average user will. Make anything possible but make it seem like there’s nothing else needed.
It’s easy to get stuck in a haze of options and possibilities, excited at the fact that your users will be able to just ‘flick a switch’ and everything will change. But really, that’s not what the user wants. That’s not what the user should want or should need.
Building the perfect product means building the perfect user experience. Remember that before you pile 101 options into a favicon plugin.