互联网和产品 · 2018年07月17号 0

运营类产品经理常用的功能设计方案

运营类产品经理身边最常出现的一组功能设计,他们分别是检索列表、错误提醒、弹出确认框、树形菜单、消息通知和系统首页,设计的效果优劣不在我们的交流范围,我主要想表达一下这些功能背后隐藏的问题。

一、没有设计之检索列表

上下结构为主,上边一块区域是基于各种表格字段的检索区域(你也可以叫数据过滤)。下边是一张数据表格最后一列经常性的放着操作区,多半都是删除,修改或查看三个操作的各种组合,再多一点就是表格的首列是复选框,用于对整个表格数据进行批量操作,有时候还会带一些数据的导入、导出、关键字段的排序以及默认展示列等辅助功能。

运营类产品经理常用的功能设计方案

这就是这个功能的常规描述,基本大部分产品经理都可以通过这段描述定位到自己设计的系统中的影子,甚至很多人还会觉得自己的设计好像都是这样的,你也许会进一步问这不是很正常的一个功能设计吗?

那我们就通过这个常见功能聊聊需求分析与产品设计,我们通过两个问题展开话题。

话题1-用户用这个功能做什么?

这个才是关键,大部分人都没法说清晰用户用这个功能最后能解决什么问题,得到的答案很多都是用户会怎么使用这个功能的操作描述。

大多数产品经理,都没有通过需求分析过程,挖掘到用户的真实问题。第一次同用户接触时很难直接命中问题本源,往往基于用户自己的理解开始展开话题,我们对用户的需求有一个假设,基于这个假设给了一个产品设计方案。

用户对自己的需求也有一个直观的描述就是他心目中的产品设计方案,在一开始的时候大家就围绕着彼此的设计方案开始整个需求分析过程,没有人正常去进一步聊到用户的需求是什么,负责任点的产品经理会把自己猜测的需求,共享给用户进行大量的说服式引导,不负责任点的产品经理直接给用户一句话“回去把你的需求描述清楚吧”。

周围的产品最愿意用一句话来描述产品经理的工作是什么“发现问题、解决问题”,咱们暂且不谈这句话对产品经理的职责描述的是否准确。沿着这句话聊下去,都没有描述清楚用户的真正问题是什么,最后如何能够说明设计方案解决的用户问题。

需求分析是基础,没有最好这一点,不要先想着战略布局。

话题2-用户如何解决问题

有时候我们会自我安慰,这个功能设计够用了,能够完成用户的基本要求。造成这种现象的根本原因是习惯,大家都习惯拿身边现成的例子直接套用,尝试自我解释如何能够完成操作得到想要的结果,如果方案走得通就默认可行,也仅停步于可行。

这种方案带来的直接后果就是,系统中存在大量能用不好用的功能。用户与系统之间的关系可以简单分解成,系统提供用户需要的信息,用户根据系统提供的信息作出判断,最后通过操作给系统反馈,最终解决问题。

如果按照这个步骤分析下去,设计方案如何能够帮助用户快速准确找到关注的信息,提供的信息内容是否足够用户做出正确判断是产品设计时应该考虑的第一步。

当用户根据掌握的信息能够很好地做出决策时,产品应该提供用户清晰简明的操作方式,这是第二步。

基于这一原则,能用和好用带来的将是完全不同的设计方案,愿你在需求分析和产品设计上都能换个角度从新起步。

二、失败设计之错误提醒

错误提醒典型的场景,是出现在表单项每个控件附近的标红文字,或者干脆弹出一条错误提醒,或者莫名其妙的系统没有任何响应,联系研发同学才发现后台记录里有一条错误日志。

运营类产品经理常用的功能设计方案

《交互设计精髓》第三版第24章头一段文字是这样描述的:

“对话框用于错误消息(error message)、警告(alert)和确认(confirmation),这是三种现在图形用户界面设计中滥用得最多的元素。如果设计得当,这些对话框几乎可以完全消除”。

首先我们要清醒的认识到,到底是谁的错,很多产品都认为错误提醒,其实是用户没有按照系统的规定要求进行操作所带来的系统反馈,其实大家应该换个角度想想,用户是知道自己的目标是什么的,只是在做这件事的过程中,跟系统交流得到的反馈非常呆板。

