Today I’m speaking at WordCamp Sacramento about the lessons I’ve learned while reviewing 30 membership plugins. While I get into product development, product marketing, writing review posts, and even membership details, I thought this quick review might help.
Have you heard the story of a building that melted a car?
There’s a building in London, colloquially called the “walkie talkie” building even though it doesn’t look anything like one, that was recently named the ugliest building in London.
But that’s not what’s most interesting about the building. What’s really interesting about it is its shape. Creating a concave structure seems a bit odd, you’d think. And maybe there’s been a reason most organizations don’t do it.
When you create that kind of curve, and the sun is in the right spot, it turns out that you can create a power ray of super-hot sunshine. A laser beam that melts things.
The builders are said to be “working” on it, but it’s a bit after-the-fact and it’s unclear if they’ll be able to solve the problem (even if it’s only a 2-hour issue, for only 2-3 weeks a year).
For now, they’ve closed the parking lots where cars were getting burned. And people don’t hang out down in that space, for obvious reasons.
Reviewing Membership Plugins
This past summer I spent a month or two reviewing 30 different membership plugins. And more than anything, I noticed that, much like the builders of the walkie talking building, most developers seemed to think about the user experience only after most of the development of their plugins was complete.
I’m not picking on one specific plugin or another.
I’m simply suggesting that the user interface (UI) and user experience (UX) of many of these plugins didn’t appear to be the first thing developers were considering.
As the Nielson Norman Group has said, UX – U = X.
In other words, you really shouldn’t take the user out of the user experience work you’re doing when focused on product development.
Start with the User
My colleague at Crowd Favorite, James Archer, likes to tell folks that design requires empathy. He’s 100% correct, and it applies beyond designing websites or branding material.
When WordPress plugin developers are writing code, they’re mostly focused on solving technical challenges. And I get this, because the technical challenges feel like they might not be solvable sometimes. So they attack that risk with vigor.
But what if that’s not the real risk?
What if the real risk is that your plugin functions but doesn’t get traction because users feel like it’s too complicated? What if the real challenge is that you’ve created a technically competent solution that has no empathy for its intended user?
Three Tips for Plugin Developers
My tips for folks creating WordPress plugins come down to this:
1. Get end users involved really early on and collect their feedback.
It’s normal to want to wait until your plugin is fully functional. But by then, you’ve likely made several decisions that will be difficult to unmake. So get end users involved as early as you can.
2. Measure the number of clicks to complete each main task.
One thing I noticed this summer was that for some key tasks, certain plugins might require a user to navigate 4, 5 or 6 different pages to get one single feature configured. That’s really painful.
3. Design your screens and experience before you write your code.
For the longest time I’ve told corporate executives that when it comes to designing software (from an architecture perspective), it’s easier to solve problems earlier rather than later. A dollar spent on technical planning saves hundreds during development. The same is true for design.