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.

Some personas should be taken more seriously than others, I think.

Some personas should be taken more seriously than others, I think.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Category:
Articles
Tags:

Join the conversation! 5 Comments

  1. Nice writeup on how to target themes better. I think that creating themes that are more focussed is not only beneficial for the users, but also for the developer, as they are likely to generate more sales while being easier to support.

    Related to the point number 4, specifically the Custom Post Types, I think it’s always a good idea to point towards the Content Type Standards: https://github.com/justintadlock/content-type-standards

    I don’t necessarily agree with the not recommending to use Post Formats though. As long is you parse the content in a smart way and don’t require your users to format their content in a weird way, switching between themes should be relatively painless. Worst case scenario, the content will be displayed as is, without any adaptions due to lack of post format support.

    • I think that creating themes that are more focussed is not only beneficial for the users, but also for the developer, as they are likely to generate more sales while being easier to support.

      I agree. I think those who end up building themes that offer a wide variety of features, although maybe useful, need to be prepared for the level of support that comes with it.

      On top of that, there are a lot of users who end up blurring the lines between theme support and customizing a web site such that they end up asking for how to change things that are really outside the scope of what themes should support.

      This is another reason why I think having a really lean set of features is so important. If it’s not easily possible with the theme, then it’s likely to be out of scope for support.

      Related to the point number 4, specifically the Custom Post Types, I think it’s always a good idea to point towards the Content Type Standards.

      Indeed. This is a resource that I’m familiar with and I like the effort that’s being pushed with it. Until it’s part of some type of official standard, though, I still stay hesitant to use it. There are just times where something starts off with strong support and isn’t widely enough adopted.

      I don’t necessarily agree with the not recommending to use Post Formats though. As long is you parse the content in a smart way and don’t require your users to format their content in a weird way, switching between themes should be relatively painless.

      I can agree with that.

      My initial position has more to do with how post formats are handled right now. That is, when a person specifies, say, a link post format, then there is a certain why it should be styled – sure – but what about putting the link into the content?

      Does the link go in the Does the URL go into the title? Into the content? Is all content but a URL ignored? Is the title the anchor text?

      That’s just an example but I think it shows the challenge of post formats.

      • That was one of the reasons I was sad to see the Post Formats UI get yanked from Core in 3.6 I was really excited to play around with having that stuff standardized for users. Without it, you may end up having to parse out the post data that you want to style differently, which is almost always going to be a PITA.

  2. A very useful read for me. I fully agree with it as I am facing the consequences of building a “blurry scoped” theme with lots of feature but having very low sales, And also building a well scoped theme with lots of features and having good sales but huge amount of support work that eats up lots of my time.

    So, I realized that it is very important to identify the problem that a theme will solve and then work on providing a solution in the simplest and smartest way possible.

    • …but huge amount of support work that eats up lots of my time.

      Remember, that’s a great problem to have :).

      So, I realized that it is very important to identify the problem that a theme will solve and then work on providing a solution in the simplest and smartest way possible.

      Agreed. I think it’s important to identify the problem and to identify the persona you’re targeting.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.