1/6“没有设计之检索列表”-需求分析与设计（升级版）

今天我们聊聊身边最常出现的一个产品设计，一说你就知道这种设计几乎遍布整个系统的每个角落

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

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

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

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

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

大多数产品经理都没有通过需求分析过程挖掘到用户的真实问题。第一次同用户接触时很难直接命中问题本源，往往基于用户自己的理解开始展开话题，我们对用户的需求有一个假设，基于这个假设给了一个产品设计方案，用户对自己的需求也有一个直观的描述就是他心目中的产品设计方案，在一开始的时候大家就围绕着彼此的设计方案开始整个需求分析过程，没有人正常去进一步聊到用户的需求是什么，负责任点的产品经理会把自己猜测的需求共享给用户进行大量的说服式引导，不负责任点的产品经理直接给用户一句话“回去把你的需求描述清楚吧”。

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

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

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

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

这种方案带来的直接后果就是系统中存在大量能用不好用的功能。

用户与系统之间的关系可以简单分解成，系统提供用户需要的信息，用户根据系统提供的信息作出判断，最后通过操作给系统反馈，最终解决问题。

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

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

基于这一原则，能用和好用带来的将是完全不同的设计方案

愿你在需求分析和产品设计上都能换个角度从新起步

二零一八年二月十四日于鸡西

下一篇：2/6“ 失败设计之错误提醒”-异常设计