想要更棒的阅读体验？

你还可以在我的博客查看全文（https://steveoon.me/2016/06/13/the-role-of-framer-in-the-combat/）

或者在知乎专栏查看（不支持GIF动图）

三年前，我曾写了一篇文章「交互设计路径分析-让用户对你的APP了如指掌」，在文章中分析了在做APP的交互路径设计时的思路，并且用一些实例进行了对比。这两天突然发现人人都是产品经理出现了我的这篇文章，当然是掐头去尾的复制了部分段落（心中落泪，感谢你们在我不知情的情况下把这篇文章放了上去T_T）。言归正传，之后的时间中由于作者懒（忙）癌（着）病（恋）发（爱），到目前为止都没有把这几年中的个别项目设计过程沉淀下来，怎么可以这样？！这不符合我做人的社会主义核心价值观啊！有木有？介于此，我打算讲最近的一个故事，COME ON BABY LET'S GO~

接下来，这篇文章中大概会涉及到的一些内容（你要的干货）：

• 理解产品并定义它的方向
• 需求挖掘、采集以及演变为功能
• 可操作交互原型的重要性
• Sprint Process

| 虚拟现实播放器「VR PLAYER」

为什么要做VR播放器？答案很简单：因为最近VR很火爆，刚刚过去的Google I/O 2016上，Google也发布了他的VR平台叫做Daydream（白日梦？），该平台集成在Android N里面，各大手机制造厂商都会在随后的机型中增加对该功能的支持。大势所趋，我们也去蹭一杯羹。

内容导向 VS 技术导向？接到需求后，在产品初期的定义中，我们有两个方向「以内容为导向的平台型产品」类似优酷土豆、爱奇艺等偏向内容构建 or 「以技术为导向的工具型产品」比如早期的暴风影音、QQ播放器等以技术特性为出发点。最终确定将产品初期形态定义为已技术为导向的工具型产品。

为什么？

我们有一个还不错的技术解决方案供应商

初期想构建庞大且高质量的VR视频内容，需要非常专业的人和设备

内容需要逐步堆积起来，才能慢慢形成一个资源池，并非一朝一夕就能搞定

既然产品初期形态确定了，接下来所有的一切，都必须围绕：

技术导向的工具，他是一个工具，一个顺手的工具

基于此，团队的设计师们组了个局，通常设计师们喜欢管这个局叫「brain storm」，在这个局上，我们开始思考的一个问题是：一个工具型的VR播放器应该为用户带来哪些便利？这类用户应该具备什么特质？

咳咳~不好意思我要打断一下，这种脑暴真的有用吗？

小明，这个问题问的好，你可以把手放下了。脑暴当然有用，尤其可以发散每个人的思维树，可以让观点不局限在一个固定的维度，但脑暴的主持人非常关键，毕竟我们需要的是在天马行空之后，把能够落地的点子沉淀下来。所以脑暴的时候，主持人应当注意让大家讨论的点都是围绕在一个核心需求上，可以把这个核心需求看做一颗大树的树冠，所有枝杈在发散的时候一旦出现其中一根树枝长歪了或者准备长歪了，主持人需要把它修剪掉（就好像园艺工那样），脑暴的过程可以遵循一些已有的方法，比如我们会针对几个核心问题，在一个规定的时间内，每个人写出5个想法，然后把Tips传递到下一个人，根据你看到的其他人的一些点子再写5个，如此循环到你看到的点子差不多已经接近了（一般2-3轮）为止，然后分为两组挑选各自认为可行的点子整理成一个方案进行一个15分钟辩论，最终筛选出可行的点。值得注意的是，在辩论的过程中每个人都应该尽量规避一些可以导致非理性决策的「认知偏误」，有时候当你想要验证自己的决定是否理性时，可以参考这个认知偏误列表，然后再反思一下。

