Designing Digital Products People Actually Want to Use

Most digital products that fail are not broken. They pass testing, launch on schedule and collect their first sign-ups without complaint. Then usage thins out. Accounts go quiet, the team adds features to win people back, and the product gets heavier without getting more useful.

The cause is rarely a missing feature or the wrong shade of button. More often, the product asks more of people than it gives back, at exactly the moment they are deciding whether it deserves their time. Designing products people want is largely the work of getting that exchange right.

Start with the job, not the feature list

People do not so much buy a product as hire it to make progress in a particular situation, the idea Clayton Christensen and his co-authors call jobs to be done. A clinic’s booking portal is hired to get a patient an appointment without a phone call. An internal stock tool is hired to stop a warehouse manager chasing three colleagues for one number. The feature list is how you deliver that progress, not the reason anyone shows up.

The most useful question in product thinking is what people do today instead. There is almost always a workaround: a spreadsheet, a WhatsApp group, an email thread, a call to the person who knows. That workaround is your real competitor, and it has one large advantage: people already know how to use it.

If booking through the portal takes longer than ringing reception, patients will ring reception. A new product has to beat the workaround clearly on the job that matters, not on capabilities nobody asked for.

Before designing a single screen, write down three things:

• The job, in one sentence, in the customer’s words.
• The workaround it replaces, and what is genuinely good about it.
• The moment of value: the point at which someone would say “that was worth it”.

Usable is the floor, not the goal

Usability is the well-understood part. Jakob Nielsen’s 10 usability heuristics, refined in 1994 and unchanged since, are still a reliable checklist: show people what the system is doing, prevent errors before they happen, let people recognise options rather than remember them, and give them a way back when they make a mistake.

But a product can satisfy every heuristic and still go unused. Usability tells you whether people can complete a task, not whether they will bother. Products people want add two things on top: value that arrives early, and value that repeats.

Conceptual model

1. Repeated valuePeople come back and do it again unprompted.
2. Early valueThe first session already feels worth it.
3. UsabilityPeople can complete the task they came for.

Whether they will botherWhether they can

People rarely adopt a product; they adopt a shortcut to something they already wanted.

Shorten the path to the first useful moment

The first session is where a product is most fragile. Nobody has seen any value yet, so every question and every empty screen is a reason to leave.

Consider two invoicing tools. The first asks for registration details, a logo, tax settings and bank information before you can create anything. The second lets you draft an invoice straight away and asks for each detail at the point it is needed. Both collect the same information, but only one lets a busy owner see the product working within minutes.

A few patterns help consistently:

• Defer what is not needed yet. Progressive disclosure moves advanced or rarely used features to a secondary screen, which makes an application easier to learn and less error-prone. Setup questions deserve the same treatment.
• Choose defaults with care. A default is a decision made on the user’s behalf, and people often leave it untouched, so give it as much thought as any screen.
• Show real content early. Sample data, a template or a prefilled example teaches more than a guided tour of empty screens.
• Let people leave and come back. Save progress automatically. A half-completed form that disappears is one of the quickest ways to lose someone for good.

Remove accidental friction, keep intentional friction

Not all friction is a problem. The work is telling the two kinds apart.

Accidental friction is effort that serves nobody: labels written in internal jargon, an account required before any value is shown, requests for information you already hold, dead ends with no next step, error messages that say something went wrong without saying what. Each is a small tax, and people pay it in patience until they stop paying.

1. NeedProgress on a job they already have.Slower than the old way
2. DiscoveryTo see it working before setting everything up.Sign up before any value
3. InteractionLabels and controls they already recognise.Internal jargon in labels
4. FeedbackTo know what the system did.Vague errors
5. ConfidenceA clear next step, and a way back from mistakes.Dead ends, no next step
6. CompletionThe job finished in one go.Asked twice for details

Where friction can break the journey

Intentional friction is effort that protects the person: a confirmation before deleting a project, a review step before a payment, a short pause before sending money to a new recipient. Removing these makes a product faster and worse.

The test is whether a step helps the user avoid a mistake they would regret, or mainly helps the business. If the honest answer is the business, the step needs a stronger reason to exist.

