这篇文章里，作者从评价标准、设计风格、企业的产品原则、设计原则、设计工具等方面，分享了自己关于To B SaaS产品设计的理念和方法，一起来看看吧。

各领域里好的产品，都有其共通性，因此像《产品心理学》这种经典，对各领域产品设计者都有很大帮助。但每个种类的产品，当然也有其特别性。2B SaaS的产品设计，会有很多不同于其他类型产品的设计原则和方法。2B的重点是面向特定的企业领域，提供特别的业务价值和效率体验；SaaS是产品交付形态，更是商业模式，因此SaaS产品要支持产品价值交付的低成本高效率好体验，同时要支持SaaS这种商业模式所需要的商业体验。

我想从评价标准、设计风格、企业的产品原则、设计原则、设计工具这几个方面，分享一下我对2B SaaS产品设计的理念和方法。

一、产品评价

要做好产品，首先需要确定一个标准，做成什么样子就算好产品。这有2个视角来评价，一个是从设计角度看2B产品要设计成什么样子，另一个是从客户角度如何评价产品并因此决定是否购买产品。

首先是设计评价。我有个评价模型，2B SaaS产品可以从4个层次来看：有用、好用、优雅、关怀。

• 有用， 在确定的问题域里，清晰理解场景，提供高效率的解决方案，使用户和客户都获得真实有效的价值。
• 好用， 产品是否内部逻辑清晰，交互合理，对外与企业已有和将有工具和流程共同协作，明显改善企业用户的业务效率和工作体验。
• 优雅，产品是否给用户带来愉悦感、控制力、安全感。是否给客户企业带来低风险、高效率、低成本的价值展现能力。
• 关怀，产品是否关心用户的工作体验和成长，给用户带来获得感、成就感、视野，创造美好现在和将来；是否关心客户企业的变革和发展，适应甚至引导客户的业务和管理演进。比如用户会因为使用你的产品，感觉工作从无序变有序、工作心态更加积极。 企业从产品中感知到趋势和问题，获得面对挑战的能力和工具。

另一个是客户评价。企业对产品的评价和决策，是由个人评价和集体评价形成的，涉及企业内多层次多角色的综合评估过程。从角色看，可以有3个视角：用户个人评价、利益相关人评价、企业决策对产品价值评价。从人评估产品的大脑活动来看，分为3个层次，本能、行为、反思。这里概要地列举一些评价需求，但需要根据具体产品和目标客户，做细化。使用这个模型来拆解客户对产品的评价，结合设计评价的4各层次，在产品里考虑每部分如何实现和满足。

关于体验设计是否重要，有些观点认为在2B领域，价值为王，体验设计差一些不是问题。在企业决策中，体验的影响通常是隐性的。但我认为价值是通过体验来呈现的，在这个体验和习惯被大量训练的时代，你无法忽略用户“感受”对评价反馈的巨大影响。尤其红海产品和早期产品。因此要非常重视。

二、产品的调性和风格

2B产品，也需要根据行业特性、用户特性、产品定位和公司策略，确定产品的调性和风格。你希望用户感知到的系统是一个机器人？工具集合？流程平台？ 希望它呈现冷峻准确，还是主动友好？这些决定了体验设计、内容设计、互动设计、视觉设计的风格。 尤其即将到来的AI产品时代，产品具有一定的“人性”，那么你需要它是个什么样的“人”。这部分不多说。

三、企业的产品原则

以下一些原则，其实还是产品层面的原则。但之所以将他们拿出来，放在企业层面说，是因为这些原则都是直接受到公司经营、公司管理层、公司文化影响的。要站在企业层面，确定这样的一些原则。才能让产品团队在具体产品工作中安心做产品，不会因为“非产品”的因素冲击，使得产品工作变形。

• 好的产品，应嵌入新生产要素，使得用户体验有大幅跃迁甚至颠覆。
• 要为核心场景的业务目标做设计，为本质需求的解决方案做设计。而不是某个客户提出的需求、甚至某个客户想要的解决方案。
• 不要尝试在产品中帮客户解决所有问题。确定好横向的边界和纵向的边界。横向是覆盖哪些业务环节和操作环节。纵向是环节里帮客户做到什么程度。 把覆盖的环节，做到极致。把选择器和一些权责，交给用户。
• 要以产品思维做产品。要整合资源，为目标问题域和目标用户提供独特价值。定位用户和问题、分析问题、设计和实现解决方案、实现解决方案，对客户交付解决方案价值这样一个系统化过程，要通过建立多层模型，落实这个过程。 既不是累积“客户需求”、也不是自我陶醉的“领先技术和方案预设的方案”。要建立用户心智模型。要求所有用户按照设计者的“逻辑”来使用产品，是没有建立用户心智模型。是面向设计的产品，不是面向用户的产品。
• 产品是一个理性的迭代试错过程。要在迭代和用户的逐步验证中，验证价值点，快速完善产品。不要期望一次就完美，那会产生很多无用设计、来回修改、增加产品复杂性、减缓产品上市速度等。这也是精益创业的核心，即分析信息、提出假设、快速验证、将成功规模化推广。哈佛商学院Stefan H. Thomke教授在哈佛商业评论上有一篇文章：Act Like a Scientist: Great Leaders Challenge Assumptions, Run Experiments, and Follow the Evidence，也是个非常好的参考理念。
• 俞军的产品价值公式：用户价值=新体验-旧体验-替换成本。 不要作替换成本太高、或新体验价值提升不大的“新产品”。
• 要做高级的产品，而不是低级的。低级意味着：多欲的、简单的、盲目的。高级大概是：克制的、极致的、特立独行的，有自我坚持的完整意识的。

