硅谷用户体验设计师的工作实习周报分享

老梦の / 2016年2月24日

设计资讯 2231 10 1

我是Hoka，之前在SAP Palo Alto一个提供设计咨询的组做实习生。我们组不仅给其他公司做设计，也带领客户做设计思维的workshop，帮助客户在公司内部推广设计思维，还有一些给SAP内部做设计的项目。

在实习期中，我的主要项目是和两个设计师一起合作公司内部盈利预算的dashboard。因为对这一主题了解不多，我们集中进行了访谈，邀请负责盈利预算的同事向我们讲解盈利预算中涉及的人、事、物和各种KPI。访谈过后，我们绘制了流程图、人物角色、体验流程图作为总结，并提出了10多个HMW（How Might We）作为设计的重点（具体研究过程请回复04查看上半部分）。

创意阶段（Ideation）

根据研究结果，我们提出的HMW有「如何帮助用户更好地监控最重要的KPI？」、「如何让财务预算的流程更透明？」等。为了回答这些问题，我们一起进行了两轮Ideation。每个人先将自己想到的解决方案写在便利贴上，再互相分享，讲清楚每个解决方案是针对什么问题，给用户带来怎样的好处，并贴在对应的HMW下。需要注意的是，这里每条便利贴最好只涉及一个解决方案，方便归类，也更容易讲清楚、说服别人。理论上在这个阶段，解决方案应该是比较high level的，也就是产品层面的、功能上的方案，但有时候我们也会忍不住给出一些细致到UI的方案。我的一个组员就像是灵感永动机，思路很活，有很多想法，实用又新颖。除了他能够讲清楚每个创意的优缺点，听起来很有道理之外，我也想知道他平时是怎么积累这些灵感的，所以就观察了一下：

首先是观察、思考其他软件、应用的特点。有些灵感可能来自看似毫无关系的地方。比如我们有一个页面参考了Facebook的activity log（记录用户在脸书上的一切活动的页面），以此衍伸，想到可以做一个盈利预算团队的activity log，让每个人都可以看到别人做了什么，这就解答了「如何让财务预算的流程更透明？」的问题。

其次是总结新的趋势。网上有不少类似「2016最新网页设计趋势」之类的文章，虽然内容大同小异，但当我们把这些模式合理运用于自己的设计，还是可以让人耳目一新。看这类总结时，要细想这些模式成为趋势的原因，以及如何在自己的项目中加以运用。我们组内也会有相关主题的分享。也可以浏览Pinterest、Dribbble和Behance之类的设计呈现网站，看看有什么新颖的dashboard概念。

最后就是经验啦，面向企业的dashboard虽然主题各有不同，但解决的问题却很相近，有一些常见的解决方案，改动后可以套用在新的设计中。

故事板（Storyboard）

创意阶段结束后，我们画了故事版，来想象、描绘我们即将设计的新系统可以如何帮助到用户。故事板帮助我们把之前的灵感整合起来，想象它们如何在现实生活中帮助用户更好地完成目标。它也是我们之后设计的重要参考，我们在描绘设计板时会设想用户如何接触到新的系统，系统里大致有哪些核心功能。作为研究阶段的最后成果，我们也会借助故事板，与用户验证板上的想法，确定我们抓住了核心问题。我们也用它跟技术组介绍我们的想法，及早确定技术上的限制。我个人觉得故事板也是我们给PM和stakeholder画大饼的工具……

绘制故事板时，我们参考了Hero’s Journey的模板，Hero’s Journey是美国神话学家Joseph Campbell总结的叙事手法，他将英雄神话故事模式分解为12小阶段，大意就是一个普通人离开日常生活，展开探险，碰到小挫折，遇到老师解救，遭遇敌人，经历试炼和挫折，重生，再次回到日常生活（想想魔戒、哈利波特之类的都可以搭进去呢）。我们没有（也做不到）完全参照这套模板，只是在大画布上画了一条大致的情绪曲线，由中到低再到高，代表了一个英雄（用户）从平常生活（我们的设计出现之前）中遇到问题纠结痛苦（于是使用了我们的设计）最后克服困难涅槃重生的过程，按照这条情绪曲线，往画布上加入分镜和描述。画分镜的过程也促使我们去思考了更多界面里的元素。画完故事板，我们筛选出创意阶段最重要的想法，将它们一一对应到故事板的分镜，理清出现的位置，确保草图中有它们的位置。

有了故事板，设计开始有了眉目，我们也就开始跟技术组聊可行性了。技术组远在欧洲，给合作带来了难度，所以技术讨论一度终止了两个月，直到我们万能的PM找到了坐在我们楼下的技术代表，瞬间项目进度就加快了，所以位置很重要，我很羡慕那些可以拉着小板凳坐在Dev旁边看他们改代码的同学们……

