WordPress is about freedom. This is one of the many reasons for the platform’s success, as well as creating an interesting new paradigm. Developers have a very low barrier to entry, which means that anyone with an idea and time to spare can develop a product on top of WordPress, upload the files to a marketplace and start selling (and making money). With this low barrier to entry, and an influx of developers looking to sell their products, it becomes an exercise of it’s own to try and stand out from the crowd (be the signal amongst the noise).

Fortunately, there are a few golden rules and tips which, when employed, help the product stand out from the rest.

In no particular order, here are a few of these golden tips:

Choose one feature; make it perfect

Perfection is many small elements, done well. Marco Pierre White

It’s all well and good if you want to make a plugin that “does it all”. The one fatal flaw of this approach is that it is counter to what the very foundation of WordPress is. Having a plugin system within WordPress has several benefits:

Core doesn’t need to do everything

Not every WordPress user requires an events calendar or a form generator. If you need specific functionality on top of what WordPress core offers, there’s a plugin for that.

Ease of pinpointing an issue

If something breaks, simply deactivate all of your plugins and reactivate them one at a time. When something breaks, you’ll know which is the problem product.

Another reason to keep your product focussed on a single purpose is to avoid intra-product functionality conflicts. You may have two features within your product which cause conflicts, in niche cases. You may spend hours upgrading Feature A, only to realise that you’ve created a conflict with Feature B. If you’ve got many customers who use only one of the features, separating these out into two separate products minimises the conflicts and potential pain points customers may experience (for example, a customer who uses only Feature B, would be forced to bear the brunt of a conflict with Feature A, even if they don’t use it).

Know your audience

Before coding a single line, be sure you know who your product is speaking to. An example of this would be my Matty Theme Quickswitch plugin. This plugin is aimed squarely at theme developers who need to quickly switch between many different themes, per day, in order to fix bugs or answer support tickets for their themes.

Knowing this, I’m able to easily accept or reject features for this product, as I know who the product is speaking to.

Another example of this is a theme. Is your theme geared at beginners, developers or both? Are you targeting a specific niche, which requires compatibility with certain plugins (for example, the real estate niche, who enjoy using a specific plugin for listing their properties).

Knowing your product’s audience helps to keep the feature set in line with your (and your customer’s) goals, answer pre-sales questions more efficiently and ensure your product develops in line with your customer’s vision.

Abide by WordPress Coding Standards

As long as your plugin or theme has the correct header information, you can do anything inside it. This means there are many (many) different approaches being taken when developing WordPress products. This is where the code standards come into play.

The WordPress Code Standards is a document (on the WordPress Codex) which outlines conventions for organising files, code structures, naming conventions, etc. These standards also cater for areas such as loading localisation files, correct loading of assets and preparing your code to interact with other WordPress plugins.

Use the tools and conventions within WordPress

This is one of the easiest tips on this list. Look at WordPress and make sure your product blends in.

If your product uses a settings screen in the administration area, make sure you place it under the correct menu item (appearance adjustments under Appearance, set up screens under Settings, etc). If your product doesn’t need a top-level admin menu item, don’t add one just for the sake of having your own icon next to the menu label.

WordPress also includes a Settings API for easily creating settings screens which look like WordPress settings screens. They’re also more secure and take a bunch of the code out of the equation, which can only help.

Be mindful of user interface conventions within WordPress, and respect them. There is an entire team dedicated to improving and adjusting the WordPress user interface, based on usage data and experience, so respect that and make use of their findings.

In addition to being mindful and respectful of the existing interface, it’s important to consider your customers. Having used the existing WordPress interfaces, your customer is used to a specific convention. If it’s a blue button, it does the “save” or “publish” action (in other words, they click the blue button when they’re done). If your customer sees a spinning circle, they know something is being saved for them in the background.

Your role in developing a WordPress product isn’t to re-design the administration interface, it is to provide an intuitive space for your customer to get the plugin up and running, or adjust settings.

Test your product

Always check your work. While this may sound like something a high school math teacher would say, they couldn’t be more correct. Just because the code looks correct, doesn’t mean it works.

If you know your product makes out-going requests, try and test it on a bunch of different server types (shared, dedicated, virtual, etc). If you’re creating directories and files (not recommended, by the way), be sure to do the same kinds of tests as mentioned above.

Try to test your product as if you are your own customer. If your product is truly magical, it is most likely being created to scratch your own itch, so testing as your own customer shouldn’t be an issue.

Why you should follow these tips

These tips are just that; tips. Guidelines, if you will. While I’m not going to sit you down and force you to follow these steps, here are some benefits to doing so:

Easier debugging after release

Debugging a snippet of code is nobody’s first choice for an evening activity. This is one of those tasks where you want to get into the (correct) file, fix the bug, commit the code and move on. Making your code lean and mean, helps with finding bugs several months down the line.

Fewer support requests

You’re a developer (or product manager). Your passion is developing WordPress products, not helping customers to figure out how to use your product. If you’ve followed the golden rules above, any customer support query should be along the lines of a bug report or a conflict with another plugin (read: other kind of bug report). Of course, there will always be those one or two cases where the ticket isn’t a bug report, so be sure to keep a look out for those, and respond in a friendly manner.

Executive summary

The goal of the above steps three-fold; respect the technology, embrace the technology and help customers to understand, use and benefit from your product in the most intuitive and friendly manner possible.

Got any other golden tips for WordPress product development? Share them in the comments, below.