Pricing Pages and Plan Tables: UX principle for coding agents

A pricing page is a decision surface, not a feature list. The visitor arrives with one question, which plan is for me, and every element either answers it or delays it. Most pricing pages fail because they present plans as equal columns and leave the choosing to the reader. Choosing is the work. Do it for them, and show why.

This doc covers the plan table itself and the page around it. The comparison psychology it leans on lives in comparison.md and cognitive-laws.md. Checkout after the choice lives in commerce-checkout.md. The marketing page that wraps it lives in ui/marketing-pages.md.

Name a default. A visitor with three equal options reads three times and decides once, badly. Mark one plan as the one most people should pick, and let its card carry more weight: a filled header, a slightly raised surface, or a small label inside the card. The other cards stay quiet.
Put the recommended plan where the eye lands. In a three-plan row that is the middle. In a two-plan row it is the one the reader reaches last, which is the right in a left-to-right layout and the left in a right-to-left one. On one column it goes second, after the reader has seen the entry price.
Do not raise every card. Elevation is comparative. If all three cards carry the same shadow, none of them is recommended, and the page has told the reader nothing (see ui/depth-and-surfaces.md — Elevation is comparative).
Say who each plan is for, in the card. One line under the plan name, describing the person, not the volume: "For a solo designer shipping client work" beats "Up to 3 seats". The number belongs in the feature rows.

Price the Anchor, Then the Rest

Show the highest-value plan on the same screen as the entry plan. A price read alone is expensive. A price read beside a larger one is reasonable. This is reference dependence, and it is why a lone plan converts worse than the same plan in a set (see cognitive-laws.md — Reference Dependence).
Lead with the price the reader will pay. If the headline number is annual-billed-monthly, the reader who picks monthly feels tricked at checkout. Show the number the selected billing period actually charges, and put the other period's saving beside it as a second line.
Make the billing toggle change the number in place. The toggle is a control the reader operates to answer a question. If prices swap without motion, the reader misses that anything changed. Animate the number, briefly, and never longer than 200ms. Under prefers-reduced-motion swap the value with no transition, since the change still needs to be noticed (see ui/perceived-speed.md and ui/accessibility.md — Reduced motion).
State the currency and the period every time. "$19" is not a price. "$19 per user, per month" is. Abbreviate the period in the card if space is tight, but never drop it.
Fold mandatory charges in. Tax, seat minimums, and setup fees belong in the headline number or in a line directly under it. A fee that first appears at checkout costs you the sale and the next visit.

Build the Feature Rows Around Differences

Order rows by what decides the choice. The row that moves a reader from one plan to the next goes first. Rows that are identical across every plan go last, or into a collapsed group, because they carry no decision.
Repeat the shared rows anyway. A plan that shows only what it adds reads as a plan that lacks everything else. Show the full set, with the shared rows quiet and the differentiating rows at normal weight.
Write feature rows as capabilities, not as internals. "Publish to your own domain" beats "Custom CNAME support". If the term is the one your audience already uses, keep it exact (see microcopy.md).
Use one symbol for included and one for absent, and label both. A tick and a dash are not self-explanatory to a screen reader. Give each cell an accessible name, "Included" or "Not included", and never carry the meaning in colour alone (see ui/accessibility.md).
Put limits as numbers, not as adjectives. "Unlimited projects" is a claim. "Up to 50 projects" is a fact the reader can act on. If a limit is genuinely absent, say unlimited once and mean it.

Handle the Comparison Table Separately

Cards decide, the table confirms. The card row is for choosing. A full comparison table, every feature against every plan, is for a reader who has narrowed to two and wants to check one detail. Put it below the cards, not instead of them.
Keep the plan header visible while the table scrolls. A reader who has scrolled past the header is reading unlabelled columns. Pin the header row.
Group rows by area and let a group collapse. A forty-row table with no grouping is a wall. Six groups of seven rows is a document.

Small Screens Change the Shape, Not the Order

Stack the cards, keeping the recommended plan second. The reader should meet the entry price, then the recommendation, then the top plan. A recommended card that lands first reads as the only card.
Never turn the comparison table into a horizontal scroll on a phone. A plan table scrolled sideways loses the comparison that is its whole purpose. Give each plan its own stacked block with its own feature list, or let the reader pick two plans to compare. A data table may scroll sideways deliberately; a plan table may not, because comparison is the only thing it is for (see responsive.md — Tables on Small Screens).
Keep the billing toggle above the first card, in reach of the thumb. A toggle that sits above a long stack means the reader scrolls back to change it. Consider repeating it once at the end.
Do not shrink the price. The price is the largest number on the page at every width. If something must get smaller on a phone, it is the feature rows, not the price.

Say What Happens Next

Label the action with the outcome, not the plan. "Start the free trial" and "Talk to us" tell the reader what the next screen is. "Pro" as a button label tells them nothing (see microcopy.md).
State the commitment beside the action. No card needed, cancel any time, and how long the trial runs. One quiet line under the button removes the hesitation the button created.
Give the enterprise plan a different action, not a hidden price. "Contact us" is honest when the price genuinely varies. It is dishonest as a way to hide a number that does not.
Show the current plan as current. A signed-in reader on a pricing page needs their own plan marked, with the action changed to reflect a move: upgrade, downgrade, or the plan they already have, disabled with a reason.

Do Not

Do not use a countdown or a fake scarcity line. The reader who notices costs you trust permanently, and pricing is where trust is measured (see anti-patterns.md).
Do not hide the cheapest plan below the fold. If the entry plan is real, it belongs in the card row. If it is not real, remove it.
Do not pre-select the most expensive billing period without saying so. Defaults are a choice you make for the reader. Make one that survives being noticed.
Do not put the money-back guarantee, the logos, and the FAQ between the cards and the action. Everything between a decision and its button is a reason to leave.

Checklist

One plan is recommended and reads as recommended, without every card being raised
The headline price matches the selected billing period, with currency and period stated
Mandatory fees are in the headline number or directly under it
Feature rows lead with what differs and state limits as numbers
Included and absent cells carry an accessible name, not colour alone
The comparison table pins its header and groups its rows
On a phone the cards stack with the recommended plan second, and no table scrolls sideways
Every action says what happens next, with the commitment beside it
A signed-in reader sees their current plan marked

Recommend One Plan