编辑导读：B端产品多种多样，设计过程中会遇到不同的问题。本文作者从自身工作实践出发，对招聘SAAS系统设计展开分析，并基于自己的思考，对设计过程中的一些问题进行了解答，供大家一同参考和学习。

从0到1的SAAS系统多是由公司自上而下推动开展，因此今天我不会和大家过多说明项目的背景和缘由，而是着重和大家聊一聊在从0到1这个阶段，我们经历过的困境以及破局之法，希望可以为大家在从0到1设计SAAS系统以及后续的迭代过程中，提供前车之鉴及较为落地的解决办法。

困境一：种子客户的定制化需求/客户需求和产品规划不一致

兵马未动，粮草先行。在产品团队开始规划设计系统之前，销售已经开始打单，并且拿下了一个行业龙头客户。

即便我们前期做了很多业务调研，系统冷启动的过程中，不可避免地仍会依托、参考借鉴种子客户反馈的真实业务场景，这也注定了接下来的很长一段时间我们都处于被种子客户裹挟的被动局面中。

该客户会根据自己过往的系统使用经验及线下业务场景提出大量需求，而这些需求无法通用化，此时，寻找种子客户定制化需求和通用化场景之间的平衡点至关重要。

针对此类大型种子客户，若无法满足他的使用，可能意味着失去，对于开拓市场极为不利。可以按照以下几点进行逐步实施：

1. 寻找影响其流程使用的核心点，如果人力和时间极为有限，尽可能以最低成本去实现，满足客户的使用；若功能有通用化的方案，可结合功能设计、实现逻辑、实现成本，判断是否允许后端先以配置化进行开发，节省后期通用化开发成本；
2. 针对不影响客户使用的功能点，可采取“置换方案”，即以告知客户正在规划和进行中的功能的实现价值，来置换客户一些不太重要的功能点；
3. 拒绝一些需求，主要是一些仅仅解决客户当下需要，但后期可能并不会用的需求，可告知客户其他解决办法或研发一次性处理掉，无需通过功能性进行实现。

困境二：不同类型客户的多样化需求

在客户数量渐渐增加后，会面临不同规模的客户。客户的诉求也不尽相同。以招聘系统为例，大型乙方客户的业务流程较为规范、业务类型较为丰富，所需功能可能不仅限于职位管理、招聘流程、人才库、报表等核心功能，还包括客户管理、开票管理、供应商管理等功能；而中小型客户的业务流程简历、业务类型相对单一，所需功能可能仅有部分核心功能，甚至仅需要人才库。

那么在针对整体系统给迭代过程中，如何处理不同类型客户的不同需求，甚至同一种功能的不同要求：

1. 所有需求的迭代围绕客户留存风险、功能价值两大要素围绕进行；
2. 高价值、高风险客户的核心需求为第一优先级；低价值、高风险客户的核心需求次之；整体需求排优过程中，尽量保证需求的通用性。

困境三：功能逻辑高度耦合

在从0到1系统设计过程中，一个无法避免的问题就是各个功能模块见的逻辑耦合。由于不同功能由不同产品负责，功能逻辑高度耦合时，容易造成产品设计的逻辑漏洞（因为可能会遗忘），同时容易造成后期产品逻辑过度繁重，也不利于用户使用。

可通过以下几点来尽量避免逻辑高度耦合造成的设计应影响：

1. 产品设计前的充分沟通，确保涉及逻辑与其他模块的功能不会冲突；
2. 设计的逻辑尽量考虑是否涉及到权限部分。举个例子，当用户没有查看职位的权限，但是却具备招聘流程的操作权限时，如何可以看用户投递的职位详情，可以考虑采用弹窗的方式来解决，确保用户可查看职位详情，避免因为无职位数据权限造成无法在其他功能中查看职位详情。

困境四：客户永远在猜测功能的逻辑

客户使用系统时，会抛出大量的使用问题和功能实现问题。比如客户在导入简历时，会问一系列问题：最多可以导入多少份简历？简历重复时是否会有提示？重复的简历是怎么处理的……

产品设计时，尽可能将功能做一些必要性地解释说明（说明的展现方式有很多种，可以直观说明，也可以以hover时展示的形式进行，具体案例具体分析），不要让用户去猜这个功能是做了什么，之后又是怎么处理的，否则会造成用户使用的疲乏感，也容易增加解答客户问题的时间成本，得不偿失。

困境五：差劲的交互设计

用户在使用过程中，经常会问这个应该怎么操作，为什么这个无法点击，为什么这个点击后跳转到这个页面。

系统的用户参差不齐，功能使用上的诸多疑问不要归咎于用户。产品需要考虑每一个点击跳转的合理性、操作项交互方式的必要性、操作路径的简洁性等（如果交互设计师，则可尽量与交互设计师沟通、反馈，避免此类问题重复发生）。

综上所述，在设计SAAS系统过程中，切勿被客户牵着鼻子走，更不要忽略良好交互的重要性，须清晰了解产品功能间的逻辑耦合，简介明要地展示功能设计的说明和边界。

本文由 @Sarah 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议