Too often, product support is seen as simply a way to correct users who just can’t seem to do things properly. But what if we saw support as a way to educate users, and more importantly find the the difference between a developer’s concept of what a plugin or other product can do and what users think it can do?
If these two perceptions are different, then it is a clear sign that a new approach is needed for the support user experience. Redesigning a support system is an opportunity to not only better educate users about how to use the product, but to also better communicate what its true value is.
More importantly, a good support experience design can help build community between users and developers. Chances are whatever plugin, theme, or other service you are selling for WordPress, there are several other alternatives out there. The competitors may be using similar technology or even the same technology, since this is an open source ecosystem after all. I think that’s a good thing—it means success will generally go to those who serve their users the best.
Since August, I’ve been handling support for the Pods Framework. Pods is an incredibly powerful tool for getting the most out of WordPress’s CMS capabilities. Pods is a completely free plugin built by a small team of developers, supported by sponsorships and user contributions.
With these limited resources, lead developer Scott Kingsley Clark and the rest of the Pods team created a ton of cool features, but by the time I started with Pods there was a real gap between the plugin’s capabilities and educating users about what they could do with all of these features.
Traditionally, support for a product is designed in collaboration between the product’s developers and the support team. In order to make sure I am meeting our users’ needs and to make the most efficient use of our limited features, I’ve been co-creating and co-designing with our users as much as possible of the redesign of the user support experience for Pods.
The first step was our new tutorials section, featuring both user-authored content and content written by me that emerged from a process of co-creation. I’d like to share some of the lessons I learned about using participatory design strategies to create a better user support experience.
Be Empathetic
It helped that I started the job as a fairly novice user of Pods. This allowed me to walk in the shoes of a novice user for awhile. I used my experience learning to use the plugin as a way to explore the various pathways that existed, and those that didn’t exist between me and the information I needed to complete whatever it was I was trying to do.
Too often, the only way I was able to get the information I needed was to ask one of our developers. While this is an option available to anyone via our IRC channel, it is far from the most efficient use of our developers’ time, which is also a limited resource. So, whenever I solved a problem this way, I made a note that I needed to create a more direct path from the user to this information.
More importantly, beyond just being a nice person, I try to be relatable. I don’t know everything about Pods and I don’t pretend to. When a user wants Pods to do something that it doesn’t do, and I also wish it had that capability, I let them know. These are opportunities to bring people further into the community by having them make a feature request. As that user watches the feature request turn into an actual part of the plugin, they become more apart of what we are doing.
Letting The Support Forums Guide You
Often times support for a WordPress plugin or theme is handled by the developer who has more experience with WordPress than their users have. In this situation it is even more important to listen to users and pick up on trends.
When I was starting out with WordPress it was almost spooky how the site wpbeginner.com had anticipated every question I had. It was like they were reading my thoughts—before I even had them. When I saw the site’s founder Syed Balkhi speak at this year’s WordCamp Birmingham he shared the secret as to why his incredibly incredibly popular seems to always have the answer to every questions a WordPress beginner has.
Turns out Syed isn’t clairvoyant. Instead, he and his team search Twitter and other sites regularly for the questions being asked about WordPress, and answer the most common questions with tutorials on their site. They were meeting my needs by listening to people like me.
As a support rep, getting the same support question over and over again can either be a drain on your time or an opportunity to improve your support. When I see the same question over and over again, instead of just typing the same answer over and over again, I treat it as a valuable piece of information. These repetitive questions show me exactly which hole in our support system I need to fill in first.
Co-Create Content With Users
Whenever I create example code in the Pods support forums that could be useful to others, I create a public code snippet using Github’s Gist feature, with a more generalized version of it. Now that snippet can be found by anyone and I can give out the link in the future in support requests. This doesn’t just save me time, it gives me an opportunity to refine the code based on feedback from other users who have incorporated it into their sites.
A good, reusable code snippet is a good start, but is not the end of the process. Eventually it can become part of a tutorial breaking down each of the steps involved. This type of tutorial is shaped not only by me, but by the needs of many users, their feedback and help from our development team. The result addresses real problems, from real users, with solutions that work for them.
Use Community Generated Content
I only work for Pods twenty hours a week. After all of the time I spend answering support questions in our forums and IRC channel, as well as doing bug reporting and testing, I only have so much time to write tutorials and doc pages. Luckily we have several users who have written excellent tutorials about Pods. Previously no central or easily searchable location existed, to find the links to them. It was no surprise that I was getting requests for tutorials that already existed. Our users simply couldn’t find them.
While we were creating our new tutorials section, I realized it was going to look quite empty with only the three posts we had ready, even if one was an eight-part series that I wrote—with input and feedback from a user, of course. That’s when it occurred to me to do link posts to the ten or so tutorials I had collected from other sites. I didn’t want to pull all of the content into our site, and steal traffic from our user’s sites, but I did want to put all of these resources in one place.
My solution was for each of the user created tutorials to create a new post, on our site with a few sentences about the tutorial and a link to the complete article on the original site. With just a couple hours of work, I more than tripled the amount of content we were making available. Many of these tutorials cover topics too advanced for me to write about, which widens the breadth of topics covered. These tutorials now show up when a user searches our site and drive traffic to the original author’s site.
Recently, I took this process a step further when a user in our forums posted a solution to his own question before I could answer it. The original question was a common one, and I liked the solution, so I asked permission to use his code in a new tutorial. It turned out that the user was planning on writing a tutorial about it already, which was perfect. One more link post for the tutorials section, freeing me to work on other content.
Treating Users Like Human Beings
One thing you may have noticed is that I never did a single survey or questionnaire. Instead, I engaged in active conversation via Twitter, Facebook, Reddit and our support forums with active, current and past users to figure out what they needed help with, why they were considering using Pods, and even why they had chosen not to.
Co-creation isn’t beta testing or gathering data via analytics or surveys, its an ongoing conversation and process. More importantly, it allows you to treat your users like real people, by acting like a real person yourself.
People don’t interact via survey, we interact through conversation and through shared experience. The most powerful interactions we have with each other are those that are the most empathetic, when we truly understand what each other are experiencing.
Most people in the WordPress community are aware of the recent incident where WooThemes received a lot of criticism, when they announced they were changing the length of their support licenses. They made a mistake, which is what people do. I firmly believe that what makes a good person is not somehow avoiding making mistakes all together, but how they handle the mistakes they make.
If WooThemes had stuck to their original decision, it would have been easy to label them just another greedy company, but that’s not what happened. Instead, the people involved in the decision went out of their way to publicly acknowledge their failing, engage their users and the wider community in a discussion about how to move forward. Only then did they offer a new way forward that had emerged from that conversation.
That’s treating your users like people, by simply acting like a good person.
The debate about sustainable pricing structures and business models for WordPress products and services is far from finished. It’s an important discussion, but none of it matters unless people want to do business with you.
The WordPress world is no different than anywhere else. People want to do business with people who treat them like people. This is especially true in an open source ecosystem where alternatives to a product that has failed its users can and will spring up quickly to take its place.
1 Comment