Features shouldn’t feel like features | by Avi Siegel | Dec, 2024

Ever use a product where everything just clicked? Where functionality felt so intuitive it was almost invisible? Where every interaction felt natural, as if the product were reading your mind?

It’s a magical feeling, isn’t it? Like the product was designed specifically for you, anticipating your every need. No hunting through menus, no awkward workarounds, no puzzling over how to accomplish whatever it is that you’re trying to accomplish — everything just flows.

Now think about the last time you had to learn a new tool. Recall that overwhelming feeling of staring at the endless navigation, the seemingly infinite buttons on every page, the dashboard that seems like it’s trying to tell you an answer, if only you knew how to speak its language.

The difference between these experiences isn’t about having more or fewer capabilities. It’s about how naturally those capabilities fit into the way you work.

That’s the power of experience-driven design, and it hinges on a simple but profound concept:

Features shouldn’t feel like features.

This isn’t just wordplay. This is a fundamental shift in how you should think about building products — one that separates truly great products from the endless parade of feature-rich but painful-to-use tools that dominate most markets.

Think about it this way: When you build features, you’re asking users to learn your product. When you craft experiences, you’re adapting your product to how users already work. The best products don’t feel like collections of features to be learned — they feel like natural extensions of each user’s workflow. By shifting from feature-centric to experience-driven design, you stop adding complexity to your product and start removing friction from your users’ lives.

We often think of features as distinct, self-contained units of functionality. They’re the bullet points on a product roadmap, the items in a changelog, the callouts in a monthly newsletter.

And they are indeed all those things.

Experiences can also be all those things, of course. But what makes them different is the way we think about them.

When you just list out the things you’re building (in those aforementioned roadmaps, changelogs, and newsletters), it’s easy for it all to become a jumbled mess disconnected from the most important part of the product-building equation: the user.

But when you start from the perspective of the user, it’s not about the lists of things you’re doing anymore. It becomes not just about the problems being solved, but how the pain points are being addressed and the feeling of how it all comes together into a cohesive product.

A feature is something users use.

An experience is something users seamlessly engage with as they accomplish their goals.

Both solve the problem. But one does it on the user’s terms.

An example

Let me illustrate by way of example. (I’m sure you’ve seen the below competing concepts in various tools you’ve used — you tell me which is better.)

Imagine you’re writing a comment in your task management tool, and you want to add an image for context. You drag from your desktop into the description area, and it’s added in-line.

Let’s go to the other end of spectrum. You try to drag & drop, but you get a little “you can’t drop that here” icon. You realize there’s an “upload media” button, which you click, and a select-your-file modal pops open. You navigate through your computer’s file hierarchy, double click, and your image is loaded as an attachment to the task, available at the bottom of the description with no context whatsoever as to what it relates to or why it’s there.

Both of these are features, of course — a product manager prioritized solving a pain point, a designer conceptualized the idea, an engineer built the functionality into the tool.

And both solve the need (to add images to a task).

But one is a feature that very much feels like a feature.

Whereas the other? The other is a feature you barely feel because it’s an experience. It just feels right… like a natural extension of the context you’re already in… exactly what you’d expect to happen if you performed that action.

That difference is features vs. experiences in a nutshell.

Go pull up your product roadmap. I imagine it has a pretty specific list of things you plan on building, something like this:

• Calendar integration
• Custom database fields
• Alerts system
• Export tool
• Dashboard
• Dark mode
• Etc.

Each item is a feature that someone asked for, or that a competitor already has, or that seemed like a good idea during that one meeting where everyone was hopped up on caffeine and enthusiasm.

The problem isn’t that these are bad ideas — I’m sure they’re great! The problem is that you’re thinking about them as features to be shipped rather than experiences to be crafted.

Go back to that list — does any of that really tell you what’s needed?

• What does the calendar integration need to do?
• Do you need a custom fields features, or do you just need to add a few common fields that were left out of the initial scope?
• What are those alerts going to alert about? Will users actually see them in your tool, or should they end up in Slack (or wherever else your users are)?
• Do people need to export their data, or just get it into their BI tool?
• What questions are going to be answered by the dashboard? Is a dashboard the right place to answer those questions?
• Are your users the highly technical kind that expect dark mode in all their tools, or is it just that your CEO wants dark mode because they heard it’s all the rage?

