Unity ID
MR产品设计中的踩坑实践（一）

WuHao
阅读 422
2020年4月30日
DataMesh团队
本文邀请DataMesh产品经理王瑞为我们带来他的个人干货分享：作为一个在新兴的MR行业领域“先驱者”，在MR产品设计中都有哪些踩坑实践？将分为『需求』、『产品设计』、『硬件坑』、『与真实世界结合』四个板块来介绍。
一、需求
需求分析
任何产品设计，最终都还是要回到用户需求、客户需求层面上来，那么提到需求，还是免不了老生常谈的各种需求分析方法。
诸如用户体验五要素、马斯洛需求层次，需求三要素等。
那么对于我们在MR这个行业进行探索，做一个“先驱者”这样的角色时，我会采用的方法是场景式的需求分析法：
一个什么样的用户，在什么样的场景下，产生了一个什么样的需求？
这类的分析方式其实在C端用的非常广泛，并且C端产品有一个特点是，你可以是你自己产品的用户，可以很好的代入到产品中去；但同时这也会带来一个问题，那就是“过强的代入感”，把自己的想法强加给用户。
特别是在MR行业（目前又主要针对B端场景），弄清楚用户/客户的实际的痛点就显得格外的重要。
需求例举
此处以我们的产品DataMesh Director近期一个需求来去做例举：
用户： 小明，30岁，企业办公人员，文史类专业出身；能比较熟练的使用office软件，对三维模型有粗浅的认识。
场景： 小明在DataMesh Studio中编辑剧本，编辑到一半，小明的电脑突然断电了。
需求： 小明重启电脑，能够恢复之前的编辑，不会丢失之前那么长时间编辑的内容。
需求的本质是什么？
我们在收集需求的过程中，会接收到很多零零碎碎细节的意见或者建议，这类的东西往往都带有需求提出者的主观判断或者自身局限性。
这也要说到那个经典的案例，用户告诉我们他想要一辆更快的马车，那么我们就真的应该给他们马车吗？或许不一定，他只是想要更快、更舒服的从A点移动到B点，那么我们应该给他的可能是一辆汽车，一辆火车，或是一张机票。
那么在这种情境下，相比起直接给到方案，我们多问问为什么，搞清楚用户的需求，弄清楚问题的本质，才能够给到更加准确的解决方案。
另外其实很多同学在思考需求的时候，特别是有一定技术背景的产品，会很容易被实现限制，此处的建议是：先想清楚需求，再考虑实现，毕竟研发大大们往往都会说，需求你尽管提，只要它是合理的，总有办法实现的。
需求是否通用？
这个问题其实也是老生常谈了，为什么很多公司做着做着做成了一个外包公司，很多时候就是因为他们没有想清楚这个问题，客户要什么我就做什么，客户怎么想我就怎么想，最后发现做的所有工作都不通用。
我们在思考需求的时候需要有一种抽象思维，有没有什么办法可以同时满足A、B、C、D各种不同客户的相似的需求？
这里其实可以稍微提提”MVP”，很多同学说，如果不清楚需求是否有价值，可以先用MVP来去验证，这里其实有一个很多人经常会犯的问题，产品是可以MVP的，但是需求不能，需求是实际的，是能够满足长期使用，并且具备后续完善迭代的，你必须要实实在在的去解决了用户的问题，找到了他们的痛点，解决方案可以先最小先可用，但是场景不行，否则恐怕就会出现每次都在做MVP做PoC，最后做出来的MVP全都是用后即抛，没有验证到任何有价值的内容。
优先级是什么？
对于产品来说，优先级是一个非常频繁出现的词汇，但这里我想说的不仅仅是产品的优先级，更重要的是对于对方来说的优先级，或者对于不同的用户、不同的需求方的优先级。
此处同样以我司的产品来举例，我们的产品是面向B端客户的企业级产品，所以需要有相应的一些权限控制和License管理，那么就License这一条来说，对研发或者是对产品来说它的优先级其实并不高，我们有很多紧急的Bug需要Fix，有很多技术债需要去还，License这样的东西可以通过合同或者别的方式来去限制，那我们就会往之后去考虑。
但是对于市场部的同事来说就不一样了，License的存在与否，关系到市场的宣传策略，定价模式，另外也关乎到我们SaaS化及向开发者推广或者社区运营，那么在他们那边的优先级就会相当高。
在这种情况下，我们就需要很好的去权衡各方的优先级，并且综合地去做决策。
需求会带来多大的价值或者影响？
最后当所有的东西都想清楚了，开始要去做决策了，那么此时要去衡量的就是价值，或者说是影响了，需要投入类似的人力物力财力的情况下，越是高价值高影响的需求我们越是应该优先考虑。
至于如何来给需求定价值或者影响，办法就很多了，对于B端来说很多时候有个很简单粗暴的办法，看客户的付费意愿：十个客户想要A功能，每个愿意花十万，二十个客户想要B功能，但B功能不会成为他们做决策的关键点；那这个时候我们就认为A功能的价值远比B功能要高，此处仅仅举个例子，实际情况肯定会复杂很多。
如何获取需求？
说了这么多需求的判断，也稍微提提如何来去获取需求了，我在日常工作中主要的收集渠道大致可以分为如下几类，仅供参考：
讲讲MVP/PoC
MVP这个概念自打在《精益创业》中被提出来之后，便被广大产品同学们常常念叨，但实际上MVP到底有什么用，什么是最小、什么是可用？
其实可以举两个实际的案例来帮助大家理解：
·Dropbox
这个其实也是一个非常经典的案例了，Dropbox这款产品的特殊属性，意味着即便是要打造传统意义上的“最小可用产品”，也需要做到各个平台的应用及云端服务器的搭建，需要投入大量的成本，那么Dropbox的创始人是怎么做的呢？
他们用非常低的成本制作了这个视频，然后讲清楚了他们想要做的事情和他们想要实现的功能，最后的结果自然不用说，Dropbox在提交了这个视频之后： “成千上万的人来网站上去看视频，一夜之间我们的beta等待邮件(email list)从5,000个用户一下涨到75,000个。我们都惊呆了”
·多抓鱼
（此处援引自多抓鱼联合创始人陈拓的一次分享） 多抓鱼是一个二手书交易平台，以一个特定的价格收购二手书，然后清理、消毒、包装之后转卖给另外一部分用户；那么他们在早期是怎样用MVP的方式来探索需求的呢？
其实很简单，就是用微信群+Excel，他们先是将所有对这项服务感兴趣的人都拉到了一个群里面，然后用Excel来做记录交换信息，有人想在群里卖书，然后登记下来，有人想要买书，就在Excel里面进行挑选，非常高效低成本的完成了需求和场景的早期探索。
由于篇幅较长，为方便大家阅读，『MR产品设计中的踩坑实践』拆分成了三篇文章，以上就是“踩坑实践”之一的『需求坑』了，对于多数行业及产品都适用，下一期我们着重来讲讲MR相关的『产品设计坑』。
产品设计
Hololens
发布于技术支持