Pricing from a UX perspective: plans, anchors, and transparency
How to design a pricing page users understand: number of plans, comparison tables, anchors and decoys, and transparency without deceptive patterns.
What is pricing from a UX perspective?
It is applying experience design principles to how prices are presented: how plans are organized, what is compared, how charges are shown, and in what order options appear. Pricing strategy decides how much to charge; pricing design decides whether the user understands the offer and trusts it.
A useful distinction: design can make a decision clear or confusing, but it should not change the information the user receives. When the design hides, distracts, or exaggerates, it stops being pricing design and becomes a deceptive pattern.
Why does it matter to a designer?
Because the pricing page is one of the screens where trust is earned or lost in seconds. A user who does not understand what each plan includes leaves, and one who discovers a charge at the end of the process feels deceived. Both outcomes are bad for the business in the long run, even if they look good on a single metric in the short term.
It is also a cognitive load problem. Too many options and confusing comparisons force users to do work the design could have saved them.
How many plans should you show?
There is no ideal number of plans backed by conclusive evidence. A Setproduct design article argues that two plans reduce decision fatigue, and that four may require more explanation. That is the opinion of a template vendor, not a study.
The practical question is comparison. Smashing Magazine advises avoiding horizontal scrolling in tables on mobile, and suggests alternatives such as tabs, wrapping, or accordions. And as Hick’s law explains, more options usually take longer to decide between.
How should the comparison table work?
A comparison table helps you see what each plan includes, but it has reading problems. Smashing Magazine notes that users scan the page in a “lawn mower” pattern and lose their orientation as they scroll. Its recommendations include:
- Visible headers while scrolling, so users know which plan each column belongs to.
- Key features first, because they are the ones most often compared.
- Plans ordered from least to most expensive from left to right, with the standard and most popular plans toward the center.
- The remaining features on request, instead of showing everything up front.
Setproduct suggests using a table when there are several plans with many features, representing features with icons, and highlighting the most important ones. For advanced features, Nielsen Norman Group recommends progressive disclosure: show the most important options first and leave the detail for a clearly signposted second step, without going beyond two levels, since more levels usually hurt usability.
What are anchors and decoys?
An anchor is a reference price the user sees first, which influences how they judge the others. A decoy is a plan that, compared with others, pushes the decision toward a specific one. Wikipedia describes the decoy effect as the inclusion of an unattractive third option that is asymmetrically dominated: worse than one option in every respect and only partly worse than the other, which makes the dominating option look better.
It is a real behavioral tool, and it is easy to misuse. According to the same page, some research suggests the effect does not appear in realistic purchasing scenarios, for example when the options are not of equivalent value. And if it is used to force a decision the user does not understand, it stops being an improvement and becomes a deceptive pattern.
To go deeper into these patterns, the dark patterns page explains where the line is.
When should you NOT highlight a plan?
Highlighting a “popular” plan is valid if it is true. It is not valid when the highlight is just a tactic to push users toward a more expensive plan they do not need. Setproduct recommends using a “popular” badge sparingly and only for important information.
Nor should you hide the free or cheapest plan so it looks like it does not exist. That is not a decoy; it is hiding options.
How do you show prices transparently?
Setproduct recommends a consistent price format, such as “$10/month”, and advises against phrases like “starting at” or “from” when they do not clarify the real price. Smashing Magazine asks for transparent, honest, and clear pricing, without surprises.
The same applies to extra charges. A tax, a service fee, or a per-user cost should be visible before the user starts checkout, not at the final step. A charge that appears late usually causes abandonment and complaints.
Setproduct also suggests offering a free trial or money-back guarantee when the product allows it. That does not replace transparency, but it reduces perceived risk.
Example
Illustrative example: a design tool has three plans: Free, Pro, and Team. Its first version shows four columns with every feature in alphabetical order, inconsistent prices, and the phrase “from 9” on the Pro plan. The team reorders features by what buyers care about, shows prices as “9 dollars per month per seat”, makes the cost of each additional user visible before the payment button, and keeps Pro as the highlighted plan because it really is the most chosen. Testing afterward with usability sessions shows whether users understand the difference between plans without help.
Common mistakes
- Squeezing many plans into a table that forces horizontal scrolling.
- Ordering features alphabetically instead of by importance to the buyer.
- Using “from” or “starting at” without clarifying the real price.
- Showing extra charges only at the end of the process.
- Using decoys when the options are not comparable or the user does not understand the difference.
- Labeling a plan as popular when it is not.
To decide how to present options, competitive analysis shows how other products in the sector do it. And if you want to validate a new plan before publishing it, concept testing lets you test the idea with users. For the experimentation side, A/B testing tools explains which options exist.