如何设计清楚易懂的价格表

好用的价格表应该让人不用打开计算器，也不用另开一个浏览器标签页，就能回答三个问题：哪个方案适合我的工作？我实际需要付多少钱？选择这个方案后，接下来会发生什么？

乍看之下，这件事并不难，直到你把真实的产品细节放进布局里：一个方案包含五名编辑者，另一个按编辑者人数收费；年付金额显示的是折算后的月均价格；最关键的功能，却埋在十二个一模一样的勾号下面。卡片看起来可以很精致，但用户仍然难以做出决定。

下文以虚构的协作服务 Fieldnote 为例，具体说明这些设计问题。

画卡片之前，先定义用户要做的选择

先用一句话写清楚，你希望访客做出什么决定。对 Fieldnote 而言，这句话是：为独立研究者、小型项目团队，或需要集中管理的组织，选择合适的工作区方案。

这几类用户有不同的工作需求。从这些需求出发，比先认定所有价格页都必须有三列更有帮助。如果产品只有一个付费套餐，页面可能只需要解释价格，无须做方案比较。如果服务提供的是几个独立产品，页面可能需要先让用户选择产品。把本质上不同的购买选项并排放进相邻列，会暗示它们可以互相替代，而事实可能并非如此。

向产品负责人确认，哪些事实真正会改变用户的选择。在这个例子中，关键因素是活跃项目数、包含的编辑者人数、访客访问权限和管理能力。各方案的存储空间也有差别，但对目标用户来说，它不太可能决定第一轮选择。区分这些信息，才能安排页面顺序：先帮助用户判断是否适合，再展示核实这一判断所需的细节。

在设计稿之外，单独维护一份简明的方案事实表，记录每个方案的名称、适用人群、计费单位、包含数量、限制、升级条件和购买路径。如果资料中某一项尚未确定，就明确标记为待定。不要在制作漂亮的设计稿时，无意间替产品定下了尚未敲定的商业政策。

这份事实表还能防止修改后出现前后不一致。比如团队更改了方案包含的编辑者人数，方案摘要、比较表中的对应行、计算器和常见问题都可能需要同步检查。它们是同一个事实的不同呈现，而不是几段恰好包含同一数字、可以各自修改的文案。

价格表设计：先缩小范围，再逐项比较

方案卡片和功能比较矩阵承担不同任务。卡片帮助访客筛出几个候选方案；矩阵则让他们根据具体要求，进一步核实这些候选方案。试图把所有细节都塞进卡片，只会得到几列很长的内容，让方案之间的差别更难找到。

Figma 的价格页设计建议区分了简洁的方案介绍和更完整的比较表，并建议在价格附近明确标出计费单位。这些建议可以作为本文页面结构的基础。参见 Figma 的价格页设计建议。

以 Fieldnote 为例，Solo 卡片可以先说明它适合独立项目，再列出价格、活跃项目上限和访客访问权限。Team 卡片可以先介绍共享研究的用途，再给出价格、包含的编辑者人数和共享项目容量。Organization 卡片则可以解释集中管理能力，以及通过销售人员购买的路径。如果商业模式要求单独报价，就没有必要硬给最后一张卡片编出一个公开价格。

即使各方案的具体数值不同，信息出现的顺序也应保持一致。如果一张卡片把计费条款放在按钮下面，另一张却放在价格旁边，读者就必须自行寻找它们之间的关系。对齐本身也在解释内容：相同的位置，意味着相同类型的信息。

分两遍阅读 GitHub 的价格页

GitHub 价格页提供了一个真实例子，便于理解方案摘要与详细比较的分工。上方方案区说明有哪些可选方案，以及如何购买；下方功能比较则提供另一层次的细节。截图中的价格用于说明页面结构，当前条款应以实际页面为准。

检查这两个区域时，要分别提出不同的问题。在摘要里，你能否找出一个可能适合自己团队的方案？在比较矩阵里，你能否核实那个足以排除该方案的关键要求？这种分工很有用，因为入门介绍卡片和采购核对需要的信息密度并不相同。如果卡片承载了矩阵中的每一行，它就不再是摘要了。

