如何设计收敛和确定设计边界

飞鱼 B端产品站 2024-05-28 10:24:16

一、背景

产品专业能力包括：

需求洞察
用户调研、用户模型研究
设计发散思考
竞品分析
设计方案决策
输出设计文档&自查清单
用户体验兼容方案设计与落地规范
项目管理、跨部门配合等方面

承接上篇《如何进行设计发散思考》，在发散思考得到很多想法之后，本文档内介绍如何进行【设计收敛和确定设计边界】。

二、设计收敛的作用

设计师本来就是一个充满创造性的职业，为什么要收敛思维呢？

针对不同的业务场景存在不同的设计方法和策略，收敛思维是贯穿整个设计流程中的。B端产品设计过程中使用收敛思维，核心目标还是「降本」，无论是降低用户的认知成本、学习成本，还是平台侧的开发和维护成本，而通用性、普适性、可扩展性、低成本成为评估最终方案的硬指标。

2.1 节省设计开发资源

开发资源资源是有限的，所以我们通常聚焦于最能满足用户需求的功能，然后优先调配资源来解决。

设计收敛，就是权衡市场需求和可用资源，以期待用最优成本满足需求的方式。

2.2 保持功能简单易用

设计收敛可以控制产品功能无需扩张，贴合产品定位和聚焦核心功能场景，使得产品能以最少的功能解决最多的问题，让产品功能更简单易用。

2.3 降低方案决策难度

通过设计收敛，可以排除部分方案，缩小方案决策范围，降低方案决策难度。

三、设计收敛的方法

3.1 收敛需求边界

需求为什么要有边界？

从广义的角度来说，需求受限于企业业务的边界。
从狭义的角度来说，B端业务比较大的一个特点是多人决策，需要各个部门给出意见，并就相关问题达成一致意见。
映射到产品身上，即每个设计任务需要解决的核心需求是什么，每个需求需要解决的核心问题是什么。通过确保需求边界来确保设计边界，是的每个设计任务中用户需求和产品功能保持步调一致，这样才能保证所做的需求是有价值的。

如何收敛需求边界？

当我们处理业务需求时，比较难以控制需求蔓延，即需求范围无限制的扩大。从用户角度来说，同一个业务场景下涉及到多个功能点，用户这个也想要，那个也想要，很难让用户去定义优先级。这个时候，就需要产品经理把控原则，把用户需求有选择性的束缚在某个范围内。

【方法一】拆解最小业务单元

最小业务单元，是在完整业务单元的基础上，以最小的工作任务走完整个业务链条，即完成业务的最短路径。
其定义方法，可以用“有或没有”的影响来衡量，如果某个业务需求没有，也不影响业务的完整性，那就可以剔除；如果缺少某个业务，业务就完全无法进行下去，那就必须保留，所有必须保留的项，就形成了最小业务单元。
产品是业务线上化的结果，需求一定来源于实际业务。找到最小业务单元之后，最小业务单元中的某些部分需要按优先级排序，优先线上化对用户体验影响较大的部分。

【方法二】论述需求必要性

这个功能是不是用户所必须的，有其他替代方案解决吗。
这个功能是不是针对我们的目标用户群体。

由此，便可对需求边界做收敛。

3.2 确定功能边界

确定功能边界是指，需要明确需要在哪个模块或哪个地方增加功能，可以解决用户需求。确定的功能边界越小，影响范围越小，设计开发工作量越小。

确认功能边界的意义，是为了保证产品设计不“越界”，通过限制功能改动范围，来限制设计边界。

3.3 参考竞品

可以把需求涉及到的功能点，列举出来，看看哪些竞品有，哪些竞品没有。若我们想做的功能，很少有竞品做，需要反问自己：竞品为什么没做？是有技术实现卡点，还是需求本质指向的不是这个功能？

3.4 抽象功能模型

唐纳德在《设计心理学》里面就提出的用户模型、设计模型的概念。部分产品设计，也需要在给出具体方案之前，抽象功能模型或定义功能概念。

对产品本身来说，模型的作用是：

1）符合模型的功能才有更高的拓展性和适配性，所以我们做出的设计若能符合模型，对后续拓展会更加友好。

2）SaaS产品有非常强的业务属性，如果缺乏框架性思考，单点设计功能将会让你精疲力尽，对内部来说不断堆砌功能，开发成本会越来越⾼，对外部来说用户看到的信息繁杂，无法高效的完成任务，所以我们设计功能前需要理清架构，以⼀种全局的框架视⻆来思考。

3）业务架构是⼀套功能依据业务进⾏分类整合，形成抽象化的业务模型，架构可以帮我们理清每个业务模块/功能间的边界，以及他们之间的关系，在我们⾯对多个类似的需求时先梳理架构就可以基于场景迅速定位到对应的模块，在设计功能时我们就可以实现⼀个功能满足多个类似需求的效果。那么如何设计一个功能满足不同场景需求呢？

4）通过可配置化满足客户的个性化需求。

⼀般会存在两种情况，第⼀是业务流程与现有方案差别较小，那我们可以从功能层面进行配置，第⼆是业务流程与现有方案差别大，那我们从系统层面进行配置。

在可配置层面⼀般来说包含界面布局，字段名、验证逻辑、计算规则、审批流配置，角色配置，角色功能权限配置，用户配置，用户数据权限配置等。在产品设计时需要规划好什么样的配置功能开放给客户，什么给到自己。原则上为了避免客户的复杂度，尽量开放小范围的配置功能给到客户自己使用。高配置往往会造成低易用性，配置项过多会带来页面不简洁，流程不高效；本质上来说用户要的不是配置项，是低成本实现目标的功能。
在判断功能要不要做成配置时我们可以通过两个维度来做判断，⼀个是模式切换频率，还有⼀个则是需求的长尾程度（用户需求差异化程度），针对⼀些默认配置项判断标准我们需要回归到场景，在大量同⼀种类型的个性化场景中，找到最核心的场景，并根据场景下的功能设计设置为默认配置项。

因此，可以通过抽象功能模型来限定功能形态，从而限定设计边界。

抽象功能模型分成三步⾛：

第⼀将场景需求清单拆解为单点功能。
第⼆将单带你功能按不同维度整合。有相似性的功能整合为一套模型体系，摒弃关联性不大的功能。
第三梳理模型内各功能点之间的逻辑关系。

3.5 其他几种小方法

冲动法：某个方案会不会让自己觉得很妙，会不会有奔走相告的冲动。如果是，则这个发散方案就值得留下来。
揣测别人极限之外：对某发散方案，尝试下，是不是身边100 个人可能都想不到，或者甚至连自己的领导，连业界权威都想不到，那么这个发散方案也可以保留。
排序法：强制一定的比例排序，10个想法留1 个。如果想再增加一个功能点，那就再额外发散10个。
回顾法：当前想到一个方案，如果一天之后、一周之后、一个月之后感觉方案还是很不错，那就值得把这个发散方案留下来，深入考虑如何实现。
一票否决法：发散思考时获取到了尽可能多的解决方案，这些方案不可能每一个都十分正确、有价值。因此在方案决策之前，可以做一次初筛，直接排除掉一些不靠谱的方案。比如有用户体验极差、开发成本非常高、无法对老用户兼容处理等问题的方案。