You’re creating a product that feels like it was assembled from a box of random parts rather than designed as a cohesive whole.

And as such, you keep ending up with…

• Feature bloat: Every piece of functionality that a single person ever wanted (and yet somehow, paradoxically, nobody can do what they need to do)
• Inconsistency: Each feature feels different than the last, because each one was built to function in a way perfectly ideal for itself on its own, without consideration for how it fits into the bigger picture
• Decreased usability & horrible UX: A cluttered interface with too many options, and nobody can find the functionality they need

If you think about features in terms of raw functionality — just adding more buttons, pages, capabilities — you end up with a feature factory. This is where products become bloated, complex, unusable messes.

The best features are the ones which users don’t even realize they’re using as they use them. They’re the ones that feel so natural, so obvious, that users would be surprised to learn they weren’t always there.

Think about your smartphone’s keyboard. Remember when it didn’t have swipe-to-text or speech-to-text? When it didn’t autosuggest the perfect emoji? When it didn’t automatically correct your typos? Ducking right you do!

Those aren’t feature anymore — they’re just how keyboards work.

• Emoji keyboard — feature. Emoji autosuggest — experience.
• Old school autocorrect (replace specific sets of characters with specific other sets of characters) — feature. Current autocorrect (just do it) — experience.
• Individually press every single individual letter like a plebeian — feature. Swipe- or speech-to-text — experience.

Technically possible — feature.

Just works — experience.

That’s what you need to aim for. Not features that users have to seek out and learn to use, but experiences that just work the way users expect them to work.

Some more examples for you:

• Documents that save automatically, instead of requiring a save button (remember when you’d lose your 20-page essay if you forgot to hit ctrl-s? Pepperidge Farm remembers)
• Search results that update as you type, instead of requiring you to hit enter (minimize those clicks)
• Copying on your phone and pasting on your laptop (i.e., universal clipboard), instead of texting yourself or sending yourself an email
• Forms that remember what you entered even if you accidentally navigate away, instead of losing your work and having to start over (or just give up and never submit)
• Code editors that format your code as you type, instead of wasting time debating the entire engineering team on the virtues of tabs vs. spaces
• Dashboards that adjust their time range to automatically include today, instead of having to press “in the last month” every single damn time you open the dashboard
• Agile task management tooling that reminds you about upcoming holidays during Sprint Planning, instead of starting the sprint and realizing immediately after that you’re destined to fail to hit your goals (sigh)

Notice the pattern? None of these feel like features because they’re not adding new things for users to do — they’re removing friction from things users are already doing.

If you think about features in terms of experiences, you focus on providing value in the most natural and intuitive way possible. You find the best way to help users help themselves, as opposed to just adding yet another button amidst a sea of buttons.

Okay, so features bad / experiences good. How do you turn a feature factory into an experience studio?

1. Understand the story behind the need

Stop asking “what features do our customers want?” — that’s like asking what tools to buy before you know what you’re building.

Instead, dig deeper:

• What is the user actually trying to accomplish? Not just the immediate task, but the broader goal.
• Why is this particular need so important to the user? This goes beyond the “what do they say they want” and into the “but seriously, why do they actually want it”.
• What is it about the user that makes them… them? What is their role? How does that impact what they need or what they know or how they think?
• How does this need fit into the user’s broader workflow? What are they trying to do right before and after this particular task? This can easily influence the understanding of the “why” and the solution that becomes the “how”.

[If you’re astute, you may have noticed really this all comes down to understanding the job story.]

The best product experiences come from understanding the complete context of user needs, not just the specific request.

2. Look for friction points

This is your treasure map — X marks the bad-user-experience-that-could-be-better. While users might not be great at telling you what’s wrong, their behavior leaves clues everywhere. Your job is to be a product detective, hunting down these moments of frustration before users have to complain about them.

• Flow disruptions: Every time a user has to stop what they’re doing and think about a next step that needs taking (especially seemingly unnecessary ones), you’ve found a friction point. Why should they have to remember to save? Why should they need to manually sync?
• Cognitive overhead: What are users forced to remember or track? Those task ids they keep copying and pasting everywhere? The three difference places they need to update every time something changes?
• Repetitive actions: If users are doing the same thing over, and over, and over again — that’s a red flag. These are ripe opportunities for behavior that could at least be simplified, if not fully automated.
• “I wish it just…” moments: These are pure gold. This is users telling you exactly where your product is falling short, where potentially even a slight tweak or tiny improvement could turn the unnatural into magic. (Though, be sure to pay attention to not just what they’re wishing for, but also why they wish for it.)

