How to Design Clear Pricing Tables

A useful pricing table lets someone answer three questions without opening a calculator or a second browser tab: Which plan fits my work? What will I actually pay? What happens if I choose it?

That sounds straightforward until you put real product details into the layout. One plan includes five editors, another charges per editor, annual billing is displayed as a monthly equivalent, and the feature that matters most is buried underneath twelve identical checkmarks. The cards can look polished while the decision remains difficult.

The worked examples use Fieldnote, a fictional collaboration service.

Define the choice before drawing the cards

Write the decision you expect a visitor to make in one sentence. For Fieldnote, it is: choose a workspace plan for a solo researcher, a small project team, or an organization that needs centralized administration.

Those are different operating needs. They are more useful starting points than deciding that every pricing page needs three columns. A product with one paid package may need a price explanation rather than a comparison. A service with separate products may need an initial product selector. Putting fundamentally different purchases into adjacent columns can imply that they are interchangeable when they are not.

Ask the product owner which facts actually change the choice. For our example, the important ones are active projects, included editors, guest access, and administration. Storage also varies, but it is unlikely to determine the first decision for the intended audience. This distinction gives the page an order: establish fit first, then expose the details needed to verify it.

Keep a small fact sheet outside the design. Record each plan’s name, audience, billing unit, included quantity, limit, upgrade condition, and purchase route. If the source says an item is still undecided, mark it as undecided. An attractive mockup is a particularly bad place to settle missing commercial policy by accident.

The fact sheet also protects against inconsistent revisions. If a team changes the included editor count, the plan summary, comparison row, calculator, and FAQ may all need attention. Treat those as different views of one fact, not independent pieces of copy that happen to contain the same number.

Pricing table design: shortlist first, compare second

Plan cards and a feature matrix do different jobs. The cards help a visitor form a shortlist. The matrix helps that visitor check the shortlist against specific requirements. Trying to put every detail into the cards produces long columns whose differences are hard to locate.

Figma’s pricing guidance distinguishes concise plan presentations from a fuller comparison table and recommends making billing units explicit near the price. That is a useful foundation for the structure here. Figma’s pricing page guidance.

For Fieldnote, the Solo card could describe independent projects, then show the price, active project limit, and guest access. The Team card could describe shared research, then show the price, included editors, and shared project capacity. The Organization card could explain centralized administration and its sales-led purchase route. There is no need to force an invented public number onto the last card if the commercial model requires a quote.

Keep the order of information consistent even when the values differ. If one card puts its billing terms below the button while another puts them beside the price, readers must search for the relationship. Alignment becomes a form of explanation: the same position means the same kind of information.

Read GitHub’s pricing page in two passes

The GitHub pricing page offers a useful real example of the distinction between a plan summary and a detailed comparison. The plan area establishes the available choices and purchase routes; the feature comparison below provides a different level of detail. The captured prices illustrate that page structure; check the live page for current terms.

Inspect the two areas with different questions. In the summary, can you identify which option is plausible for your team? In the matrix, can you verify the one requirement that would rule it out? This division is useful because an introductory card and a procurement check do not have the same information density. A card that carries every row from the matrix stops being a summary.

Ask a prospective buyer to choose a suitable plan and explain the commitment; those answers test what the layout communicates.

Calculate the bill the reader is actually choosing

For a separate per-seat example, imagine a fictional service called SeatMeter with a plan displayed as $12 per editor per month, billed annually, with a minimum of five editors. A three-person team does not necessarily owe $36 each month. Under those stated terms, the minimum annual commitment is $12 × 5 × 12 = $720.

This is where a pricing design often fails even though every individual number is accurate. The visual hierarchy makes the monthly equivalent memorable and the actual payment almost invisible. Ask someone to explain what they expect to be charged today. If they answer with the rate rather than the bill, making the rate larger will not solve the misunderstanding.

Avoid letting a savings badge obscure the baseline. If the annual option saves twenty percent against twelve monthly payments, say which monthly rate was used. If a promotion applies only to the first period, keep that condition close to the promotional amount. A permanent-looking badge attached to a temporary offer creates an expectation that a footnote may not undo.

The same discipline applies to included capacity. “Five editors included” and “minimum five paid editors” can produce the same initial team size while describing different commercial rules. Write the actual rule in the fact sheet, then make the card, matrix and checkout handoff use that same meaning.