到这里，参与脑暴的每个人应该已经非常了解「我们要做什么？」和「我们该怎么做？」，那么接下来，不要忘了老板的需求（一般是商业方面的诉求），不要忘了竞品分析的结论，如果是一个大版本的迭代，不要忘了要一些之前版本的运营数据，做一个数据分析，毕竟当你调整一个入口时，并不是拍脑袋决定的，而且基于数据决定的，所有的这些细枝末节必须非常重视。

因为用户体验的好坏是无数细节堆砌而成的。

把所有这些需求整理一下，形成一个文档，把需求列个表，注明优先级。在对每一个功能点细化之后，第一件事情当然是梳理出一个流程框架，目的是让自己和团队对产品的功能结构有一个清晰的理解，同时方便攻城狮们开发。之后我会把每个功能点「串联」起来，形成一个故事版，然后用线框图把每个故事版表现出来，目的是当你在和所有的stakeholder沟通时，可以给他们用线框图讲一个完整的故事，让他们对这个需求的场景加深理解，也让自己对这个需求是否应该存在做一个判断。（下图是我在产品设计过程中对产品框架的梳理）

（下图是我在做交互过程中对流程的梳理）

这里我给「百度脑图」做个广告吧，个人觉得还不错的Web脑图工具，简洁、云存储、一键整理，这对我来说就足够了。关于脑图、线框图的设计，有很多文章都探讨过，在这篇文章中我不再做过多的讨论，总之整理这些的目的是让所有利益相关者能更加清晰的理解你的意图，同时让产品的“性格”更加清晰明了。

| A PROTOTYPE IS WORTH A THOUSAND MEETINGS

雷迪森 and 乡亲们，重点来了，借用Paul Stamatiou（Twitter高级产品设计师）的一句话: A prototype is worth a thousand meetings. 我想把这句话拓展一下:

一个关键设计的可操作原型，可以节省非常多由认知偏误造成的沟通成本。

在读完Paul Stamatiou的这篇文章（Designing Twitter Video）之后，我决定在我们的产品设计过程中，尝试用可操作交互原型的方式来实践一把。于是我打开了Framer Studio的官网，下载了这个软件。

越强大的工具，使用成本自然会略高一些，这个跟投资一个道理，高风险，高回报。好在我自己之前有一些HTML/CSS/JavaScript的基础知识，所以上手还不算慢。就如Framer官方的宣传语说的一样，这个工具不会局限设计师的任何一个想法，只要你能想得到的idea，它都可以实现，这样一个直接用JavaScript来写交互原型的工具还有什么做不到的吗？Framer有它自己的开源库（framer.js），当中包含了各种动画曲线和一些组件，方便用户直接去使用。同时也开发了Mac/iOS/Android客户端，可以直接在你的手机上预览和操作你的原型，完全可以做到以假乱真，在验证设计的时候，我经常拿着假的原型，尝试让他们完成某些任务来验证可行性。

用代码直接来写原型，当然不会限制你的idea没错，但是毕竟coding一个原型出来还是很慢的，等你原型写好，产品周期过半了有木有。

我知道小明你一定有这样的疑问，不过Framer憋了两个大招，其一，它可以直接从Sketch或Photoshop导入你设计好的资源，你只需要设计好视觉稿并把图层分组，然后点一个按钮，Piu~它就跑进了Framer，接下来你要做的就只是添加一些事件、动画等等。其二，Framer并不是直接用JavaScript的语法来写代码，而是借用了CoffeeScript. 后者大大简化了JS的语法，让代码变得清晰易读，当然也就加快了coding的速度。如果你已经具备一些写代码的经验，把你的设计coding出来也许比你设计UI还要快！

不看广告，看疗效儿！

此神器一出，Facebook、Twitter、Google、Microsoft等一些大厂的设计团队纷纷表示：你牛逼，666~ 掌声、欢呼声响成了一片。

| 设计如何迭代

有些童鞋对「原型」的理解可能第一反应是线框图

不过我们在产品设计过程中，产出物也是随着执行一个设计流程：“理解、发散、筛选、原型、验证”逐渐迭代上去，所以我的「原型」从严格意义上讲，其实是包含：“手绘草稿、线框图、流程图和可操作原型”这几个部分的。