为什么人与人之间交流的时候遇到不顺畅会通过调整来适应,人与系统之间如果遇到不顺畅得到的就是一个错误提醒。

错误消息不起作用,最讽刺的地方就是,我们自己设计的错误提醒其实根本无法阻止用户“犯错误”。

《设计心理学》里面诺曼特别拿出一个章节来讲错误设计,人们经常认为应该尽量避免出错,或是认为只有那些不熟悉技术或不认真工作的人才会犯错误,其实每个人都会出错。产品经理的错误则在于没有把人的差错这一因素考虑在内,设计出的产品容易造成操作上的失误,或使用户难以发现差错,即使发现了,也无法及时纠正。

现在有很多人把“反人性”设计的产品,叫“诺曼产品”,也许这是我们唯一跟设计大师有联系的一个点,就是我们的设计非常”反人性“。

不用提醒用户犯了什么错,应该帮助用户继续前进。严格意义上讲,这应该算针对“异常场景”设计的范畴,我特别提到针对“异常场景”而不是“异常”,其实就是想跟编程技术里面的异常设计区分一下。

一些编程语言专门会讲异常设计的部分,异常处理的好坏,直接影响到整个项目的代码质量,以及后期维护成本和难度,良好的异常设计对程序的可扩展性、可维护性、健壮性都起到至关重要。

从产品经理的角度我想表达的是,没有什么异常设计,一切设计都是围绕用户使用的操作场景,出现一些操作卡顿也算是一种正常的场景,这时候需要系统的设计方案能够辅助用户正常的操作下去。

现在身边很多产品经理大谈系统的智能化,其实我一直想说,连一个小小的异常场景,系统都不能自我的调整,或者辅助用户一起顺畅的往下继续前进,这时候就开始谈系统智能是不是有一点本末倒置。

三、糟糕设计之弹出确认框

弹出确认框一般都是居中弹出,上面一行小字,下边两个按钮,分别是“确定”和“取消”,有的时候会是“OK”和“Cancel”。

运营类产品经理常用的功能设计方案

据我的观察,大部分用户都已经养成习惯,默认点击回车键越过这一步骤,如果你把鼠标的锚点设置在“取消”按钮上,用户或是通过方向键加回车键搞定这个问题,或是干脆提一个需求把光标锚点直接调整到“确定”按钮上。

为什么我会单独拿一个大家都认为很“自然”的设计方案,来展开一段文字?

其实我是想通过弹出框引申出一段话题,产品的很多细节体验设计到底为谁而做,这里面有一个大家都熟悉,但很容易忽视的就是“用户”,产品经理每天面对很多交流的人,大部分人都会对产品经理提出各种诉求,但我们很少会把最终用户的诉求体现在产品设计上。

最近看一本书叫《用户故事与敏捷方法》,专门有一个章节讲“代理用户”。说的就是身边接触到的“非真实用户”,很多人在采集需求的时候往往考虑的都是这些噪音,这时候你就是用“乙方心态”在开展工作。

什么是“乙方心态”?

甲方负责验收你的成绩,你就是乙方,来做一套 IT 系统,甲方的老板,并不是最经常使用这个产品的人,但他决定满意度,他是客户;最经常使用这个产品的人,是公司的全体员工。这些员工,用互联网的语言来说,就叫作“用户”。

客户在考评你,但是不怎么用产品;用户在用产品,但是并不考评你,用户和客户常常不统一,是两群人。那这个时候我们到底应该听谁的呢?

大部分的乙方会选择,谁考评听谁的!所以,大量的乙方公司,做出了很多用来取悦甲方老板,但大部分员工很难使用的产品。这种心态,就是典型的乙方心态。

——摘录自刘润五分钟商学院

运营规划想引起使用者的重视,产品经理想要功能简洁,技术研发想要代码可扩展以及数据安全,体验设计岗想要风格的统一,最终的用户想要没有这个弹出确认框。

一个小小的确认框,带来的更多是忽视,以及对人机交互顺畅度的干扰。运营类系统设计过程中很容易忽视用户体验,因为他们没有选择,他们会被客户的决策影响。

你可能听说过,售前经理会竭尽全力的宣传产品的优势,让一家企业的客户买单,客户买回产品后,交给企业的最终用户使用,这些用户每天都会沉浸在充满弹出确认框的系统怀抱中。

