Although I still stand by the idea that we all have the ability to decide how complex or how simple we create our themes, I do think that there’s something to be said for identifying the core problem a given theme is trying to solve.
That is to say, is a given theme trying to:
- Target landing pages for a certain type of niche business?
- Create a reading experience that looks ideal on mobile devices?
- Serve as a tumblr-esque type of blog?
- Meant to serve as an online journal for, say, photos or music or videos or something similar?
- …and so on
In short, I think that when someone asks you “what does your theme do?” or “who is your theme for?” then you should be able to quickly give an answer. Saying something like “this theme is for the small business owner who runs a restaurant, or a body shop, or a photography studio, or a convenience store” is too broad.
If we use personas as a way to identify who our themes are for, and a persona represents an actual type of person, then doesn’t it seem highly unlikely that a person who runs a restaurant may also be the type of person who is a mechanic and/or a photographer?
What I’m trying to say is that whenever we sit down to begin planning out and building our themes, I think that we need to do a better job of identifying both who the theme is for the and what the problem space is that we’re attempting to enter.
Of course, this isn’t to say that some teams don’t already do this. In fact, I can think of quite a few who do and who do it really well. Other times, though, I think that many try to create themes more or less to show off what they can do with WordPress rather than to truly serve a need that a potential set of customers may have.
So where do this leave us? That is, how can we do a better job of approaching theme development in such a way that’s it’s solving problems and catering to a certain type of customers rather than just trying to be the next flashy product that offers n-number of a features and m-number of options?
WordPress Theme Development Process
I don’t pretend to claim that I have the definitive way to approach building themes (is there even a single way?), but here are somethings that I’ve found to be useful when planning out a theme:
- Identify the type of problem you want to solve. Do you want to create a theme for long-form bloggers or casual bloggers? Do you want to create a theme for people who need a storefront? Do you want to create a theme for someone who writes a lot of documentation? And so on.
- Create a persona. A persona is nothing more than a fancy word for creating a fake personality that has the attributes of your ideal customer. How frequently do they blog? Do they do it from their desk each morning or is it periodically on the weekends each month? Do they update their site often or sporadically? Are they a writer, journalist, tumblr-style blogger, or what? Talk to people that fit into the type of problem you want to solve and then create solutions based on what they share.
- Test Your Implementation. This is also typically called some type of use case testing or user testing and it basically involves you sitting down with a few people who are of the target audience for which you’re trying to build the theme. You give them a list of things to run down and attempt to achieve and see how well they perform. Additionally, you can pre-populate the theme with test data and give them the chance to run through it and identify what they like, what they dislike, and so on. Sure, some of it will be subjective – it’s hard to nail a design that’s universally liked, but it’s possible to actually find something that resonates with a lot of people. Also, it’s important to note that testing should not include things that are bound to WordPress – that’s an entirely different focus of a test and it really doesn’t impact your theme if you’re rolling with the stock set of features.
- Go Easy on Customizations. This is arguably the most subjective point I’m going to make, but if you’ve worked with WordPress long enough, then you’ve likely experienced some of the challenges that come with working with custom post types, custom taxonomies, post formats, and so on. Because these are not universally supported features across all themes, then it may not be a good idea to include them in your theme, either. That is, people who are blogging are likely going to want to change their theme at some point. Yes, we’d like to have a level of customer retention, but trying to lock them into your theme by giving them features and formats for their data that only you support is a way to make them more irritated than happy. After all, what happens when you release another theme that they like and then they can’t migrate to it because it doesn’t offer all of the same customizations that your previous theme offered?
For many, I think that theme development is something that’s seen as a relatively easy and/or minor task. I can understand that statement, too. We’re not writing medical software, we’re not writing multithreaded embedded applications, and we’re not writing anything that interacts with the kernel of an operating system.
We are, however, doing more than just putting a pretty face on a website. We’re giving the words that people write – as serious or as light-hearted as they may be – a level of presentation that represents their ideas (and, ultimately, them) in a way that also is accessible to their readers.
And in that sense, it’s far more challenging than just trying to showcase what we’re capable of doing with WordPress.