• Sprint Process

说到这个流程，有一个关键字叫「Sprint」，今年3月8号GV（Google Ventures）的三个设计师专门写了一本书详细阐述了一个初创公司做产品决策时，如何快速、理性、准确的把一个idea落地成一个产品。

我简要的翻译了三个设计师的背景：

Jake Knapp
Google Ventures “冲刺”流程的设计者，他有参与超过在100多个初创公司快速创业的经验，其中包括23andme、Slack、Nest、Foundation Medicine（如今已在科技与生物工程邻域成为顶尖公司）。Jake Knapp之前在Google工作，并领导团队运用“冲刺”流程设计和开发Google的几乎所有产品（从Gmail到Google X），他是目前全球少数顶尖设计师中的一员。

John Zeratsky
John Zeratsky设计过众多App、医学报告、新闻日报等等，在加入Google Ventures之前，他是YouTube的设计主管，并且是FeedBurner的早期员工，该公司后来在2007年被Google收购。John Zeratsky为华尔街日报、Fast Company（1995年诞生于美国的商业杂志，按月出刊，专注于提供科技、商业、设计相关文章）和连线杂志撰写设计与生产效率类的相关文章，John曾在威斯康星大学麦迪逊分校（美国最著名的公立研究型大学之一，学校有公立“常春藤”之称，是美国知名的十大联盟创始成员）学习新闻专业。

Braden Kowitz
Braden Kowitz在2009年创立了Google Ventures的设计团队，并且在风险投资公司开创和引入了“设计合伙人”角色这一理念，他为将近200个初创公司提供设计、人员雇佣、企业文化方面的建议和意见，在加入Google Ventures之前，他领导设计了诸多Google产品，包括Gmail、Google App for Business、Google Spreadsheets和谷歌趋势。

关于以上提到的一些初创公司背景：

23andme
是一个私人性质的帮助你了解你自己的基因组的生物工程科技公司，坐落于加利福尼亚州的Mountain View。公司的名字灵感（23andme）来源于正常成年男子细胞中有23对染色体。它直接面向个人客户，并提供基因组测试服务，2008年由美国时代杂志发表的一片文章“Best Invention of 2008”中提到。

Slack
2013年8月上线，是一个团队协作平台，可以让团队工作更加效率。由硅谷一些投资人和Google Venture投资，截止2015年3月共获得1.6亿美元融资，公司估值超过20亿美元。

Nest
一个专门设计智能家居设备和系统的创业公司，联合创始人有来自Apple的Tony Fadell等工程师，2014年1月Google用32亿美元获得了这家公司，截止到2015年11月，这家公司已有超过1100位员工。

Foundation Medicine
坐落于剑桥的美国公司，开发生产和销售为流行性癌症做染色体分析的诊断程序，公司的实验基于下一代染色体排序技术，2014年11至12月间，Roche公司宣布以7亿8千万美元的价格购买Foundation Medicine 56.3%的股票，同时还意向投入4亿美元在Foundation Medicine的运营和研发上。

对这本书感兴趣的童鞋可以买一本，目前应该只有英文版的。这本书并不像其他设计书籍总是说一些泛泛而谈的概念，Sprint从头至尾都关注「方法」，一切方法都是实践中试错总结而来，我只能说这是一本真正「接地气」的设计书籍。

• The First Version

有了功能列表，有了流程图，有了框架，有了线框，我们可以开始着手coding一个demo出来验证你的想法了，是不是很兴奋？我比较喜欢把一个idea亲手变成一个可以在手机上把玩两下的东西（下面是其中一个原型，来这里查看交互动画）。