Every point of friction is an opportunity to transform a clunky feature into an invisible experience.

3. Remove before you add

This may be counterintuitive for most product teams, but it’s absolutely crucial. Before you add anything, think:

• Can we eliminate (or hide) a feature without causing any heartache? Are there features which are used by effectively 0% of your user base (or low enough that you’re not worried about it)? Other features will automatically be easier to discover/locate and use simply by getting rid of features that are in the way.
• Can we automate what users are doing manually? Look for patterns in behavior that could theoretically be handled by the system, automatically. If users always the same three actions in sequence, maybe that should be one automated flow — whether requiring one button press somewhere, or even…
• Can we make this happen in the background? Features that require user intervention feel like features. Things that just happen feel like magic.
• Can we combine multiple features into one seamless experience? Instead of having a whole feature for each related item, can we create one intuitive flow that handles everything? (In its simplest form, this can come down to solutions like putting like functionality into a single overflow menu.)

The most elegant solutions often involve removing complexity rather than adding features.

4. Make it feel natural

This is where we get more into art than science. You want your product to feel it couldn’t possibly work any other way.

• Think in terms of magic: If you had a magic wand, how would a given feature work? That idea you have in your head is probably closer to what users actually want than whatever specific feature they may be requesting. And then, the toughest part: how can you close the gap between magic and reality?
• Maintain context: Features that pull users out of their flow feel like features. Can the-thing-they’re-trying-to-do happen right where they already are?
• Embrace progressive disclosure: Not everything needs to be visible all the time. Yes, creating a single page with a button for every possible user need means that every possible user need is only a single click away — but that doesn’t sound like a good experience, now does it?
• Design as if documentation doesn’t exist: Users shouldn’t need a manual to figure out how to use your product. The right action should feel obvious at the right time.

Natural experiences feel like they were designed specifically for each user’s unique needs.

5. Test the invisibility

Here’s how to know if you’ve succeeded, or if you still have more work to do (but note… you always have more work to do):

• Watch new users: If they have to ask how to do something, it probably still feels too much like a feature.
• Listen for silence: The best features often generate the least feedback because they just work.
• Track feature discovery: How are users finding particular functionality? Through documentation (bad), or through exploration (good)?
• Look for natural adoption: Are existing users organically discovering and using the feature without prompting? (I.e., get rid of those “look over here, new feature alert” banners and callouts and modals.)
• Monitor feature mentions: In user interviews, do they talk about a capability as a feature, or just as part of how they work? This comes down to the specific wording they use — “…and then I check our progress on the home screen” is indicative of an experience, whereas “…and then I open up the dashboard, change the time range to include today, and click on the revenue metric icon” sounds like a feature.

The truest sign of success is when users can’t imagine how they worked without a feature, yet also can’t remember specifically when they started using it.

Your product doesn’t need more features. It needs more moments where users, instead of asking “how do I do that?”, say “of course it works that way” (or ideally, never say anything at all).

The next time you’re running through your roadmap of features, try this exercise: Take each item, and ask “how can we make the need for this disappear?” Not by ignoring it, of course, but by so seamlessly integrating it into the user experience that nobody even notices it’s there.

This is going to require a mindset shift, but you’ll be able to get there if you try.

1. Dig into why your users “need” certain functionality in the first place (it’s often not what they’re explicitly asking for)
2. Figure out where they’re struggling or frustrated (even if they don’t tell you with their words)
3. Get out of their way by removing stuff they don’t need (you don’t have to solve every problem for every user)
4. Make everything that remains feel natural (aka magic)
5. Prove to yourself that the changes are working (and then go back to step 1)

All this might mean shipping slower. It might mean saying “no” more often. It might mean completely rethinking parts of your product.

But the payoff? A product that users love without knowing why. Tools that feel like they were built just for them. Experiences so natural that users can’t imagine any other solution.

Because the best features aren’t features at all — they’re just the way things should work.