Features vs benefits is the age-old tale that separates meh UX writers from great ones.
Talking about features, not benefits, is a trap even senior writers today fall into. But it’s one I’m going to teach you to steer clear of.
The best UX writers focus on the user benefit first. The feature is secondary. That’s because you need to give the user a reason to care before you offer something to care about.
What are features and benefits?
Here’s what I mean when I say features and benefits:
- Feature: The product offering, what it does, and how it works
- Benefit: The value added to the user’s life from solving their problem using the feature
For example, say you're writing for monday.com, a project management software. One key feature is custom dashboards.
Here’s the difference of describing the feature vs showing the user benefit:
Feature-oriented: Create custom dashboards and track progress, timelines, and budgets at a glance
Benefit oriented: Make business decisions with confidence with custom dashboards
The feature-oriented version stops at and focuses on only describing the product. The benefit-oriented version hits on a user's pain point (making business decisions) and tells them why and how the feature (custom dashboards) is relevant to their lives first.
Here’s another example from Casper mattress:
Feature-oriented: Multi-zoned support keeps your spine aligned
Benefit-oriented: Wake up back pain-free and align your spine with multi-zoned support
Keeping your “spine aligned” isn’t really a user benefit, even if it might seem like it is. Do you know the benefits of keeping your spine aligned? If you ask me, it sounds good, but I don’t know if that’s a problem I have.
Compare that to “wake up back pain-free” — that directly describes a problem I have and that multi-zoned support is a solution.
And here’s one last example from Airtable’s syncing feature:
Feature-oriented: Collaborate on a shared view of table data with different teams using Airtable
Benefit-oriented: Align your team around a single source of truth with real-time data from different sources
“Collaborating on a shared view of table data” sounds powerful, but the average user isn’t going to take the second to figure out how that applies to their problems.
On the other hand, aligning your team “around a single source of truth” solves a poignant problem and gives the user a reason to pique their interest.
How to find the user benefit
The best way to find the user benefit is to ask why. And ask why again. And ask why again.
Empowered first and foremost by user research and insights, you need to push the boundaries of description. And you do that through a string of “whys.”
For example, you can fill in the blank here to get to the benefit:
You should “eat broccoli” because ______.
The ______ is the user benefit/why the user should care.
For example:
You should eat broccoli because it's healthy for you.
Sure, being healthy is a user benefit, but it’s a pretty generic one. Telling the user “it’s healthy for you” isn’t going to spring them into action. We all know we should be healthy, but that doesn’t mean we live healthfully.
We need to go a layer deeper and ask, “Why would the user care about being healthy?”
Let’s say this user cares about being healthy because they want more energy. Then we revise our user benefit accordingly:
You should eat broccoli because it'll give you unmatched energy.
We’re getting somewhere, but we need to go a layer deeper — why does our user need unmatched energy? What is that a problem for them, and why should they care?
Let’s say our user is a busy tech executive. They’re juggling a director level role while raising a family, and they’re pinning for a VP-level promotion. They need to go above and beyond to achieve their goals, but they just don’t have the energy on a daily basis to do it.
Understanding this user pain point, we can ask “why” one last time to get to a hard-hitting user benefit:
You should eat broccoli because it'll give you unmatched energy, so you can conquer your workweek.
Now that’s a reason to eat broccoli 🥦
We can do the same Greg, a plant care app. The feature is Greg “eliminates all the guesswork of plant care”
Why does the user care about eliminating all the guesswork of plant care? So they know what to do.
Why does the user care about knowing what to do? So they don’t kill their plants.
Ah-ha! Then, we can fill out our little formula:
Greg eliminates all the guesswork of plant care, so you keep your plants alive.
There is a point where you can ask too many “whys” and get way too deep — deeper than the user cares to get with a digital product.
For example, if we were to continue with the “whys” for the Greg app, we could get to a pretty deep place:
Why do you want to keep your plants alive? Because you want something to care for and help grow.
Why do you want something to care for and help grow? So you can feel a sense of purpose.
“Feeling a sense of purpose” might be a little too lofty and detached from our feature. So it’s important to make sure your benefit is still within a reality the user is aware of.
We can do the same for the LinkedIn Premium feature that lets you see how your application compares:
Why does the user care about seeing how they compare to other applicants? So they can understand how their application stacks up.
Why does the user care about understanding how their application stacks up? So they can apply efficiently.
Why does the user care about applying efficiently? So they can save time and land a job already.
Why does the user care about applying efficiently? So they stop applying and start doing the job.
Then, we can fill out our little formula:
LinkedIn Premium helps you see how you compare to other applicants, so you can fast-track your job search.
And we can put on our UX writing cap and make this more succinct:
Fast-track your job search with insight into how your application stacks up
The more concrete you can get about the user benefit, the better.
Happy UX writing đź––
