SaaS定价页面首先要帮助用户判断哪档套餐能完成自己的任务,再让他看懂计费单位、付款周期和实际支付总额。只放三张价格卡,再给中间一档贴“推荐”,往往不足以支持选择。套餐差异、人数变化、当前方案和下一步购买结果,需要在同一条路径中解释清楚。
可以用墨刀原型连接定价页、人数选择和订单确认,先检查信息与操作是否连续。下面用虚构团队知识库“拾页”作为练习,设计个人、团队和企业三类方案。文中的金额只用于说明界面和计算方式,不代表墨刀或任何真实产品的报价。

先按用户任务分套餐,不要先按卡片数量分
个人用户关心能不能整理自己的资料,团队负责人关心能否共同维护知识库,企业采购更关心组织管理与服务安排。页面应先用简短句子说明各档面向谁,再展示真正影响选择的能力。并不是每个产品都需要三个套餐,也不是中间套餐天然最适合。
| 方案 | 本例面向的对象 | 卡片优先说明的内容 | 下一步 |
|---|---|---|---|
| 个人 | 独立整理资料的使用者 | 个人内容管理与使用范围 | 开始使用个人方案 |
| 团队 | 需要共同编辑的工作小组 | 成员协作、共享空间与计费人数 | 选择团队人数和账期 |
| 企业 | 有组织管理与特定服务要求的团队 | 管理能力、服务内容及需沟通的条件 | 提交团队需求,了解方案 |
描述要帮助读者自我判断。“适合所有团队”“无限可能”无法解释差异。若某能力有项目数、存储或角色限制,应把单位写在能力旁,不能全部藏进一个星号。企业方案若没有统一公开报价,就明确进入咨询路径,不用“免费体验”暗示其长期价格。
价格至少有四个维度:金额、单位、周期和总额
本例团队方案设为月付每人36元;年付按每人每月30元展示,一次支付12个月。购买5个席位时,年付总额是30×5×12=1800元。如果卡片只显示醒目的“¥30/月”,用户可能以为整个团队每月只付30元,或可以按月支付30元。
年付卡片可以写成“¥30/人/月”,紧跟“按年支付,5名成员合计¥1800/年”。月付视图则显示“¥36/人/月,5名成员合计¥180/月”。年度折算单价与实际扣款金额应同时清楚出现,不让页面视觉层级掩盖付款周期。
| 选择 | 折算或单位价格 | 人数 | 实际付款表达 |
|---|---|---|---|
| 月付 | ¥36/人/月 | 5名成员 | ¥180/月,按月支付 |
| 年付 | ¥30/人/月 | 5名成员 | ¥1800/年,一次支付12个月 |
| 人数未确定 | 展示单价并说明单位 | 待输入 | 提示选择人数后查看总额,不先制造确定总价 |
优惠活动、税费、最低购买人数、额外用量和自动续订等信息,应该以真实业务规则为准。在设计阶段把这些项目列成待确认事项,确认后再进入页面。不要为了让卡片更好看,自己补一个“永久优惠”或模糊的“起”字。
月付年付切换,应更新所有相关信息
切换账期后,不仅大号价格需要改变,周期标签、合计金额、按钮说明和订单页的账期也要同步。若页面有功能对比、浮动购买条或底部再次出现的价格,那里也应跟随当前选择。用户不应该在首屏选年付,点击按钮后却看到月付订单。
首次默认展示哪个账期,是产品决策而不是通用最佳答案。可以突出年付,但要让月付入口同样可辨识;不要用浅到看不见的文字隐藏另一选项。切换时保留已选人数和当前套餐,让用户比较同一购买条件。
人数变化也会影响总额。本例从5人改为8人,年付应显示30×8×12=2880元。输入0、负数、空值或超出允许范围时,应给出就地提示;具体最少、最多人数来自真实规则。原型至少准备5人、8人和输入无效三种结果,避免价格计算只画一个静态数字。

功能对比表只比较会影响选择的差异
价格卡片负责快速筛选,展开的对比表负责回答细节。把所有档位都拥有的十几项能力堆在顶部,会让真正的差异沉到底部。可以先按“内容使用、成员协作、管理与服务”分组,在每组中优先显示决定升级的能力。
勾与叉适合表示有无,但不适合替代所有描述。“支持协作”究竟是可以分享查看,还是可以共同编辑?“高级权限”允许限制什么对象?必要时给出简明说明或指向具体功能页。限制值也要用相同单位比较,不能一个写“10个项目”、另一个写“充足空间”。
手机上避免把四列内容整体缩到极小。可先让用户选择要比较的两档,再逐项对照;也可把每档按相同分组展开,保留清楚的套餐名称。横向表格若需要滑动,应让用户知道可以继续查看,并避免滑到某一格后丢失列标题。选择哪种形式,取决于比较项目的数量与用户任务。
已登录用户与新访客,不一定看到相同的按钮
新用户需要知道购买后加入哪个工作区;已有用户还需要识别当前套餐、有效期和谁有购买权限。如果自己只是普通成员,“升级”按钮直接进入付款可能让人误以为能替全团队更改方案。可按真实权限显示“联系管理员”或对应申请入口。
对当前套餐使用“当前方案”标识,避免看起来像还需要再买一次。升级、续费、增加成员和降低方案不是同一个动作,按钮文案应对应真实结果。升级是否按剩余周期补差、降级何时生效、历史内容如何处理,都需要在确认页根据实际规则解释,不能套用另一家SaaS的逻辑。
例如负责人从团队方案进入增加席位,确认页至少显示工作区名称、当前成员数、新增数量、适用周期和本次需付金额。一般介绍“团队方案适合协作”的卡片不能代替这个已购用户的确认过程。
购买确认页承接的是一份具体选择
本例从“团队、年付、5名成员”按钮进入后,确认页应继续显示相同选择,并让用户能返回修改。如果返回定价页又恢复成默认个人方案,用户会怀疑刚才的操作是否有效。登录步骤也应尽可能保留已选方案;无法保留时,需要清楚提示重新确认。
确认页把套餐、人数、周期、应付总额以及已确认的续订安排放在同一区域。主要按钮可以是“确认方案并继续”,实际是否进入支付、提交订单或销售联系应由系统流程决定,不能把一个不会即时开通的咨询请求写成“立即开通”。支付后的结果设计可参考支付成功、处理中与待确认的页面处理。
用三个购买任务检查,而不只看价格卡片
第一个任务:一个5人团队比较月付与年付,准确说出每次支付多少。第二个任务:已有团队方案的负责人增加3名成员,确认是在增加席位而非重复购买。第三个任务:没有购买权限的成员找到下一步。让不了解规则的同事完成这些任务,观察他在哪一处停下来、是否把单价当总价。
在墨刀里可以分别制作两种账期、两组人数、当前套餐和无购买权限的画板,连接选择、返回和确认路径。标注价格公式与已确认规则,研发才能知道哪些文字需要一起更新。定价页的转化价值来自减少疑问和选择错误;是否提升购买率,还需要上线后的真实数据观察。