产品经理给《爱死机S1E7》中外星人女主的建议
故事简介
首先简短的介绍一下故事内容，以方便没有观看过这部作品又非要看我扯下去的读者来大概了解下情况。故事发生在近未来时期，全宇宙低等级文明的人类，通过一个神级文明留下的“星际高速路”实现了星际之间的旅行。我们故事的主人公就是个往返于各个星系之间的“大货司机”，主要靠超载，抄近路等手段从星际资本家那边讨生活。高速路就是下边酱婶的，右边那个光圈里进去，嗖一下就到目的地了。
由于是神级文明，其他文明都掌握不了他们的技术原理，只能停留在应用层，时常因为使用不当出现一点小问题。我们点背的主角和他的两个船员就在最近这次旅行中迷路了，还不是一点两点的小偏差，是到了一个看似熟悉，实则吓死人的宇宙坟场。
坟场的主人是另一个文明的外星人，拥有控制其他生物意识，制造VR场景的能力。本剧中就出于对主角的临终关怀，开始了一次不太成功的尝试。下边我将从剧情展开，看看我们的女主为了解决男主能有尊严、无痛苦的死去这个“核心痛点”而做的一系列努力，有哪些可取之处，又有哪些可以优化的点。
01 初见空间站——产品框架设计
首先我们的女主通过SWOT分析，明确自己团队在VR技术上有先天优势，全宇宙领先。从底层技术来看，女主的产品的确无懈可击，给优化和创新提供了最坚实的支撑，是所有后续展开的基础。基于项目目的目标，再结合团队背景，决定了女主设计的产品到底是什么。一句话总结，女主的产品就是一款基于VR技术，满足用户怎么不知不觉开开心心死去这个需求的沉浸式体验产品。
对我们做产品的启示是：一个项目的立项阶段，在明确项目的目的目标之后，第一就是要确定团队能力天花板，明确哪些我们能做，哪些技术我们可以利用。如果剧中女主的能力不是精神控制，而是什么随意变换形态（有点不敢想象随意变换形态，男主知道真相后会不会猝死），那为了解决痛点其实也是有很多其他手段可以用的。也就是说，最开始我们要确定好核心产品形态，下一步才是开始整个产品的框架设计展开。
对于产品框架设计，有句话讲的好：一切脱离业务的架构都是耍流氓。
剧中女主的产品主要业务流程就是通过对话心理疏导，以及一些生理上的“疏导”，来平复男主焦虑的心情，稳住男主，已达到男主在不知不觉中平静的老死的目的。提炼其中的关键点，就是要有对话流程，要有“身体上的互动”这两个主要业务交互；然后就是时间要能维持够长，否则男主还老不死（大雾）。
基于这个主业务，女主首先把整个产品形态设计成为一个人类的大型维修空间站，为了业务具体实施，又设计了酒吧，床，导航电脑，其他NPC等一系列功能模块。最重要的是设计了自己，这个互动主要功能。
这里我就不累述每个功能点的作用，主要谈谈最基础的产品形态。
当我们男主从冬眠中苏醒之后，第一眼就看见了一个地球文明的空间站。此处很重要，因为此时是在用户的激活流程中：在用户触达产品的最开始时间，你的产品营造什么氛围相当重要。我们来看下女主是这么做的：
由于网上不好找资源，这段GIF取自B站
此处，我们可以看出，所有可见的范围被女主进行了重新包装，选用了地球文明熟悉的空间站形态，而不是直接以它本来的面目展示给男主，我估计如果她不整这一出，男主苏醒过来的那一瞬间估计就要吓死了。所以给我们的产品启示就是，一定要注意目标用户的使用习惯，不要刻意做太个性化的创新，在保证产品本身的易用性的前提下来规划和设计交互。此段来看，女主的设计并没有其他问题，如果我是女主的话，我可能会设计更多的NPC来活跃社区氛围，比如机器人点赞在社区应用中很常见。即用户主要需求被满足之后，还有炫耀和展示的需求。
02 女主——用户核心痛点的定位
在描述女主这个功能设计的之前，我们先来看看男主。
目标用户明确，那我们就先给男主做个用户画像：
用户男，40岁左右，飞船船长，工作强度大，但是收入高，以船为家，社交范围窄，没有家庭或离异。喜欢冒险，自信，身强体壮，富有人格魅力。
基于这个用户画像，我们可以明白，男主的一些性格特征：工作强度大，收入高，则对于娱乐的需求和投入会较大；没有家庭，身强体壮，又富有人格魅力，则很容易吸引女性，也容易被女性靠近；因为自信，对漂亮女性的戒备心小，对有竞争关系的男性戒心重。然后我再回过头来看女主伪装出来的这个形象（女主真身本剧最大亮点，建议自己去看哈）：
男主之前认识的人，发生过不可描述的事情但是并不是熟人。这里我非常赞赏我们真实女主的选择，她肯定是在浏览了男主所有记忆之后，挑选了最合适的一个形象角色：好看，柔弱的女性形象，第一反应不会让用户排斥，有进一步接触的欲望；又是有过接触的人，可以最大程度减少用户戒心。
为什么不是男主的家人？
因为此处的场景离地球十万八千里，虽然用户熟知的人可能更能赢得用户的信任，但并不是所有场景都适合熟人关系的。比如，作为空巢老人突然接到孩子的微信说出车祸了需要打钱，相信大部分人第一反应是，这是个骗子吧。
为什么不是其他认识的男性角色？
我们通过对用户属性的分析，可以得知男主的背景和个性决定了他应该很少有交心的朋友，就算有，能交心的程度也存疑，毕竟常年的职业特性，应该要求他时刻保持危机意识。其次还是对场景的分析，孤男寡女在一个空间还好说，两个男的天天喝酒么？有点难。
为什么不是其他陌生人？
这个应该更好解释，毕竟默认人想要建立信任更难，尤其是在没有平台和其他用户认证的情况下，依靠单个用户对一个产品产生信任，本身就是个难题。所以我们在产品设计的时候，都考虑到了要做用户评价系统，做官方认证内容等手段。
基于以上考虑，总结起来就是说：在发掘用户核心需求的时候，一定要基于目标用户属性和使用场景两个角度来看，却一不可。
本剧最完美的设计就在女主伪装的这个形象身上，可见一个针对用户核心需求而定制出来的功能是多么吸引人。
03 知道真相——不要用户要什么就给什么
本片的高潮部分，男主通过船员NPC的提醒看出破绽之后，逼着女主让他知道事情的真相，然后如愿以偿知道了所有的答案。但是呢，就差那么一丢丢，男主就要被吓死了。整个项目前功尽弃就在这一瞬间，好在女主及时回滚版本，才得以维持用户活跃而不流失。
现实中的男主，清醒的一瞬间看到的世界
此处给部分年轻产品经理在唠叨一个老生常谈的道理：用户真正想要的不一定是他表达出来的内容。
大家都知道，通过一些正儿八经的方法，除非有相当的技巧，否则用户基本上不会跟你说真话。无数产品悲剧都是由此而来，其中著名的案例就是多年前可口可乐的新配方的失败。80年代可口可乐为了对抗百事可乐的冲击，在美国10多个主要城市进行消费者调研，问用户“认为可口可乐口感如何？”“想试一下新饮料吗？”“可口可乐口感变得更柔和一些，你会尝试吗？”
调研结果显示用户普遍希望可口可乐出新口味。然而……当可口可乐真的做出新可乐时，却招致用户大量投诉抗议，最后新可乐只卖了3个月。
那么一般，我们有什么手段可以知道用户真实的想法呢？
这里简单介绍一些办法，具体内容相信网上相关介绍蛮多的。
- 深度访谈，找出描述性词汇，而非名词。比如做产品的人都知道，福特造车之前问过的问题，得到的反馈是“我想要一架更快的马车”。这个反馈的重点是马车么？肯定不是，其实用户是要更快的交通工具。
- 行为而不是观点。防止被用户忽悠的某种极端办法就是不去听，而去看。比如最明显的是，投放广告的之前，用户都要看到产品细节，到最后数据却发现导购角色比产品本身影响更大。其他领域也都可以通过实验的方法来获得结果，这也就是MVP重要的原因。
- 不断追问。你为什么要来这儿？因为我要开车。你为什么要开车？因为我要回家。你为什么要回家？因为我现在饿了。那我现在请你吃顿饭，你可以多陪我聊会儿么？好啊！这边举这个我现编的很弱智的例子，具体使用的时候请大家自己体会。
到此，女主最大的败笔，就是男主说我要真相就给了真相，如果是我，我可能会想设计一次其他飞船的事故，以第三者的视角先让男主明白整个项目的意义，再投射到自己身上。也就是说，在用户提出需求的时候，应该先用一些其他的引导方式试着梳理问题，最后才是简单粗暴的执行。
04 又一次轮回——快速迭代的重要性
在女主回滚数据之后，男主又一次从休眠仓中苏醒，两人又开始刚见面时的对话，只不过，此时的场景里。跟男主一起过来的两个船员的身影却不见了。原来，上一次宕机事故的罪魁祸首是男主潜意识里的反叛精神投射到NPC身上导致的，也就是让女主暴露破绽的女船员。所以，这次更新版本，直接把这个功能砍掉了。哈哈哈，就是这么简单粗暴。
如果我是女主，以做产品的思维，在迭代过程中我可能不会那么简单粗暴的直接删除某个可能会引起bug的功能，这里需要对流程和数据的精确分析，聚焦到BUG本身，而不是把相关功能一块删掉，哪怕是之前觉得鸡肋的模块，也可能牵一发动全身。
影片到此戛然而止，估计以男主现实情况的体格，这一轮模拟之后应该会死了吧。到此我们女主的主要任务就算完成啦。作为产品经理，我最后说一句，养成根据用户反馈产品数据快速迭代的好习惯，产品是不断优化完善的，不可能一蹴而就。
好了，我扯不动了，这集虽然短，但是还是有很多可以发掘和思考的点，这边我就不再发散了，还是安利你们自己去看吧。这边这些产品知识我聊得很零散，算是自己在看剧过程中的一次知识的梳理。不知道别的产品小伙伴平时看电影，看世界会不会像我这么矫情去套方法论，哈哈哈。不管你是不是，欢迎跟我交流，产品本身，科幻，推理，心理学都是我的领域！
作者：许士通，微信公众号：野狗王的士高（ID：mrentropee） ，前搜狐畅游产品经理，目前从事大健康领域产品工作。研究生学习心理学，针对产品中的心理问题有些许思考。欢迎加我讨论~
本文作者 @许卡通 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
