How Do You Design a Feature People Actually Adopt?

How do you design a feature people actually adopt?

By answering four questions before you build it: when would someone need this, how will they find out it exists at that moment, what does the first successful use look like, and what makes them come back. A feature that fails any of these fails regardless of how well it is built.

We design product interfaces alongside the marketing sites that sell them, which gives us an odd vantage point. We see the launch announcement and the usage data. The gap between them is almost never about the feature being bad.

This is the framework we use, in the order the questions have to be answered.

Why do good features go unused?

Because adoption depends on a chain of four things and product teams usually invest in one of them. The feature has to be discovered, at a moment when it is relevant, by someone who understands what it will do, who then succeeds on the first attempt. Break any link and the rest does not matter.

The common failure is discovery. The feature exists behind a menu the person has no reason to open, announced once in a changelog nobody read, at a time when they were not doing the task it helps with. It is not undiscovered because it is hidden. It is undiscovered because nobody needed it on the day it was mentioned.

The second most common failure is the first attempt. Someone finds the feature, tries it, gets a confusing result, and files it mentally under does not work. Winning them back is far harder than being good the first time. Our piece on SaaS onboarding flow design covers the first run version of the same problem.

Question one: when would someone actually need this?

Write the trigger as a moment, not as a persona. Not power users need bulk editing. Something like: a person has just filtered to 40 records and realises they all need the same status change. That sentence tells you where the feature has to appear and what it must be called.

If you cannot describe the trigger moment, the feature is a capability rather than a solution, and capabilities do not get adopted. They get demoed.

The test is whether a designer could point at a screen and a state. If the answer is anywhere in the app, at any time, the feature has no home, and it will end up in a settings page where features go to be forgotten.

Question two: how will they find out at that moment?

By the feature being present in the place the trigger happens, not by being announced elsewhere. Discovery that depends on memory is discovery that fails, because the person learned about it on Tuesday and needed it on Thursday.

This is where progressive disclosure earns its keep. Jakob Nielsen's article on the technique, published on 3 December 2006, describes deferring advanced or rarely used features to secondary screens, showing only a few of the most important options initially and offering a larger set upon request. He notes it improves learnability, efficiency and error reduction at once.

The important nuance is that progressive disclosure is not the same as hiding. Nielsen's guidance is to disclose up front whatever users frequently need, and to determine the split through task analysis, field studies and usage data rather than by intuition. A feature relevant to a common task belongs in the primary view even if it feels advanced to the team that built it.

Question three: what does the first success look like?

Define it concretely, as an observable end state, before you design a single screen. The first successful use of a bulk edit feature is 40 records changed and a message confirming it. The first successful use of a report builder is one report saved that the person would actually send to someone.

Then count the steps between the trigger and that end state, and remove half of them. Every step is a place to abandon, and the first attempt has the least patience of any attempt that will ever happen.

Design the empty state as part of this, not as an afterthought. The first time someone opens a feature, it is empty, and that screen is doing more persuasion than any tooltip. Our piece on loading and empty states is the longer argument.

Question four: what brings them back?

A result they can see, or time they can feel. If the feature saved them fifteen minutes, the interface should make that legible, by showing what it did rather than silently succeeding. Silence reads as nothing happened.

Repeat use also depends on the feature being where they left it. Moving a feature after launch, even to a better place, resets adoption among the people who had just learned it. If you are going to move it, move it early and once.

And make the second use cheaper than the first. If the feature required configuration, remember that configuration. Asking the same five questions every time is how a useful feature becomes an occasional one.

How does this change what you build first?

It moves the entry point earlier in the plan. Most teams build the feature and then decide where the button goes. Under this framework the trigger moment and the entry point are decided first, and they constrain the design of the feature itself.

That reordering has a cost. Sometimes you discover the feature has no natural home, which means either the feature is wrong or the surrounding product is. Both of those are painful findings and both are cheaper before the build than after.

It also tends to shrink scope. When you design from a single trigger moment, the version that serves that moment is smaller than the version that serves every imagined use. That smaller version is the one that gets adopted.

What should you measure?

Four numbers, matching the four questions. How many people encountered the entry point. How many started. How many reached first success. How many came back within a fortnight. Each drop tells you which question you answered badly.

A steep drop between encountered and started is a naming or clarity problem. Between started and first success is a flow problem. Between first success and return is a value problem, and that is the expensive one, because no amount of interface work fixes a feature nobody needed.

Measuring only total usage hides all of this. A flat adoption line could be any of the four failures and the fix is different for each. Our article on SaaS dashboard UX covers making numbers like these legible to the team.

Does this apply to AI features too?

Yes, with one addition: trust is part of first success. A person's first use of an AI feature is also their first test of whether it is right. If the output is plausible but wrong and they cannot tell, you have not gained an adopter, you have created a future complaint.

So the first success definition for an AI feature includes the person being able to verify the result. Show what it used, let them correct it, and make the correction stick. That is more work than a confidence score and it is the part that earns repeat use.

The discovery question is different too. People are actively looking for AI features right now, which means discovery is temporarily easier and the first success bar is temporarily higher. Both of those will normalise.

What is the fastest way to apply this to a feature you already shipped?

Take one underused feature and answer the four questions honestly about it as it exists today. Most teams find they cannot answer question one, which explains everything else.

Then change only the entry point. Move it to the moment the trigger happens, name it after the outcome rather than the mechanism, and measure for a month. That is usually a small change and it is the one most likely to move the number.

Rebuilding the feature is the expensive response and it is rarely the right one. The feature is usually fine. It is in the wrong place, with the wrong name, at the wrong moment.

What does this framework not solve?

Whether the feature should exist. Nothing here tells you that a feature is worth building, and applying the framework rigorously to something nobody wants just produces a well designed, well placed, unwanted feature.

The question one test does filter some of that out, since a feature with no describable trigger moment is usually a feature with no demand behind it. But it is a weak filter and it should not be doing the job of talking to customers.

If you want help working through these four questions for a feature that is not landing, or designing the entry points for one you are about to build, we are happy to walk through it. Find us at phoenix.studio.