2023年产品设计：如何让功能既灵活又简单

产品设计：如何让功能既灵活又简单？一、为什么这是个问题？

功能设计是产品经理最基本的技能，也是产品最基本的组成部分和价值所在。

所以，不管是在工作中，还是在面试中，一个功能设计得太简单或者太鸡肋，都会直接拉低别人对你的印象分！！！

但在产品设计中，敏捷与简洁这两个特性的确经常是冲突的。

尤其是在工具型产品中，我们想把功能设计得很敏捷，就经常会用起来很简单；假如想设计得很简洁，又会削减功能性，显得很鸡肋。

当然还有个方法，就是在简洁的功能中加入机器学习模型；不过假如团队自身积累不足，这个方法的投入就太高而价值又太小，不是个好方法。

举个例子：在当今的产品中，包含的信息越来越多、越来越简单，所以搜寻功能就越来越重要了。

在搜寻功能上，我们既盼望能够足够敏捷（比如支持各种条件组合，支持“与或非”等等），又盼望足够简洁（像一般文字输入一样）。

怎么办呢？

这是一个比较典型的逆境，我们来看看百度、Google等通用搜寻引擎是怎么做的。

它们在“简洁”上做得很精彩，当需要多个关键词时，只需要用空格隔开就可以了。

还不错对吧？但是，再看看它们应对“敏捷”的高级搜寻功能……

这里的确供应了足够的敏捷性，但整个设计就倒塌了；由于从1个输入框变成了10项配置，太简单了！！！

那么假如加入机器学习模型呢？就这样：

这类推举看似简洁，但假如要仔细做，需要投入不少人力和时间才能实现。

所以，百度这是个失败的设计吗？

其实不然——假如你是百度搜寻引擎的深度用户，那么你应当知道这样一组搜寻指令：

用减号“-”代表排解关键字；用“intitle:”代表关键字只消失在标题中；用“inurl:”代表关键字只消失在URL中；用“filetype:”代表只想看某些文件类型，比如docx、pdf；用“site:”代表只想搜寻某个站点中的内容；以上这些指令都可以直接在搜寻框中输入，既满意了高级用户的需求，又不会影响初级用户的使用体验。这就实现了既敏捷又简洁。

那么，假如你想在设计自己的产品时也做到敏捷而简洁，应当怎么做呢？

二、原来的设计问题出在哪？

首先，我们定义问题的范畴。

敏捷与简洁的取舍，不是一个纯粹的交互设计的问题，它还涉及到前端页面交互与后端系统的协作；所以单从交互设计的角度很难找到答案。

这里必需说一点：要想提升对于产品的理解，需要练习自己的抽象思索力量。

在这里，我们就需要把详细的产品交互做一次抽象和提炼，找到其中的规律；有技术背景的同学在这方面会有优势。

为什么？由于技术语言本身就是对事物的抽象。

其次，我们要打破一种思维定式：“一个功能是一体的，不再可分”；其实并不是这样的，就用上面的搜寻引擎举例，它与用户相关的部分大致可以拆成两个子模块：

收集用户输入搜寻条件；系统解析用户输入的内容；所以，正是这两部分造成了敏捷与简洁很难取舍——用户随便输入的内容系统很难解析；而系统便利解析的内容对用户来说太简单了。

最终，我们可以借鉴技术领域的MVC设计理念，来考虑我们的产品功能设计。

MVC是三个单词的首写字母——M代表Model，是指产品中的数据模型；V代表View，是指产品中呈现数据的方式，其实就是用户“看得见摸得着”的产品形态；C代表Controller，指的是真正用来响应用户操作的部分。

这种设计理念为我们设计简单功能打开了思路。

一个产品功能，我们可以从三个方面来思索它的设计：

第一部分是Controller，我们可以理解为“核心功能”。比如，在搜寻引擎中什么是“核心功能”？依据用户输入的条件，返回符合条件的结果，这就是核心功能；所以“查询”就是一个必不行少的Controller。

其次部分是View，直接理解就是“产品形态”。比如收缩引擎中的输入框，搜寻结果列表；这两个详细的产品形态，就是两个View。

第三部分是Model，这部分就很抽象了；我们在这里不单独解释它，结合下面的例子一起说。

我们以“用Excel中的数据画图表”这个场景为例，来看看MVC的三个部分是怎么协作工作的。

首先，我们在一个Excel文件中保存的一份数据，这份数据，就相当于MVC中的Model。

接下来，我们选中这些数据，然后使用插入图表的功能，并选择一种图表类型；比如我们选择了折线图，这其中“插入图表”就是一个Controller，而折线图就是一个View。

这时假设我们不想用折线图了，想换成柱状图；那么，略微对Excel有一些了解的同学都知道，为了把折线图换成柱状图，我们不需要复制一个Excel文件，也不需要再安装一套Excel软件，只需要转变一下图表类型。

为什么这么简洁？

保存在Excel里的数据Model变了吗？没有。

“插入图表”这个功能Controller变了吗？也没有。

要做的只是切换一下View。

所以，假设我们想在自己的产品中，增加一个类似“把折线图换成柱状图”的功能，我们实际要增加的只是一个View，而不需要转变已经有的Model和Controller。

除非我们把“插入折线图”和“插入柱状图”当做完全不相干的两个功能来设计；不过这明显不合理，而且已经超纲了，我们不在这里争论。

三、怎么用MVC设计产品功能？

现在你有体会到MVC在产品设计中的魅力吗？那我们再举个例子：

协作型的产品通常都会增加权限管理模块。

根据标准的RBAC（RoleBasedAccessControl，基于角色的访问掌握），我们需要设计的功能包括：

单个/批量管理用户和给用户赋权；单个/批量管理角色和给角色赋权；权限校验，返回校验通过或拒绝；听起来像是个很简单的功能模块吧？别慌，假如用MVC的理念怎么设计呢？

这里只考虑了最核心的功能部分，在实际功能落地时，多少还会有其他功能补充进来，比如单点登录、读取用户信息等。

首先我们有3个重要的Controller（不是全部哦），包括：

1个更新用户与角色关系的Controller，支持批量；1个更新角色与权限关系的Controller，支持批量；1个校验权限的Controller，支持不支持批量都行；其次，我们只有3个重要的Module，包括：

1个用户与角色对应关系的Model；1个角色与权限对应关系的Model；1个用户与权限对应关系的Model；其实，我们也可以把这三个Model合并成1个，这样我就只需要一个“用户-角色-权限”的Model了。

最终，我们也只需要1个View了，由于在交互上无非是查询或者更新“用户-角色-权限”三者之间的关系。

此时，假如之前我们的确没有考虑到“批量