因为这个确认框背后有流程严谨性的诉求,提醒用户慎重考虑自己的每一步操作;因为这个确认框背后有传统软件遗留下来的习惯,很多前端框架都默认提供样式精美的弹出框。

用户要的是系统帮我查缺补漏,用户要的是系统帮我提速完成考核任务,用户要的是系统默默地停在那里接受他的每一步决策。运营类产品也可以做到尽可能简洁,也许我有点夸大其词,但我只想引起你的一点重视,多考虑一下亲手设计产品的最终用户,也许你可以考虑从一个小小的弹出确认框开始。

四、复杂设计之树形菜单

树形菜单一般会出现在整个界面的上侧或左侧,有时候为了扩展性,这个功能会体现层级的概念,有时候内容过多还会出现可伸缩的效果,这就是我们非常熟悉的菜单。

运营类产品经理常用的功能设计方案

大部分运营类系统都是很多功能模块需要集成,菜单功能也是首选的功能连接器。你也许又会奇怪了,这很正常,能有啥问题。

你觉得占用太多的屏幕面积,我就设计可以最小化到屏幕侧边栏的版本;你觉得菜单项太多,我就给菜单加上权限,根据权限有选择地展示菜单项。

今天我们就从这个小小的菜单为起点,聊聊过度设计与极简设计。

1. 过度设计

最早听说过度设计这个听说这个名词那会儿,我还在做研发,后来接触了一些交互设计师朋友,也反复听说这词儿。不论是平面、产品、网站、App,还是建筑设计等领域,在用户需求之外强行增加了许多不必要的功能,都是过度设计,一切不好好设计让用户混乱的产品都是耍流氓。

那产品经理到底会不会过度设计呢?

身边的案例处处皆是,比如:今天咱们聊的树形菜单就是一例,它往往给人以复杂臃肿的感觉。

先谈复杂,因为有了这个引以为傲的可扩展菜单,我们在每一次的产品迭代时,都会很轻易的就为系统增肥,反正空间无限大,菜单多到一定程度还能分级,这就导致了产品经理把思路更多的引向了功能的堆砌,回去查查你设计的系统菜单项有多少,有的功能到底有什么用可能连你自己都不记得了。

2. 极简设计

极简设计,最早接触的时候还是在了解日本设计师原研哉的时候,第一次有所体会,谈到极简不得不提无印良品的极简风格,传达的气息让你过目不忘,将白色与留白用到极致,但不乏产品的功能性。身边简设计的案例Iphone手机Home键,几乎影响了所有的手机设计风格。

再谈极简,极简绝对不是仅仅说的风格的简单化,其实这是一种克制设计,轻易不让系统增肥(因为面对减肥系统跟我们人类的压力是一样的)。用户的精力是有限的,在繁杂的菜单中寻找自己需要的功能是对用户施加的额外工作量,在这方面,简单更多是指系统把你的工作主动推送给你,你只需要完成相应的决策,操作完就离开。

过往是用户通过菜单背后的那个功能,组合处理完一件任务。现在是系统将任务推送至用户面前,让用户给出自己的操作反馈,系统把每一个操作串联在一起完成最终目标。

高大上有品位的设计也可以从身边的小地方做起,明天你就可以看看如何代表月亮消灭菜单吧。

五、简陋设计之消息通知

消息通知包括关键环节的短信通知、针对用户端APP的消息提醒、不定期的邮件推送。

运营类产品经理常用的功能设计方案

随着移动互联时代的到来,我们几乎随时在线,时刻接受周围的大量信息,无效信息泛滥,内容过载是大多数人都面临的困境。

我曾经处理过针对企业用户的邮件通知投诉,大概就是由于规则设置的问题系统同时发送上千封邮件给一位企业用户,最终对用户的正常工作照成干扰。

说了这些其实想跟你分享两个概念:“渠道失效”和“通知心理学”。

1. 渠道失效

当今社会每天会接收大量的消息,手机已经成为随身器官,时刻与外界联系。

在没有消息的时代,很多产品疯狂地帮你聚集消息,在消息过载的今天,大部分产品都增加了帮你阻拦信息的功能。

Mail里的垃圾邮件,短信功能自带的设置为垃圾信息,APP的消息免提醒,电话的设置黑名单,大部分连接媒体都有这种阻拦类功能,如果用户的“火力全开”,可以说你就是一个有连接没联系的僵尸粉。