请一位潜在买家选出适合的方案，再解释选择后需要承担的付费义务。他的回答可以帮助你检验，布局实际上向读者传达了什么。

算清读者实际要支付的账单

再单独看一个按席位计费的例子。假设虚构服务 SeatMeter 的某个方案标价为每位编辑者每月 12 美元，按年收费，最低购买五个编辑者席位。那么，一个三人团队未必只需每月支付 36 美元。按照这些条款，最低年度付费金额是 12 美元 × 5 × 12＝720 美元。

价格设计经常在这里出问题，即使页面上的每一个数字本身都准确无误。视觉层级让人记住折算后的月均价，却几乎注意不到实际付款金额。请用户说说，他预计今天会被扣多少钱。如果他回答的是单位费率而不是账单金额，继续放大费率数字并不能消除误解。

不要让“节省费用”的标签遮住比较基准。如果年付相对于连续十二次月付可以节省 20%，就说明比较采用的是哪一个月付价格。如果促销只适用于首个付费周期，就把这一条件紧挨着优惠金额展示。临时优惠配上看起来长期有效的标签，会制造一种预期，而角落里的脚注未必能纠正它。

方案包含的容量也要这样处理。**“包含五名编辑者”和“至少为五名编辑者付费”**可能对应同样的初始团队人数，却表达了不同的商业规则。先在事实表中写清实际规则，再确保卡片、比较矩阵和进入结账流程时的说明，都使用同一个含义。

按工作区计费，需要另一套计算方式

把金额、币种、计费单位和付费承诺放在一起。 如果年订阅以折算后的月均价格展示，全年实际收费总额也应放在同一个视觉组中。

假设 Fieldnote Team 选择月付时，每个工作区每月收费 30 美元。另一个按工作区计费的年付选项，每个工作区每年收费 288 美元，折合每月 24 美元。一张解释清楚的年付卡片，可以把月均价格作为主数字，紧接着说明每年一次收取 288 美元。访客不应该还需要自行判断，是否也能选择每次付 24 美元、分十二次付款。

按工作区计费和按席位计费之间的差别，同样需要仔细说明。如果一个六人团队实际需要支付六倍的金额，那么只写“每月 24 美元”就不够完整。要明确这个价格是包含固定数量的编辑者、对每位编辑者分别收费，还是有最低购买数量。数量假设应该和价格放在同一区域，而不是藏在远处的提示框中。

如果费用随用量变化，应先解释计费边界，再添加计算器。看不到计算依据的计算器，会让本来不确定的价格显得很精确。说明方案包含哪些用量、什么情况会触发额外收费，以及显示的估算是否包含可选项目。如果没有稳定费率可供计算，就改为解释销售团队需要哪些信息才能报价。

同一行比较中不要混用多个单位。如果一个单元格写“10”，另一个写“不限量”，但行名没有说明统计对象和时间周期，这些值就有歧义。“活跃项目数”和“每月创建的项目数”并不相同。即使数字看起来完全一样，这一差别也可能改变购买决定。

把计费周期切换视为条款变更

在月付和年付之间切换时，所有受到影响的事实都应一起更新。这不只是给主价格数字加一个动画。年度总额、节省金额的解释、付费承诺的措辞，以及购买按钮的目标去向，都必须与当前选中的状态保持一致。

在 Fieldnote 的例子中，连续月付十二个月合计 360 美元，年付则是 288 美元。两者相差 72 美元，也就是月付总额的 20%。如果设计中展示了节省金额，就要把这个基准解释清楚。拿折扣后的年费与另一种促销费率比较，表达的就会是另一回事。

当前选项需要有明确无歧义的标签和选中状态。小开关旁边的两个词，可能让人搞不清楚：左侧标签说的是当前值，还是可以切换到的另一个值？在原型中，使用能明显看出哪一项被选中的分段控件，通常更容易说明。无论采用哪种形式，都要确保用键盘操作时，选中状态仍然清楚，而且不能只靠颜色表达。

