来自问题关于发现需求、筛选需求和设计产品，有哪些成体系的方法论？的回答。

先说两点东西:

1、我的理论是ucd的，而我的产品观也是推崇ucd的。

2、我的理论是有理论闭环的，但是理论只要闭环就存在不能覆盖的地方，存在边际效用。所以分享仅作为参考和交流。更多理论有机会继续和大家分享。

关于题目这部分我的框架。从用户那里探索到更多的信息，然后从用户那里获得验证确定你的功能真的能创造价值。用户验证部分不在本答案阐述范围，那边仍然存在内闭环，但是也是一堆复杂的东西就是了。

痛点是指用户感觉到不舒服，感觉到难受，感觉受到困扰的事情，也就是创造价值的人致力于解决的东西。

需求是指pm向开发提出的需要实现的东西。

1、用户探索为什么是必要的？

有很多答案中都提到了以自己为出发点设计一个让自己能兴奋，能满意的产品，这是典型的hcd理论，我认为hcd理论是更适合工业时代，而互联网时代我更推崇ucd。你能满意，你能兴奋，但是你真的是你的用户么？你真的了解你的用户痛点么？你的用户真的都会为了你的产品欢呼雀跃么？你觉得你的产品能解决问题你的用户的问题能真的被解决么？用户使用你产品的场景真的没有问题么？

停止自我满足，放空自己，了解用户。

不要用自己曾经的知识和经验去设计产品，用用户的感受和对未来的期待去设计。

当你觉得你有了一些ideal 或者似乎发现了一些痛点，就可以开始进入我们的用户痛点探索闭环了。

2、用户探索的四个步骤是什么？

希望上一个问题能让你认识到用户探索的重要性，那么我的理论中用户探索由四个步骤组成：用户调研、特性总结、痛点归纳、解决方案。

每一个步骤的失误都意味着你会在用户验证时发现问题，然后重新设计一轮。所以设计中请杜绝拍脑袋，放空自己以用户为中心。

时刻关注顶层：我的用户的生活是怎样的。

3、如何进行用户调研？

用户调研方法有非常非常多，大公司也有自己的用研部门，出用研报告，还有大家可以看到烂大街的用户调查问卷。但是首先确保，你的每一个对象都是你的目标用户。浅谈几个方法。

3.1 调查问卷

我必须要说调查问卷需要认真学习一下问卷的设计，至少请阅读这个答案怎样设计一份好的调查问卷？ - 问卷调查，这是最基本最基本的请求。

问卷问题一定要问回答者的事实和情景，而不是意愿。

例如“如果有一个夜间定时大幅度打折的活动您愿意参加么？”

这个问题就是典型的问对方你愿不愿意，调查者的目光会放在打折上，有便宜你占不占，他肯定占。最后的答案就会让你欢呼雀跃，可行可行！

但是问题变化一下，

“你多久网购一次？”

“你一般会在什么时间段网购？”

“多少折扣会让你考虑立刻去购物车买东西？”

这些问题相对而言都是偏客观的，尝试询问情景的，你最后获得的信息不仅可以描绘这个纬度，还可以描绘更多的东西。这个阶段的事实性的、情境性的问题越多，下一个阶段你会有越多的素材。

我每次在做一些问题设计的想让我吐血的问卷时我都想拉出来问卷设计者，你到底有没有动脑子设计问卷？

对了，想阅读更多问卷设计相关理论知识？

3.2 访谈调查

访谈是我最推崇的调查方法之一，是一个非常好的和目标人群互动的方式。

访谈就像是你设计好问卷面对面用语言让他问答。你设计的问题是主线，而他的回答中透露的种种信息是你对这类用户真实生活感同身受的关键机会。

语言会过滤掉很多信息，在访谈的时候一定要放空自己，不要带着情绪去judge，对受访者情绪变化、倾诉欲望、表情转变都要敏感。这些往往是痛点存在的机会，遇到这些地方，及时深挖。

选取受访对象也一定要多纬度分层选取，男女都选一些，学霸学渣都选一些，在校走读都选一些，根据你希望得到的信息纬度来确定你要访问哪些人，其实访谈非常耗时耗精力，但是相信我，这会让你更好的把握用户，你的努力会有所值。PS.有机会认识极端用户时一定要认真访谈甚至完全抛开问题，因为这类用户要么被痛点折磨的最深，要么已经有自己的解决痛点的替代方案，征服hell会让你对于easy难度游刃有余。