一个以播放视频为主的工具，当然在播放视频时的体验是非常重要的，上面的demo用户场景是「不佩戴VR眼镜时，在线播放视频的过程中下载这个视频」，在我设计最初版本的时候，我设想点击「下载」按钮后，在「下载」icon右上角会出现一个「小红点」，以此来做为一个该视频已经开始下载的反馈，线框图出来以后，几个人开了一个5-10分钟的design critique，目的是收集一些feedback，不过当时包括我在内所有人都没有对这个小细节报有质疑，直到我把设计还原在手机上，让每个人尝试点两下时，发现这个设计的问题在于，点按时我的手指会完全挡住那个「小红点」，并且注意不到它出现的动画，因为太小了，所以测试下来这种反馈非常弱，而且不容易被注意到。所以解决方案和你看到的上面视频一样，当点按「下载」时，以toast的方式弹出提示用户，改进方案的时候，我测试了不同长度的文字和toast出现到消失的时间（0.8s、1.5s、2s）以检验我到底能不能够看清提示的文字，以及它不会一直停在那太久妨碍我看视频，反复测试几遍，最终确定了提示停留2s后消失。到目前为止这个小细节还算“good”但他并不“great”，Material Design在Motion这个环节中解释了为什么动画是交互中很关键的一个环节：

Why does motion matter?
Motion shows how an app is organized and what it can do.

Motion provides:

Guided focus between views Hints at what will happen if a user completes a gesture Hierarchical and spatial relationships between elements Distraction from what’s happening behind the scenes (like fetching content or loading the next view) Character, polish, and delight

因此，你会发现toast弹出到目标位置的时候，是会像弹簧一样跳动一下，而且很快，但收回的时候是慢一些淡出（ease-out）的，这就好像你刚收到拿快递的通知要飞奔过去，而拿到手拆开后就慢悠悠的晃回家了一样，这种体验会让用户觉得顺其自然，从而产生愉悦感。（下面是另一个原型）

上面这个场景是「我需要从网盘中下载某一个VR视频到我的APP中观看」，这个过程中有4种信息需要反馈给用户：

1. 开始下载
2. 正在下载
3. 下载完成
4. 下载失败

有一点遗憾的是，大部分网盘的接口并没有提供断点续传和下载过程监听这类功能，而基于开发周期时限问题，所以我们把这个需求置后了。因此你看不到上面demo中呈现出“下载过程”的信息。

这里我们遇到过一个问题，到底需不需要让用户重复下载已在本地的视频？我当时坚持认为不需要，原因是手机存储空间非常有限，但反驳我的童鞋们说，用户习惯可以存储重复的文件，他们在PC上也是这么干的。但在这里我们需要考虑的是，在怎样一种情况下，用户才会下载一个已经下载过的视频到手机上？如果有这样一个场景，但是出现的概率非常低，那么我们还需要权衡其他因素，比如存储空间。画一个矩阵图，把有利因素和不利因素全部填上，选一个尽量接近平衡的策略，然后要做的就是在实际使用中验证它。

当你看到上面的demo中，下载完成后，出现「对勾」的icon，随即又恢复到「下载」的icon，你就知道我们先尝试了第一种，允许用户下载重复的视频，因为这其中有一种情况是，用户可能会在网盘中修改文件名称，或者编辑过一个视频等等，这样一来要判断这个文件是否已经下载过，仅仅通过对比两者文件名显然不行不通，可能需要同时比对文件大小或者用其他方式解决，而这也尚需时间成本。

原型出来后，还是一样，自己先操作一下，然后拿给不同的人去操作一下，这里当你在让别人做测试之前，不要问类似“操作时我想让你看看有什么问题？”这样的问题，因为当你问出这句话时，其实就是在暗示对方，这里一定有什么问题，他会在接下来的过程中拼命找到一些看似有问题的“问题”。测试前只告诉对方任务是什么（比如：把这个视频下载下来）即可，并且不能向对方强调这是个测试，操作时要注意观察对方（比如他是否在某一刻停顿了一下？表现的有些困惑？）完成之后可以询问感受，提问时一定不要问引导性问题（比如：这个按钮放在这是不是看不到？），你可以问：下载过程中一切顺利吗？或者，是否在给定时间内完成了这个任务？等等。