一边查看页面较下方的某个方案，一边切换计费周期，看看你是否仍能分辨当前适用的周期。对于很长的比较表，在附近重复标注计费周期，可能比远在上方、已经看不见的切换控件更有用。当重复能防止价格脱离上下文时，这样的重复就有价值。

同时要明确，哪些内容应该保持稳定。除非实际售卖条件发生变化，否则用户仅仅切换计费频率，不应导致方案重新排序或功能上限改变。意外的重新排列会妨碍比较两个状态，还可能让读者以为，服务内容也随着操作发生了变化。

让每一行都能进行真实的比较

每一行都应该提出一个问题，并为每个方案给出答案。“项目容量”可以填写一个数字；“访客访问权限”可以写“包含”或“不包含”；如果一个方案只提供邮件支持，另一个提供指定联系人，“支持”这一行就需要文字说明。单靠一个勾号无法表达这些差别。

同一行要使用一致的单位和精度。如果 Solo 列写的是“三个活跃项目”，Team 列就不要写“充足的成长空间”。后一种说法回避了这张表本应帮助用户完成的比较。宣传性语言可以放在周围的说明中，单元格里则应填写实际限制。

区分“不提供”和“尚不确定”。一个短横线可能表示不可用、不适用、未披露，也可能表示零。如果区别会影响判断，就使用明确的文字。如果要用简短符号，也要说明它的含义，并确保辅助技术同样能获得这一含义。买家不应还要猜测，空白单元格究竟代表功能限制，还是发布时出了错。

功能名称也应保持一致。如果同一个能力在第一档方案里叫“共享文件夹”，到第二档却叫“协作空间”，读者可能以为出现了实际上并不存在的升级。如果能力确实有变化，就描述真正的变化：成员更多、历史记录保留更久、权限不同，或服务承诺不同。

围绕用户熟悉的问题给行分组。Fieldnote 可以分为项目工作、协作和管理几个部分。分组应帮助用户找到答案，而不是照搬产品团队内部的职责划分。如果买家是从共享访问权限的角度思考，就应让这条查找路径足够明显，即使底层功能由多个工程团队负责。

谨慎使用“包含上一档方案的全部功能”。这句话能缩短卡片，却迫使读者到别处查阅，才能理解高档方案到底包含什么。在简短概览中，这样做或许可以接受；但在比较矩阵中，直接重复实际值通常更有用，因为每一行都能独立进行比较。

为推荐方案给出理由

被突出显示的方案，应该解释它为什么适合某类用户。“适合跨项目共享研究的团队”，给出了考虑 Fieldnote Team 的理由。“最超值”却要求读者在不知道依据的情况下接受判断。“最受欢迎”则是一项需要证据支持的事实主张，不应被用作装饰，代替真正的推荐理由。

通过适当强调给读者一个起点，同时保证其他选项仍然容易阅读。更醒目的边框、小标签，或克制的底色变化，都可以达到这个目的。如果中间卡片被放得太大，以至于周围方案的条款难以扫读，这种取舍就得不偿失。用户仍然需要把突出显示的方案与其他方案比较。

去掉这层突出效果，再检查一次页面。如果没有高亮就无法理解售卖内容，说明视觉强调承担了过多的解释工作。在颜色赋予优先级之前，方案名称、适用人群说明和可见的差异，就应该足以帮助用户形成合理的选择。

适配窄屏时，也要保留比较所需的信息

把方案卡片上下堆叠并不难，难的是保留比较能力。当每个方案各占一屏时，记住第一个方案是否包含某个功能，也成了用户任务的一部分。不要以为竖向布局干净整齐，就一定容易比较。

如果方案数量不多，就让堆叠卡片中的功能顺序保持一致。如果比较矩阵较长，可以考虑让用户选择两个方案进行窄屏比较，或使用方向清楚的横向滚动表格。哪一种更合适，取决于访客主要是在阅读单个方案，还是在比较几个具体数值。

