不负责任点的产品经理直接给用户一句话“回

2018-08-02 09:41 来源:未知

  今天我们聊聊运营类产品经理身边最常出现的一组功能设计,简单的描述一下你就能把这几种设计对号入座,因为它们几乎遍布整个系统的每个角落。

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

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

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

  那我们就通过这个常见功能聊聊需求分析与产品设计,我们通过两个问题展开线-用户用这个功能做什么?

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

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

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

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

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

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

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

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

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

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

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

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

  《设计心理学》里面诺曼特别拿出一个章节来讲错误设。