再来看上面这个例子，我们的视觉设计师通过语言描述的方式，让RD的童鞋实现了一版「首页」与「设置」页面切换的交互动画，看到这个以后，其实我们是拒绝的，因为RD童鞋并没有准确的理解我们视觉设计师的意图，同时他们大多时间是在实现某个功能或者解BUG，对于交互动画并不会花太多精力。点击icon后，「首页」会掉下去，然后看到「设置」页面，但是向下滑动屏幕没有反馈，点击“返回”的方式不太符合这两个页面的上下关系，所以我们稍微改进了一下：

对比一下，你就会发现两者区别：增加了向下滑动屏幕的反馈，但并不是只要向下滑动就会切换页面，只有下拉到一定距离时才可以，目的是减少误操作带来的麻烦。首页下去之后停留的位置仍然露出了一个头可以“返回”，就好像你在操作现实中的抽屉一样。不过用户该怎样知道「首页」是可以下拉的呢？第一次进APP时用文字提示一下？NO！我非常不建议用“贴膏药”的方式把一些新手教程“贴”在界面上，除非迫不得已，用一些小动画暗示是最好的选择，所以当你点击「首页」的时候，它会向下跳动一小段距离来暗示用户这个页面是上下活动的。整个过程中，动画的时间、速度、滑动的距离坐标等都经过反复调整，最后选出一组合适的值，这些值可以直接告诉RD的童鞋们，方便他们100%的还原设计。

当我把这个改进版本和之前的版本拿给老板，让他对比操作一下后，他立马反馈后者更好一些。还是那句话：细节的堆砌决定体验的好坏。

总结：这些实战细节过程中，可操作原型的作用不言而喻，设计师可以在设计过程中不断试错、迭代，通过了解、调整非常多细节（提示时间、文字长短、动画曲线参数、实现原理、判断条件）从而找到一个最好的方案。好处是：产品可以在未开发或刚开发的阶段，就及时发现一些操作中产生的问题，而这些问题在线框图上并不会引起你的注意，从而减少开发过程中的反复修改，节省产品开发过程的时间周期。想想RD们也是人，昨天刚改好的一个需求，今天又得改回去，你逗我呢（掩嘴笑）？

部分关键交互或者说我想着重强调的地方，都会coding一个原型出来（来这里查看交互）：

| 100%还原-协助RD完成你的设计

设计评审通过了，项目要启动了，所有你设计过程中的文档、视频最好整理一下，统一命名，方便RD的童鞋查找。过程中我们会用类似「Tower」的团队协作工具，统一管理需求更改、设计走查。

这个时候，我基本天天追着RD童鞋，把设计中的所有数据对接给他们，比如上文说到的一些交互参数。最大的问题是，demo用JS实现，但iOS用object-c，安卓用Java，所以我不能只给参数，还要找到专门的可用于移动平台的motion library，好在Facebook、Google这些个大厂有开源的动画库可以直接用的，帮开发找好链接发给他们，让他们帮我还原设计。

产品开发过程中，总是去打扰RD也不好，所有你发现的与设计相关的问题，最好统一通知他们。尽量满足RD童鞋提出的一些要求，比如“不要把一些要拷贝的参数做成PNG发给我啊，不然我还得一个个敲字上去”之类的，当然，无理要求必须要打回去（奸笑）。产品前期设计的好坏，直接决定开发过程中反复修改的次数，当然肯定就会影响产品开发的周期和程序稳定性。借用Paul文章中那句话送给各位：

The details are not the details. They make the design.

| 题外话

如果这篇文章对你有一些帮助，不要吝啬你的「赞」。 如果你有一些想法或者问题，就在下面留言给我。 欢迎订阅我的博客，因为我会定期更新它。

我平时也会拍拍照，有INS的朋友们欢迎找我互粉。

扫描下面的二维码添加我的微信，另外我建了一个Framer的交流群，喜欢JS、喜欢设计、喜欢摄影的朋友们，我们等你加入！