产品，最终的使用者是用户，可以说产品的所有设计、研发都是为了解决用户的需求。
一、产品，应该代表最广大用户的根本利益。
1.用户不说，不代表错误不存在
有时候，我在后台查看用户使用数据，常常会看到一些莫名其妙的错误。比如，有不少的学生向老师反映他们的作业交过，然后第二次看的时候，作业没了，甚至有的同学直接向老师反映说系统出问题了。而事实上，查看了一下系统记录，发现并未出现过任何的问题。那就只有一种可能，产品设计有问题了。于是，我反复使用提交作业的功能，经过多次尝试，终于复现该问题。因为，上传作业后，如果不点击提交，直接关闭网页，是不算成功提交作业的。在这个操作中，系统没有给出任何的警告。
这个产品设计的小瑕疵，导致了许多用户不能够成功提交作业，从而可能作业被判定为“迟交”或者“未交”。从而影响了成绩。解决的办法，很简单，就是在用户上传作业后，未提交作业，而是直接关闭网页的行为，给出一个弹框警告即可。
像这样的错误，可能有时候用户都意识不到是系统设计的错误，而误以为是他们自己的错误。这时候，用户虽然没有直接向我们反馈，但对于这种的无声的用户诉求，作为设计产品的我们，还是必须有能力去察觉到的。然后，想办法去解决。
2.用户说出来的需求，不一定是产品的需求
我本来想写“用户说出来的需求，不一定是产品真正的需求”，但我还是把“真正”这两个字去掉了。因为真正的需求，有时候也很难把握。
还是举例来说，在我们进入高校，对老师进行产品介绍和培训时，老师会提出各种各样的他们想要的功能。有的，可能是他们这一部分老师需要的，而有的，可能就仅仅是单个老师所需要的了。有个老师，就问我们能不能开发一个解决毕业论文管理和批阅的产品，他说他们学校自己做的论文管理系统太难用，经常出问题，而且没人维护和解决，希望我们的产品可以解决他们的需求。
这时候，我们就要在心里权衡一下了。论文管理，确实跟我们的产品会有些联系。这也确实是一个需求。但，目前不知道有多少老师会迫切需求这个功能。另外，论文管理其实是比较复杂的一个功能，包括导师、答辩小组、学生成员、论文的版本管理等，再高级点，可能就得接入论文查重的接口什么的。而我们的开发资源又极其有限，做这样的一个论文管理系统，可能耗费时间较多。所以，这个需求，就不是我们产品当前所需要的需求。
3.用户说出来的需求，可能会一语点醒产品人
自从我们的新版本上线后，负责接收用户反馈的邮箱，就很少收到用户反馈了。我和老板，都很奇怪，现在用户发送反馈，咋这么少了，难道是我们产品太好用，用户都不需要反馈了？不对呀，再好用的产品，肯定都会有人反馈问题的。这个疑惑没持续多长时间，直到我们与用户谈话后，才知道了，原来，我们的反馈入口和帮助中心，有的老师找不到。
这一下子，就让我们豁然开朗。所谓“当局者迷旁观者清”，大概如此。每天接触自家的产品，对自家产品，是过于熟悉了。有事没事，多跟用户聊聊，总是没错的。
二、用户也是分三六九等的
我所说的“三六九等”，意思是用户对产品的使用熟练程度的等级划分。
- 高级用户，他们可能不需求任何的帮助、培训和引导，上手即用。这类用户，往往更年轻化，使用软件更多，接触互联网更频繁。
- 中级用户，可能需要有使用引导，必要的时候，他们会打开帮助中心，查看一下帮助视频或者文档。
- 低级用户，这类用户往往是年长者，对于互联网接触少。他们使用产品，往往需要经过培训，而且使用初期可能会频繁使用帮助中心。
对于我们这些产品设计者来说，自然希望用户都是高级用户，不用教，直接用。但这是不可能的，尤其对于我们这种课堂管理工具来说。高级用户，可能是学生居多，中级用户是一些接触互联网较为频繁的老师，而低级用户可能就是一些年纪较大的老师了。
面对这三种不同的人群，不能对自己产品有过度的自信。这要看你的主要用户是哪类居多。如果是三类用户分布差异不大，还是建议，将帮助中心、引导都放在他们可以容易找到的地方，对于低级用户，应当根据情况，给与适当的培训等。