Workspace pricing follows a different calculation

Keep amount, currency, billing unit, and commitment together. For annual subscriptions presented as a monthly equivalent, the total annual charge belongs in the same visual group.

Suppose Fieldnote Team costs $30 per workspace each month on monthly billing. The separate workspace-based annual offer costs $288 per workspace per year, equivalent to $24 per month. A clear annual card might display the monthly equivalent as its main number, followed immediately by a sentence explaining that $288 is billed annually. The visitor should not have to infer that twelve payments of $24 are available.

The difference between a workspace price and a seat price deserves equal care. “$24 per month” is incomplete if a six-person team will actually pay six times that amount. Show whether the price includes a fixed number of editors, applies to each editor, or starts at a minimum quantity. Put the quantity assumption in the same area as the price rather than in a distant tooltip.

For variable usage, explain the boundary before adding a calculator. A calculator without a visible basis can make an uncertain price look precise. State which usage is included, what triggers an extra charge, and whether the displayed estimate includes optional items. If there is no stable rate to calculate, explain what information the sales team needs instead.

Do not mix several units in one comparison row. A cell reading “10” and another reading “Unlimited” are ambiguous unless the row says what is being counted and over what period. “Active projects” differs from “Projects created per month.” The distinction can change the purchase even when the numbers look identical.

Treat the billing switch as a change of terms

Switching between monthly and annual billing should update every affected fact together. It is more than an animation applied to the headline number. The annual total, savings explanation, commitment wording, and destination of the purchase action must all remain consistent with the selected state.

In the Fieldnote example, monthly billing totals $360 across twelve months, while annual billing costs $288. The difference is $72, or twenty percent of the monthly-billing total. If the design displays that saving, keep its basis clear. Comparing a discounted annual amount with some other promotional rate would tell a different story.

The active choice needs an unambiguous label and state. Two words beside a small switch can leave people unsure whether the left label describes the current value or the available alternative. A segmented control with a visibly selected option is often easier to explain in a prototype. Whichever treatment you choose, the selected state must survive keyboard use and should not depend on color alone.

Switch the control while looking at a plan lower on the page. Can you still tell which billing period applies? A repeated billing label near a long comparison can be more useful than a control that disappears far above it. Repetition is justified when it prevents the price from losing its context.

Also decide what stays stable. Plan order and feature limits should not shift merely because the visitor changes billing frequency unless the actual offer changes. Unexpected rearrangement makes it harder to compare the two states and can look like the service has changed underneath the reader.

Build rows that can be compared honestly

Each row should ask one question and answer it for every plan. “Project capacity” can contain a number. “Guest access” might contain “Included” or “Not included.” “Support” needs a description if one plan offers email and another includes a named contact. A checkmark alone cannot express these differences.

Use the same unit and level of precision across a row. If the Solo column says “Three active projects,” do not write “Plenty of space to grow” in Team. The second phrase avoids the comparison the table exists to make. Put promotional language in the surrounding explanation and put the actual limit in the cell.

Distinguish absence from uncertainty. A dash might mean unavailable, not applicable, not disclosed, or zero. Choose explicit words when the distinction matters. If you use a compact symbol, provide a clear meaning and ensure assistive technology receives it as well. A buyer should never have to guess whether an empty cell is a limitation or a publishing error.

Feature names should also remain stable. Calling the same capability “Shared folders” in the first plan and “Collaborative spaces” in the second may create an apparent upgrade that does not exist. When a capability truly changes, describe the change: more members, longer history, different permissions, or a different service commitment.

Group rows around recognizable questions. Fieldnote could use sections for project work, collaboration, and administration. The groups should help someone find an answer, not reproduce the internal ownership chart of the product team. If a buyer thinks in terms of sharing access, make that path obvious even if several engineering teams own the underlying features.

Be cautious with “Everything in the previous plan.” It shortens a card, but it forces readers to look elsewhere to understand a higher tier. That can be acceptable in a brief overview. In a matrix, repeating the actual value is usually more useful because each row remains independently comparable.

Show a recommendation that has a reason

A highlighted plan should explain its fit. “For teams sharing research across projects” gives someone a reason to consider Fieldnote Team. “Best value” asks the reader to accept a judgment without knowing its basis. “Most popular” is a factual claim and needs evidence; it should not be a decorative substitute for a recommendation.

