迁燕京]产品设计:怎么让功能既灵便又简单?

大家在网页上开展搜索时,就会发现仅用关键字就能找到自己喜欢的具体内容,或是刚输入关键字下面就来会出现一些有关联内容,十分省时省力;文中创作者点赞了如何让功能越来越即灵便又简单,大家一起来学习一下。

 


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

 

功能是产品运营最基本专业技能,都是商品最基本构成部分和意义所在。

因此,无论是在工作上,还是面试中,一个功能设计成太复杂了或者很鸡肋,都是会立即降低别人对你的第一印象!!!

但产品设计中,灵便与简易这俩特点的确往往是矛盾的。

尤其是在工具型产品中,大家要把功能设计方案的很灵便,就常常会使用起来非常复杂;如果要设计成非常简单,又也会减少功能性,显得特别鸡肋。

自然还有一个办法,便是在简单功能里加入机器学习模型;不过要是精英团队本身累积不够,这一办法投入就太高且使用价值又过小,并不是个好办法。

举例说明:在现如今的产品上,涉及到的信息内容愈来愈多、愈来愈繁杂,因此搜索功能就会越来越关键了。

在搜索功能上,我们既希望可以充足灵便(例如适用各种各样标准组成,适用“与或非”这些),又希望充足简易(像一般文字输入一样)。

该怎么办呢?

这是一个比较最典型的窘境,我们来看一下百度搜索、Google等通用性搜索模块是怎么做成的。

它在“简易”上做得非常优异,当要好几个关键字时,只要用空格符分隔就行了。

 


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

 

很好是吧?可是,再看一下他们解决“灵便”最高级的搜索功能……

 


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

 

这儿的确带来了充足的协调能力,但整个设计方案就崩塌了;所以从1个文本框成了10项配备,太复杂了!!!

那如果添加机器学习模型呢?就是这样:

 


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

 

这种强烈推荐看似,那如果要好好做,需要花费许多人力资源与时间才能达到。

因此,百度搜索这是一个不成功的设计方案吗?

其实不是——假如你是百度搜索搜索模块的深度用户,那样你应该知道这样一组搜索命令:

用加号“-”意味着清除关键词;

用“intitle:”意味着关键词只出现在了文章标题中;

用“inurl:” 意味着关键词只出现在了URL中;

用“filetype:”意味着只爱看一些文件属性,例如docx、pdf;

用“site:”意味着只想要搜索某一网站里面的内容;

上面这些命令也都可以在搜索框中键入,既满足高端消费者的需求,又也不会影响初中级消费者的使用感受。这便完成了既灵便又简单。

那样,如果你想要在规划自己的品牌的时候也保证灵便而简易,该怎么做呢?

最先,大家定义问题的范围。

灵便与简单选择,不是一个单纯的人机交互问题,它还涉及到前面页面交互与后端系统相互配合;因此单单从人机交互的视角无法找到回答。

这儿务必说一点:若想提高针对商品的认知,必须训练自已的抽象思考水平。

在这儿,我们就要把具体产品交互做一次抽象化和提炼出,寻找这其中的规律性;有技术背景的同学们在这一方面会占优势。

为何?由于技术语言本来就是对事情的抽象化。

次之,我们应该摆脱一种思维定式:“一个功能是一体的,不会再分为”;其实并非如此,就拿上边的搜索模块举例说明,它和用户有关的那一部分大概能够分解成2个子模块:

因此,恰好是这两大类导致了灵便与简易难以选择——客户随便输入具体内容系统软件难以分析;而系统软件便捷分析内容对消费者来说太复杂了。

最终,大家可以参考行业领域的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。

除非是我们可以把“插入折线图”和“插进柱形图”作为彻底不相干的2个功能设计制作;但是这显而易见不科学,并且已经跑题了,大家不在这里探讨。

如今您有感受到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不应该做一切改动,因此数据库系统也就不再要做什么修改了。

原创文章,作者:leping,如若转载,请注明出处:https://www.qlhjjj.com/biao-3236.html

(0)
上一篇 2022年9月20日
下一篇 2022年9月20日

相关推荐

粤公网安备 44522402000168号