折叠面板能缩短页面初始长度，但也会把信息藏起来。关键限制和计费条款应保留在折叠区域之外。如果用户必须把每个方案都展开，才能找出哪个方案包含访客访问权限，那么折叠只是把同一份工作分摊到了更多次交互中。

使用真正的数据表格时，要保留其结构关系。W3C 的表格教程解释了如何关联表头单元格和数据单元格，以便辅助技术也能理解这些关系。仅仅把文字在视觉上排成整齐网格，并不能提供同等的实现。参见 W3C 无障碍表格教程。

用一个具体比较任务测试窄屏版本：找出支持六名编辑者和二十个活跃项目的最便宜方案。这些虚构要求能够暴露出，布局是否保留了做选择所需的信息。只检查页面能否装进视口，并不能回答这个问题。

让按钮准确说明下一步

按钮应该描述访客现在确实可以执行的动作。开始试用、创建免费工作区、选择付费订阅和联系销售，是不同的步骤。给它们全部套用“开始使用”，虽然能得到一排一致的按钮，却会让交互含义变得模糊。

把重要条件放在对应操作附近。如果试用需要提供付款方式，就应在用户继续之前说明。如果组织方案要先与销售沟通，就避免使用暗示可以直接结账的按钮文字。目的是让用户形成准确预期，而不是在一张卡片里解释完整的购买流程。

也要考虑已经订阅的用户。通用的公开价格表可能把他们带入重复注册流程。最终产品实现可能需要显示当前方案状态，或提供通往账户设置的入口。即使原型没有实现账户逻辑，也要记录这种状态，避免评审只考虑首次访问者。

不要把所有无法选择的情况都用禁用按钮来表达。如果购买资格取决于账户条件，就解释具体条件。没有说明的禁用控件，会让用户无法判断，问题究竟是额度限制、临时错误，还是有意设置的规则。

GitHub 截图中的卡片把这种差别呈现得很具体。Team 提供“Continue with Team”（继续选择 Team）；Enterprise 则同时提供试用和联系销售。后一张卡片表达的是进入同一方案的两条路径，而不是该方案的两项不同功能。评审时，沿着每条路径走下去，检查访客下一步需要提供什么信息。按钮可以用一致的颜色维持页面的视觉节奏，同时让标签具体说明接下来要做什么。

用真实的决策任务评审设计稿

让每位评审者都有一个问题要回答，视觉评审就会更有效。给一位评审者独立用户的场景，给另一位正在成长的团队场景。请他们选择方案，并解释哪些事实促成了这个选择。他们的推理过程能暴露出模糊之处，而泛泛地征求反馈，可能发现不了这些问题。

对于 Fieldnote，可以设计这样的任务：一位研究者有两个项目和若干访客；另一个团队有六名编辑者；第三个场景需要全组织的管理能力。还要加入一个按理应排除高亮方案的场景。否则，评审只能确认视觉强调有没有起作用，却无法确认比较内容是否支持用户得出不同结论。

接着，请每个人说出现在会被收取多少费用，以及承担什么付费义务。即使正确文字确实出现在页面某处，用户答错了仍然是问题。根据实际误解，移动或改写解释，而不是下意识地再加一条脚注。

也要有意放入难以排版的值来评审表格，例如很长的功能名称、不提供的功能，或需要协商价格的方案。这些不是可以留到开发阶段再处理的罕见例外；它们决定了比较结构能否表达真实的售卖条件。

在 OpenDesign 中，可以通过 HTML 预览支持这类视觉评审。用评论指出可能误导读者的价格信息组，或对齐错乱的比较行，再有针对性地修改文字或样式，完善呈现。把已批准的方案事实作为设计上下文提供进去。至于账单计算、账户购买资格和结账行为，应在实际实现的流程中验证。

交接页面之前，把每一个可见价格和限制都与事实表逐项比对。检查两种计费状态、每个购买操作，以及窄屏布局。当读者能够准确解释哪个方案适合自己及其条款，包括高亮方案并不适合自己的情况，这张价格表才算准备好了。