重庆小潘seo博客

当前位置:首页 > 重庆网络营销 >

重庆网络营销

产品设计:如何让功能既灵活又简单?

时间:2020-10-09 11:20:11 作者:重庆seo小潘 来源:
一、为什么这是个问题?功能设计是产品经理最基本的技能,也是产品最基本的组成部分和价值所在。 所以,不管是在工作中,还是在面试中,一个功能设计得太复杂或者太鸡肋,都会直接拉低别人对你的印象分!!! 但在产品设计中,灵活与简单这两个特性确实常常

产品设计:如何让功能既灵活又简单?一、为什么这是个问题?功能设计是产品经理最基本的技能,也是产品最基本的组成部分和价值所在。

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

但在产品设计中,灵活与简单这两个特性确实常常是冲突的。

尤其是在工具型产品中,我们想把功能设计得很灵活,就常常会用起来很复杂;如果想设计得很简单,又会减少功能性,显得很鸡肋。

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

举个例子:在当今的产品中,包含的信息越来越多、越来越复杂,所以搜索功能就越来越重要了。

在搜索功能上,我们既希望能够足够灵活(比如支持各种条件组合,支持“与或非”等等),又希望足够简单(像普通文字输入一样)。

怎么办呢?

这是一个比较典型的困境,我们来看看百度、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(Role Based Access Control,基于角色的访问控制),我们需要设计的功能包括:单个/批量管理用户和给用户赋权;单个/批量管理角色和给角色赋权;权限校验,返回校验通过或拒绝;听起来像是个很复杂的功能模块吧?别慌,如果用MVC的理念怎么设计呢?

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

首先我们有3个重要的Controller(不是全部哦),包括:1个更新用户与角色关系的Controller,支持批量;1个更新角色与权限关系的Controller,支持批量;1个校验权限的Controller,支持不支持批量都行;其次,我们只有3个重要的Module,包括:1个用户与角色对应关系的Model;1个角色与权限对应关系的Model;1个用户与权限对应关系的Model;其实,我们也可以把这三个Model合并成1个,这样我就只需要一个“用户-角色-权限”的Model了。

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

此时,如果之前我们确实没有考虑到“批量修改”的情况,但是随着用户量增加,越来越多的用户想要这个功能了。怎么办?

如果我们在设计功能时用MVC的理念来考虑这个问题,只需要修改某一个Controller;并在前端的View上增加一些复选框的功能。

数据模型Model不需要做任何修改,所以数据库也就不需要做什么改动了。