四、产品层面的设计原则

企业业务场景要求的设计原则：

• 可配置性。同一个场景功能，不同客户可能有不同的做法。产品要运行用户通过配置支持自己的习惯和模式。
• 模块松耦合。2B产品通常功能多，各功能间要无关联或松耦合。
• 完善的错误处理机制。根据需要实现：规则提醒、第一时间禁止错误、执行前预知结果、可监控执行过程、重大影响的操作可中断执行、已经完成操作可撤销。
• 闭环。逻辑严谨，流程闭环，信息闭环，交互闭环，异常流程闭环。
• 默认功能和默认配置都只为“积极的多数场景”。同时，基于用户分层、需求分层、信息分层、场景分支分层、和范围边界，提供各种可能性的解决办法。
• 提供场景里提高处理效率的工具。

企业用户需要的设计原则：

• 控制力。用户需要随时掌握任务状态、进展，随时可以控制任务的走停等。
• 确定性和安全感。用户每时每刻都知道已经发生了什么，现在能做什么，应该怎么做，会有什么结果。 所有操作，都应该“与期望一致地”响应和执行。超出预期的给多给少，对企业用户都是增加心里负担。
• 产品要让用户完全理解，不要有客户需要猜测的、无法知道的后台逻辑；但如果后台逻辑过于复杂，可以建立用户模型，让用户从用户模型角度获得确定性。windows系统的文件夹是个很好的例子，无需用户理解系统内的复杂的文件存储、索引块等逻辑。
• 不要让设计师和公司的想法和目的，影响甚至阻碍用户的业务过程。比如不在用户的业务过程中要求输入产品运营所需数据。
• 使用用户的业务语言，而不是技术语言、系统设计语言。

作为一般性SaaS用户需要的设计原则：

• 一致性和稳定性，系统要行为一致、稳定可预期。
• 让设计消失。把业务本身的复杂性之外所有产品设计、使用的复杂性尽量缩减到最小程度。让用户清晰地感受业务、处理业务，而无需花精力应付“产品”“系统”。
• 诚实。不要用以欺骗用户获得信任。
• 不要求用户记忆，在系统中呈现状态、提示考虑用户各种异常时，系统如何帮助用户终端后”无记忆“情况下继续。
• 不要潜规则。不符合用户的常识理解，需要用户根据结果来分析判断后台实现逻辑。更要避免不按某种潜规则操作时，就获得惩罚和混乱。
• 前提条件最小化。某功能执行时需要的配置，只放最小要求。
• 不要急于表达自己，先成为用户，感受需要什么。
• 准确、清晰、简短的文字表达。避免长句难句、模糊的、有分歧的表达。
• 参考其他被广泛使用的设计原则，如19 Laws of UX、google产品设计原则、尼尔森10大可用性原则。

五、设计工具

有几个2B SaaS产品设计的工具，包括用户研究、场景分析、用户旅程图、心流、设计改进元素矩阵。相关书籍和资料很多，基础方法就不赘述了。 这里只说一些使用感受。

1. 用户研究

与2C领域所说的痛点痒点喜怒哀思求有所不同，2B领域，我们也谈同理心，谈系统的感官和使用感受是否让用户舒适省心、谈用户的角色内任务实现的快速流畅有成就感、谈通过系统他提升了对自己的工作的安全感和掌控度、谈他与周边流程合作者的高效对接、谈他在岗位上的成长。2B的用户，要考虑“人”，更要考虑“角色”。最终考虑”人“更好的完成角色，但不限于角色。

• 做用户研究，考虑用户的使用场景导致风格和用户使用姿态；
• 给特定集体做产品，要充分研究集体人格（集体中形成的思考和行为模式）、共同记忆和核心观念。同样的东西，对一些人是简单的，是常识，对另一些任则是复杂的、不好理解、不习惯的。
• 把客户当作样本。任何客户提出需求，甚至直接提出“解决方案”。都应该小心分析其广泛适用性，剥离其个性化的部分。如果习惯于直接按照客户说的去做，那产品迭代的过程，就变成“拉链工程”

2. 场景分析

