“Not Intuitive” Is Another Way of Saying Slow “Time to Value”

If you’re like me, you’ve experienced 2-star reviews of your product like this before: “This plugin looks promising, but it’s just not intuitive.” No details. No bug reports. Just a vague (and familiar) sense of disappointment.

I’ve seen that kind of feedback pop up in support tickets, feedback forms, even as the reason someone uninstalls. And while it’s frustrating in the moment, over time I’ve come to see it as one of the clearest signals we get—one that points to a deeper issue with how our product delivers value.

Chuck V., a real GiveWP user, put it more gently in a Capterra review:

That’s a win for the support team, sure. But it’s also a signpost: the product left him guessing. And behind that guesswork is a metric we should all care about: time to value.

Time to value is a product metric that tracks how quickly a user achieves meaningful results after first using your product. It’s a core indicator of customer satisfaction, product-market fit, and long-term retention. The shorter the time to value, the better the experience.

Time to value, or TTV, is a critical metric that measures the amount of time it takes your new customers to get value from your product or service. New users expect to receive the value they have paid for in a timely manner—the quicker the better.

Paddle.com on TTV

The longer it takes for someone to feel they’ve achieved something meaningful with your plugin, the more likely they are to leave frustrated. “Some of the features were not as intuitive for a complete beginner like myself, but with the help of the support team everything works out!” That’s a win for the support team, sure. But it’s also a signpost: the product left her guessing.

I’ve been building and supporting WordPress products long enough to know that “not intuitive” almost never means what it says. It doesn’t mean broken. It doesn’t even mean bad. It means we missed something in the customer’s mental model—their expectations, their habits, the job they thought our plugin would do for them.

Here’s a few things I’ve learned over the years about customer feedback and intuitive product UX.

“Not Intuitive” Means They Couldn’t Succeed Without Help

“Not intuitive” is not a feature request—it’s a distress signal. It shows up when users can’t get started without searching, reading, or reaching out. It’s emotional shorthand for: “I tried to use your plugin, and I couldn’t figure it out without help.” That’s a failed first impression—and a clear hit to your product’s time to value.

And the tone is everything. Users don’t use “not intuitive” when they hit a rare bug—they say it when something basic felt off. When the next step wasn’t obvious. When they were excited to try something, and got stuck.

Find the Real Problem Behind the Problem

“Not intuitive” often points to a mismatch in mental models. We built something to solve a specific job. But the customer came in expecting it to work a different way.

It could be anything:

• Hidden CTAs
• Having to go to a different settings page to impact appearance or functionality in a block
• Settings panels with too many switches
• Flow interruptions that force people to use chatGPT to learn basic actions

Here’s a real example: KadenceWP recently launched a new Wedding Starter Template. Immediately, they got feedback saying it wasn’t “modern enough.” But when we asked what “modern” meant, users pointed to Framer templates—tech-industry sites with dark backgrounds, glowing buttons, and scroll animations. That’s not a wedding aesthetic—it’s a SaaS one. The users weren’t wrong. They just wanted something else entirely.

So the team didn’t redesign the wedding template. They started building new tech-oriented templates and upped their motion design across the board. Because that’s what the user was really asking for: visual sophistication, not a style mismatch. “Not modern enough” was just the surface symptom.

The interaction with the user in the KadenceWP Facebook group I think is really instructive, so I’m dropping it here as a reference (with user names/profile pic blurred).

You Shouldn’t Need Docs to Use a Good Plugin

Your temptation might be to add some links in your plugin to online docs to help users learn more about your features and usability. But that’s a trap.

The best interfaces make the right action feel inevitable. Obvious. Even fun. Without the need to “read more” or watch a Youtube tutorial.

Docs are essential—but they shouldn’t be the fallback for a broken experience. Their real role is powering your AI layers, onboarding flows, and post-success support—not bailing users out on the first click. If someone has to stop and read docs just to figure out where to start, your UX didn’t do its job.

This is where WordPress’ old mantra—”Decisions, not options“—still rings true. It’s not about limiting flexibility. It’s about offering a focused starting point with smart defaults and clear next steps.

This is exactly the kind of thinking behind recent conversations in WordPress Core around plugin activation flows. Kevin Hoffman points out that while Core shouldn’t dictate onboarding for every plugin, it can empower better time-to-value by letting plugins control what happens right after activation—like launching directly into a custom setup flow. Those first few seconds after install are critical. If you miss the chance to guide the user then, you’re already increasing their time to value.

“Decisions Not Options” in a Post-AI WordPress

Users don’t want 100 toggles—they want success. And today, AI can help get them there faster than ever.

We’re already seeing it:

• Setup wizards that auto-configure based on the site context
• Smart suggestions pulled from user behavior
• Interfaces that gently guide the user without being overbearing

The WordPress Core AI team is making great strides already. If you aren’t paying attention to how Core is going to embrace AI, then this WP Product Talk episode is a great place to get caught up.

When your product leverages AI smartly, users don’t even need to know that it was AI. They just feel like the plugin “got them.” That’s the real magic—building confidence without adding friction.

Another really easy, low-hanging fruit way to do that is what I call “Smart defaults.” If your plugin is pre-configured for the 80% of users who just want to hit “Publish” and see results, you’ve reduced their time to value dramatically just by having the best default settings out of the box. They shouldn’t need to think through settings or dig into configurations just to get what your product promised. Smart defaults give users success out of the gate—and confidence to explore more later.

You can still support power users without overwhelming everyone else with something like an “Advanced” toggle. Hide the extra settings most users will never touch until they’re needed. That way, the UI stays clean and accessible for beginners, but advanced users still get to fine-tune their setup. It lowers mental load without sacrificing capability.

Make It Intuitive by Design, Not by Documentation

Here’s the mindset shift: treat “not intuitive” like a usability bug, not a user failure or a feature request for more complexity. If someone couldn’t get started without help, something in your product is preventing them from having success.

Ask yourself: Can my users create the functionality my product promises in 10 minutes or less? 5 minutes? 60 seconds? That’s your time-to-value benchmark. If you’re missing it, that’s where to focus your next iteration. 

You don’t need to dumb things down. You need to:

• Focus on the 80% use case
• Use progressive disclosure for complexity
• Layer in smart defaults, inline hints, and auto-configuration

Because success shouldn’t require a tutorial. It should feel like momentum from the first click.

Takeaway: Next time you hear “not intuitive,” pause. Ask what they were really trying to do. That feedback isn’t a rejection—it’s a compass. And if you follow it to the root, it’ll take your product exactly where it needs to go.