低保真草图（Low-Fi Sketch）

完成了故事板，我们终于可以开始做「real design」啦！我们从系统首页下手，根据研究，决定了要在首页中放入哪些KPI，每个人都试着画下自己的想法，交流后，大家取长补短（功能，UI元素，排版等各方面），再各自画一轮，交流过后，确定了一个（暂时的）最终版本。后面几页的绘制过程也是如此，只是做dashboard会遇到数据可视化pattern复用的情况，所以要尽早想好一个通用的解决方案。

在画草图的同时，我们还画了screen flow，讨论了系统里需要有哪些页面，每个页面有哪些元素，考虑了页面导航是否合理。如果可以重来，我可能会尝试最近很火的原子设计模式（Atomic Design，回复c4查看周报相关内容「面向对象的用户体验设计」），先确定有哪些可视化图形，再考虑它们在不同页面的分布，而不是先考虑有哪些页面，再一一设计可视化图形，也许能更好地处理pattern复用的情况。

原型（Prototyping）

画完草图，我们做了原型，以便收集用户反馈。原型并不复杂，就是十几个页面的click-through，我们测试原型的主要目的是了解我们选择的KPI是否有意义，呈现方式是否合适，有没有漏掉信息，架构能不能看懂。我们起初用公司内部的原型工具，因为当时将近季末，大部分用户很忙，很难约到电话会议，而这个工具有点像InVision，用户可以在原型的任何地方留言，我们只要用文字介绍每个画面的功能和元素，并留下问题，就可以坐等用户反馈。过了忙碌季，我们改回视频电话测试，并使用Flinto做原型。测试的战线很长，以至于我们后来直接测试了mid-fi，也算是迭代吧。Sketch和Flinto配合很方便，可以直接将Sketch画板复制粘贴到Flinto，替换旧画板。不过Flinto不支持IE，而做盈利预算的同事好多还在用IE，测试又都是远程的，这也给测试带来了麻烦。

电话里我们准备了很多问题，小到一个按钮，大到整个系统的导航。一个很重要的研究问题是：对于高层用户（地区经理以上），他们想看的是整合后的数据，所以我们会综合他们管理的员工的所有项目，做数据可视化；但对于「一线工作者」（收集数据的项目经理），他们手头只有2-5个项目，我们是否还应该呈现整合后的数据？还是直接呈现每个项目的数据？为此我们做了两个版本，并额外了解了他们每个人掌管多少项目、每个项目最关键的KPI有几个、以及是否需要手动整合信息来报告给高层用户，最后决定按项目呈现数据，不进行汇总。

测试中，我们发现公司高层和「一线工作者」用的词汇差别很大，为了统一词汇，我们画了词汇的思维导图，并要求用户一个一个阐释概念。之前PM就提醒过，我们的设计是公司变革管理（Change Management）的一部分，在这里感受特别明显。我们需要在设计中使用统一的词汇，改变用户对这些词汇的理解，并且强调某些KPI，以获得大家对这些KPI的重视，虽然有些KPI根本没有用户提起过。这也让我对设计的力量有了新的认识。

在跟用户的交流中，我学到的是不要试图用设计来解决所有的问题。每个用户的差异太大，有些人会想要很细节的东西，嗓门又大，带跑我们，这时候就要和PM确认项目的核心内容，必要的话push back。所以虽然我很想跟用户承诺「好的我一定会把你的想法融入设计的」，但话到嘴边还是只能说「你的反馈很有价值，我们会考虑的」，所谓under promise over deliver（回复c9查看周报相关内容「如何做好设计团队的带头喵」），虽然不喜欢，但的确是让大家过得更开心的办法。

还有就是要跟PM保持很紧密的关系，他是替我们扫除路障的人，也是项目最大的backer。答应他的事一定要完成，要经常给他汇报让他放心。有突发事件会影响进度也要讲清楚。不想做的事情也要做好，但是也要给自己留有余地。

要有ownership，跟有ownership的人一起合作，会互相激励，带来彼此最好的一面。

高保真画面（Hi-Fi Mockup）

测试迭代后，我们将最终设计做成高保真画面。因为设计中有表格，我们就用Sketch的Content Generator插件，简单改一下参数，就可以获得自己想要的随机数范围啦，批量生成随机数，再也不用编数字到头疼啦。做数据可视化，颜色也是让人头疼的事情，我们参考了Samathan Zhang的文章，调整了我们使用的颜色（回复c8查看周报相关内容「给你的数据可视化加点颜色」），其中提到的Color Oracle工具，对于测试accessability非常有用，可以减少不必要的争论。