访谈单次获得的信息适中，能覆盖的人数也适中，更适合已经有一定思路进行confirm和更深了解用户。

3.3 浸入式体验

用户的感受有时候靠语言真的很难把握，而浸入式体验给了你最直接的体验，让你成为用户的一份子：盲人产品你不蒙着眼罩生活一两天好意思做设计？残疾人产品你不让自己左腿打石膏生活一周么？

这是最直接的体验，类似的还有很多，例如进入他们的环境观察，给小孩子设计早教产品一定要去幼儿园观摩学习；校园外卖一定要和通宵游戏宅一起玩两天；考研教育产品一定要跟着考研的同学一起生活一天。

去观察，感受，了解，体验。把自己当作自己的用户，你看到了什么？

浸入式体验单词获得的信息量最大，海量的场景，但是能覆盖的人数最少，适用于建立用户感觉，痛点发掘。

当你的团队进行完用户调研后，每个人脑子里都有一大堆关于用户的信息，海量的信息，然后接下来的步骤你将一步一步面临大量信息的筛选和遗落，所以一个好的产品设计师可以让自己接下来的环节留下更多有价值的信息。

4、如何进行特性总结？

团队需要在一个大大的白板上，或者一堆纸上，疯狂的写下自己认为也许存有痛点或者有值得研究点的场景，一般来说每个人至少能写十个（如果你们真的认真调研的话），大量的场景会被提出，你可以初步在心中体会到那一片用户的生活隐隐的展现了一个普遍的模样在你眼前呈现。

而此时你们要做的是把场景体现的一些特点特性写出来，每一个场景都要全队刷，一开始写的时候所有人都不要说话，全力以赴的写，然后大家开始对，没出现的写在这个场景下面，出现的、同义的就不要写，假如五个人，第四个人开始应该基本没有什么新的特性出现了（如果五个人分析能力在一个层级），但是由于个人经历和分析偏重不同，每个人应该还能出现几条新的。

然后重复这个过程。

最后将所有场景的特点都按照你们在意的几个纬度分纬度列出来，可能一条特点占数个纬度，但是全部按纬度分类列下来。

整个流程大致是

然后你们会得到一大片特点图，这就是这群用户和普通人不一样的地方。

5、如何进行痛点归纳？

痛点有很多，你们会根据特性写出用户很多很多的痛点，甚至有时候你会发现你最初idea中所看到的痛点根本不够痛！

但是请不要急于激动，我们仍然需要分析这些痛点，一般来说做出一个二象限图，像这样将所有痛点贴上去：

然后你明白，应该优先解决A，这是优先级最高的痛点，发现这种痛点我会在便利贴上写出来它旁边注明SS；而B可能是你们短期流量爆发的点，C则是帮助留存的点，D的话我一般的建议是别浪费资源去解决了……除非你在一个处于成熟期中后期的产品。

6、如何给出解决方案？

一般一个普通的pm看到痛点就会迅速给出solution，这个solution往往能解决“问题”，“给我一个按首字母排序和按照时间排序的功能。” 然后你花费程序猿一天时间给了他两个功能。他接着说：“再给我按照数量排序啦！”然后你又去找程序猿提需求。

其实他真正的需要很可能是一个数据表单加搜索功能。

那么回到我们的理论，我们应该在痛点和解决方案之间停下来，认真探索哪些痛点是有一个solution一起解决的？哪些痛点的solution也许有不同的角度？哪些solution根据我们对用户的了解是更能让他们接受的？

评估solution指标一般是：

1、自己团队的开发能力开发周期，同等条件做开发快的。

2、评估solution解决的痛点强度，可能一个只能解决一个A的solution不如一个开发更快但是能解决两个C和两个B的重要。

3、评估solution对用户的acceptable，可能一个风格不对的solution用户根本不买账或者根本不符合实际。

这样确定了解决方案，来进行功能设计、原型制作、UI制作、程序开发等等。

之后上线，然后转入用户验证（那是另一个世界）。

然后发现新的问题和想法，再进行用户探索的四步骤确定用户到底痛点在哪。而这就是迭代了。

敬畏设计，尊重用户。

因为没有完美的产品和完美的设计，所以我们才不会失业。