从用户中来,到用户中去

产品,最终的使用者是用户,可以说产品的所有设计、研发都是为了解决用户的需求。

一、产品,应该代表最广大用户的根本利益。

1.用户不说,不代表错误不存在

有时候,我在后台查看用户使用数据,常常会看到一些莫名其妙的错误。比如,有不少的学生向老师反映他们的作业交过,然后第二次看的时候,作业没了,甚至有的同学直接向老师反映说系统出问题了。而事实上,查看了一下系统记录,发现并未出现过任何的问题。那就只有一种可能,产品设计有问题了。于是,我反复使用提交作业的功能,经过多次尝试,终于复现该问题。因为,上传作业后,如果不点击提交,直接关闭网页,是不算成功提交作业的。在这个操作中,系统没有给出任何的警告。

这个产品设计的小瑕疵,导致了许多用户不能够成功提交作业,从而可能作业被判定为“迟交”或者“未交”。从而影响了成绩。解决的办法,很简单,就是在用户上传作业后,未提交作业,而是直接关闭网页的行为,给出一个弹框警告即可。

像这样的错误,可能有时候用户都意识不到是系统设计的错误,而误以为是他们自己的错误。这时候,用户虽然没有直接向我们反馈,但对于这种的无声的用户诉求,作为设计产品的我们,还是必须有能力去察觉到的。然后,想办法去解决。

2.用户说出来的需求,不一定是产品的需求

我本来想写“用户说出来的需求,不一定是产品真正的需求”,但我还是把“真正”这两个字去掉了。因为真正的需求,有时候也很难把握。

还是举例来说,在我们进入高校,对老师进行产品介绍和培训时,老师会提出各种各样的他们想要的功能。有的,可能是他们这一部分老师需要的,而有的,可能就仅仅是单个老师所需要的了。有个老师,就问我们能不能开发一个解决毕业论文管理和批阅的产品,他说他们学校自己做的论文管理系统太难用,经常出问题,而且没人维护和解决,希望我们的产品可以解决他们的需求。

这时候,我们就要在心里权衡一下了。论文管理,确实跟我们的产品会有些联系。这也确实是一个需求。但,目前不知道有多少老师会迫切需求这个功能。另外,论文管理其实是比较复杂的一个功能,包括导师、答辩小组、学生成员、论文的版本管理等,再高级点,可能就得接入论文查重的接口什么的。而我们的开发资源又极其有限,做这样的一个论文管理系统,可能耗费时间较多。所以,这个需求,就不是我们产品当前所需要的需求。

3.用户说出来的需求,可能会一语点醒产品人

自从我们的新版本上线后,负责接收用户反馈的邮箱,就很少收到用户反馈了。我和老板,都很奇怪,现在用户发送反馈,咋这么少了,难道是我们产品太好用,用户都不需要反馈了?不对呀,再好用的产品,肯定都会有人反馈问题的。这个疑惑没持续多长时间,直到我们与用户谈话后,才知道了,原来,我们的反馈入口和帮助中心,有的老师找不到。

这一下子,就让我们豁然开朗。所谓“当局者迷旁观者清”,大概如此。每天接触自家的产品,对自家产品,是过于熟悉了。有事没事,多跟用户聊聊,总是没错的。

二、用户也是分三六九等的

我所说的“三六九等”,意思是用户对产品的使用熟练程度的等级划分。

  • 高级用户,他们可能不需求任何的帮助、培训和引导,上手即用。这类用户,往往更年轻化,使用软件更多,接触互联网更频繁。
  • 中级用户,可能需要有使用引导,必要的时候,他们会打开帮助中心,查看一下帮助视频或者文档。
  • 低级用户,这类用户往往是年长者,对于互联网接触少。他们使用产品,往往需要经过培训,而且使用初期可能会频繁使用帮助中心。

对于我们这些产品设计者来说,自然希望用户都是高级用户,不用教,直接用。但这是不可能的,尤其对于我们这种课堂管理工具来说。高级用户,可能是学生居多,中级用户是一些接触互联网较为频繁的老师,而低级用户可能就是一些年纪较大的老师了。

面对这三种不同的人群,不能对自己产品有过度的自信。这要看你的主要用户是哪类居多。如果是三类用户分布差异不大,还是建议,将帮助中心、引导都放在他们可以容易找到的地方,对于低级用户,应当根据情况,给与适当的培训等。

发表评论

电子邮件地址不会被公开。 必填项已用*标注