Use emphasis to establish a starting point while keeping alternatives readable. A stronger border, a small label, or a restrained surface change can do that. Enlarging the middle card so much that surrounding terms become difficult to scan is a poor trade. The user still needs to compare the highlighted option with the others.

Check the page with that highlight removed. If the offer becomes impossible to understand, the emphasis was carrying too much explanatory weight. The plan names, audience descriptions, and visible differences should establish a reasonable choice before color adds priority.

Handle narrow screens without hiding the tradeoff

Stacking plan cards is straightforward; preserving comparison is harder. Once each plan occupies a separate screen, remembering whether the first plan included a feature becomes part of the task. Do not assume that a clean vertical layout is automatically an easy comparison.

For a short set of plans, keep a consistent feature order in the stacked cards. For a longer matrix, consider a narrow comparison that lets someone select two plans, or a horizontally scrollable table with clear orientation. The right option depends on whether visitors mainly read one plan or compare several particular values.

An accordion can reduce initial length, but it also conceals information. Keep essential limitations and billing terms outside collapsed sections. If a person must expand every plan to discover which includes guest access, the accordion has merely distributed the same effort across more interactions.

When you use a real data table, preserve its structural relationships. W3C’s tables tutorial explains how header cells and data cells need to be associated so that the relationships are available to assistive technology. A grid of visually aligned text is not an equivalent implementation. W3C’s accessible tables tutorial.

Test the narrow version with a concrete comparison: find the least expensive option that supports six editors and twenty active projects. Those invented requirements expose whether the layout preserves the information needed for a choice. Merely checking that the page fits within the viewport will not answer that question.

Match the action to the next step

The button should describe the immediate action the visitor can actually take. Starting a trial, creating a free workspace, selecting a paid subscription, and contacting sales are different steps. Reusing “Get started” across all of them makes a consistent row of buttons but leaves the interaction vague.

Put important conditions near the relevant action. If a trial requires a payment method, say so before the person proceeds. If an organization plan begins with a conversation, avoid a button that implies an immediate checkout. The purpose is to set an accurate expectation, not to explain the entire purchase process inside the card.

Consider people who already have a subscription. A generic public pricing table can send them into a duplicate signup flow. The eventual product implementation may need a current-plan state or a route to account settings. Even if the prototype does not implement account logic, record this state so the design is not evaluated only for first-time visitors.

Do not use a disabled button to represent every unavailable choice. If eligibility depends on an account condition, explain the condition. A disabled control without an explanation gives the user no way to determine whether the problem is a limit, a temporary error, or an intentional rule.

The captured GitHub cards make this distinction concrete. Team offers “Continue with Team”; Enterprise offers both a trial and contact with sales. The second card represents two routes into the same plan, rather than two different features of that plan. In a review, follow each route and check what information the visitor must supply next. A consistent button color can preserve the page’s visual rhythm while the labels remain specific about the next step.

Review a draft with decision tasks

A visual review becomes more useful when each reviewer has a question to answer. Give one person the solo scenario and another the growing-team scenario. Ask them to choose a plan and explain the facts that led to the choice. Their reasoning reveals ambiguity that an open-ended request for feedback may miss.

For Fieldnote, one task could involve a researcher with two projects and several guests. Another could involve six editors, while a third requires organization-wide administration. Include a scenario that should rule out the highlighted plan. Otherwise the review only checks whether the visual emphasis works, not whether the comparison supports a different conclusion.

Then ask each person to state the amount charged immediately and the billing commitment. An incorrect answer is a problem even if the correct words technically appear somewhere on the page. Move or rewrite the explanation based on the misunderstanding rather than automatically adding another footnote.

Review the table with a deliberately awkward value as well: a long feature name, an unavailable feature, or a plan whose price is negotiated. These are not rare layout exceptions to defer until development. They determine whether the comparison structure can represent the actual offer.

In OpenDesign, an HTML preview can support this visual review. Comments can identify a misleading price group or a comparison row that loses alignment, and targeted text or style edits can refine the presentation. Supply approved plan facts as design context. Verify billing calculations, account eligibility and checkout behavior in the implemented flow.

Before handing off the page, compare every visible price and limit with the fact sheet. Check both billing states, every purchase action, and the narrow layout. The table is ready when a reader can explain a suitable choice and its terms accurately, including the cases where the highlighted plan is not the right one.