Behavioural design without manipulation

BJ Fogg’s Behavior Model offers a useful lens: behaviour happens when motivation, ability and a prompt come together at the same moment. When something does not happen, at least one of the three is missing.

Most teams reach for motivation first, with more persuasive copy or bigger incentives. The more dependable lever is usually ability: make the action smaller, clearer and quicker. The next is timing. A reorder reminder that arrives when a customer’s supply is likely to be running low does more than a generic weekly email, because the prompt lands when the motivation already exists.

Motivation

How much they want to act.

• Persuasive copy and bigger incentives
• Where most teams start

Ability

How easy the action is.

• A smaller, clearer action
• Usually the more dependable lever

Prompt

A cue at the right moment.

• Timing is the next lever
• Lands when motivation already exists

There is a line, and people notice when it is crossed: pre-ticked consent boxes, cancellation hidden behind several screens, buttons that shame people for declining, countdown timers that reset on refresh. These patterns can lift a single metric while wearing down the trust that brings people back. A practical rule: if you would be uncomfortable explaining a design decision to the customer it affects, do not ship it.

Familiar beats clever

The case for familiar patterns on websites, set out in why great websites feel effortless, applies with more force inside a product. People use it repeatedly, often under time pressure, and every novel interaction is something to learn before the real task can begin.

Spend originality where it creates value: the service, the content, the tone. Keep navigation, forms, search and settings where people expect them, and give the same action the same name, appearance and place every time. A shared design system holds that consistency far better than memory does.

Familiar does not mean bare. Stripping a screen to its minimum can hide the very cues people rely on, which is why minimalism and simplicity are not the same thing.

Design for the conditions people are actually in

Products are designed on large screens in quiet offices and used everywhere else. A field technician closing a job on a phone with one hand. A parent booking an appointment late at night. Someone on a weak mobile connection, working in their second language, or interrupted halfway through.

Designing for those conditions is mostly a matter of discipline, and each habit below answers one of them.

Habit	In practice
Generous touch targets	Primary actions that are easy to hit with a thumb on a moving train, not only a cursor at a desk.
Forgiving inputs	Phone numbers with spaces, familiar date formats and small spelling mistakes in search, accepted the way people actually type them.
Responsiveness people can feel	Every tap acknowledged immediately, even on a weak connection or when the work takes longer.
Plain language	Labels and messages anyone can follow, including someone tired, distracted or in their second language.

Write every label and message for someone who is tired and distracted, because sometimes they will be.

Measure behaviour, not opinions

Feedback sessions and stakeholder reviews have their place, but they report opinions. Usability research has long advised teams to watch what people actually do, not what they say they do or predict they will do. The signals worth tracking are usually simple:

• Whether people complete the core task, and where they stop.
• Whether they come back and do it again without being prompted.
• Which questions reach support, and whether they fall after a change.
• What people search for inside the product, which often reveals what they cannot find.

Then change one thing at a time and watch what it does to those signals. When a redesign moves ten things at once, nobody can tell which one made the difference.

Before you build the next feature

When the roadmap is full, ask of each item:

1. Does it make the core job faster, clearer or more reliable?
2. Would someone using today’s workaround notice the difference?
3. Does it add a step, and if so, who does that step serve?
4. Will we know within a few weeks whether it worked?

Often the most valuable next release takes something away.

Race the workaround

Pick the one task your product exists for, and ask someone who does that job every day to do it twice: once in your product, and once the old way, with the spreadsheet, the phone call or the message thread it was meant to replace. Time both, and count the steps.

If the workaround wins, or comes close, that comparison is a more honest roadmap than most planning documents. Close the gap on that one task before anything new is added.

How to run the race

1. Pick one taskThe job your product exists to do.
2. Run it twiceA daily user, in yours and in the old way.
3. Time and countMinutes and steps, for each way.
4. Close the gapFix that task before adding anything new.

Setting a product against the habits it has to replace is also where our digital experience practice starts with product teams. From there, the work is refining the interface, the flows and the words until the useful path is the obvious one.