The Negative Effects of Changing WordPress Theme Design

For as much as I’m a fan of approaching WordPress theme and plugin development as one would any other type of software project, there’s one thing about releasing major updates to themes that I don’t think should be treated as some people treat software projects.

That is, when it comes time to do a major release of a theme – regardless of what the version number is (because that’s a discussion for an entirely different post) – I think that the presentation layer or the way the theme looks or its general styles shouldn’t deviate very much from the initial design.

Think about a number of the major applications that you use on a day-to-day basis. This can be desktop software, this can be mobile applications, this can be an operating system, this can be web applications, and this can even be other WordPress themes.

A tubular update to the UI of a dog collar.

Then, think about how often their interface changes. When it comes to major updates, there’s often times a major change in the interface or the introduction of a different way of doing something within the application. The change can be significant.

Although this introduces a learning curve which often leads to frustration on the user’s behalf, and although this is something that’s normal because of the advances in technology, I don’t think it necessarily applies to the look and feel of WordPress themes.

WordPress Theme Design (The UI Is the Theme)

For the sake of this post, let’s assume that you’re responsible for a theme that has a look and feel tailored specifically toward bloggers. It could just as easily be for landing pages, musicians, artists, a magazine-style theme, whatever – take your pick.

Then let’s say with the first version of your theme, you make improvements to the theme over time making minor style adjustments to, say, accommodate various browser inconsistencies, introduce a new option, remove a couple of options that are no longer needed, and you rewrite some functionality for the sake of efficiency or to leverage a new API.

For the most part, these changes are transparent to the user. Ideally, they should only make their experience with the theme much better. This isn’t always the case of course, but it’s not a bad goal for which to aim.

Exceptionally clear instructions.

Then let’s say that some new frontend framework is released, or that you stumble across a color scheme that you really like, or that some new jQuery plugin or JavaScript functionality comes available and you convince yourself that this is what your theme needs.

So, like many software developers, you jump into the code and you start reworking the theme. Depending on the nature of the change – like using a new frontend framework or a new color scheme – you may end up rewriting the theme from the ground up and then releasing it as the next major version of your theme.

This is where I think we make a huge mistake with regards to our products.

Lock In

WordPress themes are not like desktop applications or operating systems that can undergo a major shift in interface design and still maintain the the same customer base.

First, most of the major applications that you’re used to seeing overhauled are applications that have made themselves a core part of a business and, although the users may hate the changes, the business have to use the application because it’s what the rest of the industry uses and it’s how so much of their historical data is maintained.

They’ve been locked into the application, so they can’t deviate from it unless a competitor that can read the file formats properly comes along with a product that people like more. Then again, if the file format is proprietary, then it gets much more complicated.

Presentation and Reputation

The longer an individual or company uses a certain theme, the more their readers and the customer base become accustomed to how the website functions. They learn where everything is, they associate the presentation with the person or the company, and they become comfortable navigating the site.

In short, the site becomes a part of the brand of the person or the company, and people begin to think of their online presence in terms of the theme.

When your theme is responsible for part of this identity and you overhaul the way the theme looks, you end up impacting the way they’re perceived. Perhaps they won’t update the theme, perhaps they’ll hire out for a custom theme (which I think companies should probably do anyway, but that’s another post), or perhaps they’ll go with a theme that hasn’t had a major change in its presentation over the course of several major releases.

More to It Than This

The point is that I don’t think that overhauling the way a theme looks for any version – regardless of if it’s a major version or a minor version – is something that should happen. At least not immediately, and at least not with the current trends in web development.

It’s true that people purchase themes for a variety of reasons one of which is often the way it looks. To users, the interface and/or the presentation is the theme and when you change that up on them, you end up yanking the rug out from under them.

Not only can this give them a negative experience with your product, but it can also give their readers and their users a negative experience with them because they’ve also become accustomed to how the site works.

Finally, I’m not saying that once a theme’s design is locked in that it should never change – change is inevitable, especially within technology – but it’s something that should happen slowly over time, that should be well thought out, and that should be communicated to customers much earlier than the week of or the day of the release.

Furthermore, I think it makes more sense to gradually introduce changes over time such as with a slight change in color scheme or typography with the ability to maintain the old appearance via child themes at least for a period of time to create as little negative impact on the customer and the customer’s readers or the customer’s customer as possible.

The bottom line is that theme’s are for presentation of data that’s stored in a database. This can be a blog, this can be a website, or this can be a web application. To users, the way a theme looks is the theme and if you change up the way it looks then you might as well be giving them a new theme.

This is something that they did not purchase.

As such, I’m all for continual updates, releases, and improvements of our work, but completely overhauling the way a theme looks is something that I see as more of as an danger to our customer’s experience than anything else.