你能想到的联络渠道瞬间失效。

2. 通知心理学

我们所有人都被设计糟糕的通知和触发骚扰过。无关紧要的、不合时宜的、重复触发的消息冲刺着我们的生活。最糟糕的骚扰信息直接让善变的用户停止使用、退订、卸载那些不遵守构建优秀触发规则的产品。

如果不掌握一点消息通知的原则,你的用户将远离你的产品,通知的原则最起码具备三个特点:适时、可执行、激发好奇。

  1. 正常的触发是适时的:信息的发送要在合适的时间,选择用户最需要的内容,这样才可以建立与用户之间的信任关系。
  2. 有效的触发是可执行的:信息内容要具备指导意义,可以给用户带来价值,或是指导用户最近一步操作,或是安抚用户的焦急心情等,总之对用户来说不是毫无意义看两个字就删除的内容。
  3. 优秀的触发能激起好奇心:消息能够持续给用户带来惊喜,让用户产生好奇,最终情不自禁地进入系统一探究竟,这需要产品不断挖掘用户的“心思”,珍惜自己每一次与用户的接触点,不要把自己的信用像“小孩子喊狼来了一样”耗费殆尽。

六、尴尬设计之系统首页

登陆系统后第一个映入眼帘的洁面就是系统首页,如果你很懒只给你的系统首页设计了一个开机画面,或是把系统LOGO摆在首页,或是放一组欢迎语,这都算还好,还有很多系统的首页是由消息提醒,公告栏,日常KPI数据组合而成,有点类似直接把ERP的功能搬到了你的业务系统里。

运营类产品经理常用的功能设计方案

在解释上面提到的功能设计带来什么价值时,经常给出的理由是有效利用空间,挖掘系统最大价值,提升用户工作效率等。

今天我们就聊聊没有真实价值的功能,为什么会经常出现在产品设计里?

产品经理要把用户需求和产品价值有效的连接起来,经常出现上面连接不顺畅的根本原因是挖掘不到用户的真实需求是什么,以及搞不清楚产品的核心价值是什么?

1. 挖掘不出用户需求

产品经理挖掘不出用户的真实需求有几种常见的情况:

  1. 需求沟通过程中使用了很多专业类术语;
  2. 挖掘问题过程里过早地聊产品设计方案;
  3. 在产品实现的过程中很少及时验证;
  4. 对已无价值的功能很少总结反思;
  5. 很少同产品的最终使用者沟通。

2. 提炼不出产品价值

微信是如何一步一步通过迭代为产品添加功能,最后呈现出今天微信这款产品的模样。虽然每次产品迭代时都说如何提高用户体验,降低成本,其实我们很少知道我们自己设计的产品短期内会成为什么样子,更不用说未来还需要完善什么功能。

产品价值蓝图只有在总结汇报前临时拼凑,即使有价值蓝图也很少用于产品迭代过程的方向指导。针对产品的整体方向没有定位,反而对美化自己产品价值方面特别卖力的现象叫“产品陷阱”。

“产品陷阱”确实是个大陷阱,从“我的东西这么好,你们怎么就不懂呢”的陷阱中爬出来,调研调研用户到底要什么,这是每个产品经理应该真正思考的问题,产品经理不要做一名功能的堆砌工,要做一名蓝图的设计者。

如何在每一次产品迭代过程中,通过挖掘用户需求,不断修正产品定位,使产品迈向成熟而不是复杂,是产品经理应该慎重考虑的。

大部分产品经理都不同程度的存在方向性迷失,做事的出发点都是何时能上线,怎样能走通,这是我设计的功能,用户要买单,不买单就解释如何如何好,再让用户买单。

产品经理每年都要为自己设计的产品大大小小的做上百次修补,如果你紧盯着待上线功能列表来开展工作,产品注定会迷失定位,只有从如何为“真实用户”提供价值的角度判断,才有可能走上正轨。

这就要求产品经理要跳出自己的思维,不要陶醉在个人的工作成果中,不要过分依赖过往的成功经验,不要相信当前产品的稳定现状,不要觉得未来的挑战离你还远。

这些设计都由你亲手设计,选择照猫画虎,还是真正去做分析设计,给自己一个答案,也给用户多一种选择。