场景驱动的设计也有很多资料可以参考。

首先，理解用户体验和操作的层次结构：人-环境-目标-任务-动作-操作，用户是谁，包括其角色特征和非角色特征是什么；用户的生存环境和使用环境如何；用户在产品中完成哪些目标；每个目标是通过完成哪些任务来实现；每个任务要执行哪些动作；每个动作涉及到哪些点击、填写、选择等操作。我们要站在人-环境-目标的层面考虑产品的价值设计，在任务-动作-操作层面完成产品的流程和体验设计。

可以把一个任务做一个业务场景、把一个动作当做二级场景，或者微场景。要考虑4个touch point的设计：

• 微场景的用户交互体验。每个页面都要考虑用户为什么进来，进来干什么，页面能否满足。
• 场景的整体体验，包括微场景衔接体验，和场景整体感或者说故事感。任务的多个页面视图之间如何组织让用户清晰，没有疑惑，可掌控全局自己决定怎么做。一个场景里的多个操作，在系统里要有整体感、秩序感，不要让用户感觉凌乱的分布，不知道如何互相影响和协作。2B不需要惊喜和探索，需要掌控。
• 场景与场景间，基于上下文的衔接体验。
• 场景中涉及与系统外工具、流程、信息的衔接体验。微场景-，是否只是过渡页面. 不要像游戏那样，走一步才知道下一步。

比如一个数据中心运维系统，考虑运维工程师用户，大概是个技术青年，他需要做很多具体技术工作，确保服务器运行温度并做信息汇报；以确保服务器运行目标而言，需要主被动发现服务器故障、需要快速处理故障等任务；处理故障任务又需要确定故障机器、分析故障原因等。

分析故障原因这个动作，在具体的故障分析界面或日志界面或机器详情界面，需要信息分布合理、可以搜索、这些操作的响应都应该舒适高效。如此逐层分解下去，将场景和用户旅程图结合起来。

3. 用户旅程图

非常典型，资料和经验分享无数，不赘述了。使用中可以结合心流的理念做设计，关心每个动作、页面，用户心理状态、目标诉求、心理感受。

4. 心流

2B产品不需要用户上瘾，但希望用户在产品使用中能保持注意力和保持心流，从产品出来时感受到成就感、控制感。因此，编配客户交互流程时，要建立和谐的业务流、动作流、反馈流。用户要感知到自己在用一定的力，一用力就有反馈有进展，通过这种小成就感和流畅感一步步完成了任务。可以参考《About Face》里关于流的部分，以及《心流》这本书。设计团队可以建立一些如何帮助用户建立心流的细粒度的设计原则，这里列举一些例子供参考。

• 页面结构清晰。页面可以分为视觉结构和业务功能两个层次，让不了解业务的人快速浏览页面，说出页面可能提供的功能，是检验视觉结构的一个办法。 让没用过系统的从业人员设计师可以尝试让旁人快速理解页面结构，来检验设计是否合理。
• 高频操作的点击区最好是区域热点
• 400ms内反馈
• 优化响应但容许延迟（即时反馈，如果不能应运行中断后返回查看进展和结果）
• 让必要的工具近在咫尺
• 提供无模态反馈。即反馈不打断正常操作流，如word下边的字数、鼠标位置等
• 用动画动作过渡增强和保持心流
• 给用户默认配置，避免空白状态
• 不要让用户迷路，反映当前所在位置，以及退后方式
• 避免不必要的报告
• 减轻心流负重：提供选择而不是提出问题；隐藏弹射座椅的操作杆（让高效的操作过程，不感知风险操作）、区别命令和设置（大部分时候命令直接完成，需要设置只是少数，如直接打印和打印配置界面的区别，不要让一堆参数打断心流）；避免不确定性的提示
• 控制任务实现距离： 有人说2B可以不追求少点击一次鼠标。 我不尽认同。不盲目追求减少点击次数，但每次点击都必然需要一些思考、是一次任务的动作链条。如果设计产品时不考虑这个，可能放任工作链条的增长。用户完成一次任务的非业务精力就会耗的多，潜意识就是系统操作很多，有复杂性。 这各种感觉无论对于早期赢得客户，还是我们强调关怀性，尽量提升客户使用过程中的轻松感，都是不利的。 因此要注意点击的次数，和每次点击的有意义性。使客户在几个非常明确的点击后就完成了任务。不要把客户的心流耗散在点击的迷宫里。

5. 设计改进元素矩阵

1. 列出需要呈现的元素
2. 元素间多种可能组合，形成若干可能的组件
3. 正相交的组件，多种组合成多个方案
4. 根据判断标准，选择合适的方案

6. 其他可以参考使用的设计工具

• KANO需求分类模型
• 40个发明原理
• SCAMPER产品改进方法
• 病毒式营销传播的感染力6原则，社交货币、促因、情感倾向、公众、使用价值、故事
• Fogg行为模型