【硅谷设计师周报】体验设计实习小记




作者:Hoka(微信公众号:UXminion)

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

作为一个类似agency的team,我们的工作方式和公司里其他的设计团队有所不同。我们的项目周期不长,通常只有几周,而不是像其他team一个项目可以做1-2年,那几周里,几名设计师会一起扑在一个项目上,非常intense;同时我们非常重视研究,因为面向客户,要了解客户的需求,所以设计师也会参与到研究中。

我现在在做一个关于公司内部盈利预算的项目。这个项目对我非常有挑战性,因为我没有任何关于财务的背景知识(大学里唯一一门相关的家庭理财课还是个人史上最低分),而这个主题所牵涉的专业术语和利益方又特别多,而且大家还喜欢用缩写;但同时我也很喜欢这个项目,因为我能和两个非常棒的UX设计师合作,学习他们的设计流程和思路,以及和PM、和利益方沟通(卖设计)的能力。而且每天都能被智商碾压让我很开心,因为我相信UXer的使命就是解决复杂的问题。

现在项目进行了一个半月,我和另外两个设计师每天在workspace里一起工作。我们的workspace是一个开放式的会议室,墙上贴满了我们写的访谈笔记、屏幕截图、涂鸦和各种灵感。这样做最大的好处就是一抬头就能看到各种素材,不用在电脑里翻来翻去,唯一不好的就是不够环保……目前我们完成了用户研究和一部分的线框图(Wireframe),用到的设计方法和学校教的略有不同,所以我决定写一篇文章记录一下研究过程和反思。

访谈

因为对主题毫无概念,我们研究的第一步是访谈。其实在访谈之前,PM还给我们每人上了3小时的盈利预算101,有种回本科上通识课的感觉……然而作为UX设计师,我们还是想跟用户聊聊天。访谈开始前,我们通过PM给每个受访者发了三四页的pre-interview workbook,请每个人抽10-20分钟填写。除了基本的人口学信息之外,workbook中有一些我很喜欢的问题:

  • “你典型的一天是怎样的?主要的工作内容是什么,用到哪些工具、和哪些人交流?”
  • “你现在的时间分配是怎样的?理想中的时间分配是怎样的?”
  • “你工作中最开心的一天是怎样的?最不开心的一天是怎样的?”
  • “如果有新员工入职,你会给ta什么建议?”

访谈开始前,我们会浏览一遍受访者的回答,看看有哪些点可以深入挖掘,酌情修改一下访谈的重点。访谈中有两个问题我以前很少问,但通过这次访谈发现可以带来一些洞见:

  • 你如何定义工作上的/某件事的成功?(我以前不问这个问题,因为觉得太泛,可能有点难以回答,但在企业软件的情境下,确保用户能够通过我们的设计,更好地完成他们的KPI,是我们最重要的目标之一。)
  • 在整个工作过程中,如果只能改变一件事,你希望是什么?(我之前不喜欢这个问题,因为觉得与设计过于直接相关,对方的回答可能会限制设计师的想法;但其实大家都回答得比较抽象,所以不会太影响设计思路,而且这个问题对于说服PM很有用。)

访谈总结

每次访谈过后,我们都会花5-10分钟快速总结有意思的发现,聊一下感受和重点。之后,我们做了简易版亲和图(Affinity Wall),大家一起写便利贴,将它们分类,访谈和总结的时间大约是1:2。值得一提的是我们打印了很多受访者展示的软件、报表截图,这对之后将设计落地很有帮助。

流程图(Flow Model)

其实之前我们并没有计划做流程图,但是因为问题比较复杂,涉及到的人和系统比较多,所以访谈结束后,我们自然地就画了流程图来帮助自己理解整个过程。第一次画出来的流程图会很凌乱,但是在这个时间点,最重要的是记录所有的知识,整理可以不必着急。 流程图最大的帮助是确保所有人都理解过程(这对于画体验历程图很有帮助),开始寻找集中交汇点和断点

人物角色(Persona)

做人物角色是因为我们访谈了这么多人,每个人面对的问题和解决的方法不尽相同,同样的职位可能面对不同的问题,但不同的职位又可能面对相同的问题, 所以不能简单地用职位去划分用户 ,我们需要建立一个虚拟的角色来整合用户类型,确保我们设计时想的是同一个人。人物角色大多大同小异,值得一提的是我们把人物角色的目标分为两类:商业目标和个人目标。商业目标可以是完成某个KPI,而个人目标则可以是“减少花在盈利预算上的事件,积累更多与人交流的经验,争取职场晋升”等。我非常喜欢个人目标这个版块,能让我们对persona有更多的同理心,更了解他们行为的动机。

体验流程图(Experience Journey Map)

做完访谈分析和人物角色,我们一起画了体验历程图。我们做体验历程图是因为每个受访者都在工作中积累了一套自己的流程,而且大部分受访者不会按时间线给我们梳理他们的过程(虽然有个别受访者讲话特别有条理,但大部分人都是想到什么说什么),所以我们要自己总结受访者做的每个步骤,寻找其中的共同点。
在体验历程图里包括步骤(Step)、行为节点(Touchpoint)和情绪(Emotion)。步骤其实就是把flow model做成时间线的形式。行为节点在我理解中就是更详细的步骤,标出每个步骤具体的完成方法、涉及的人和系统。这一步非常考验对访谈的理解和笔记的详细度,有时候我们不得不重新听录音来补全之前遗漏的点。情绪是个很tricky的环节,因为我们访谈的内容是受访者的日常工作,他们对这些工作早已习以为常,所以很少直接提到情绪(比如“这个系统烂爆了”之类设计师都很喜欢听到的话), 但是很多时候可以从他们的行为中识别出情绪 (比如想方设法避免使用某个系统),所以要靠我们的同理心,用心感受每个行为背后的意义,以及每个步骤对受访者的目标的意义。

这个网站有Adaptive Path提供的体验流程图指导:

HMW(How might we…?)

之前的研究和总结都是为了设计。HMW是研究和设计的过渡、中间步骤,是“How might we”的缩写。基于之前的研究,对于重复出现的痛点,我们用问句的形式,来思考用户在哪些地方需要什么帮助,作为设计的起点。

做HMW要注意的是:

  • 每个HMW并不太局限(narrow),也不太宽泛(broad)
  • 每个HMW的粒度(granularity)相似
  • 每个HMW只涉及到一个点

斯坦福设计学院的网站上有一篇不错的短文讲解了HMW的具体做法:

2*2

我们最终生成了18个HMW,为了挑选出最重要、最亟待解决的HMW,我们设计了一个2*2的象限图来将HMW分类。我们考虑的维度有:

  • 这个HMW是可以用科技手段解决的,还是是要通过改变流程(很大程度上是改变人)来解决?
  • 这个HMW对商业的影响有多大?
  • 最后我们还加了一个分类:“这个HMW对用户的个人影响有多大?”

然后选出完全可以用科技手段解决的、对公司和个人影响最大的几个HMW,作为接下来的设计重点。至此研究过程就差不多完结了,终于可以开始ideation!

做完整个研究流程,我最大的感想是些 设计方法很大程度上是沟通的方法 ,用来确保每个人(不只是设计师,还有利益方)都理解了用户和他们所面临的挑战。对于企业盈利预算这样的复杂问题,这些设计方法和沟通是很有必要的。

 

创意阶段(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非常有用,可以减少不必要的争论。

 

最后

Hoka在SAP的6个月实习结束了,我很感恩有这样的经历。在类似agency的team的好处就是学到了将研究和设计结合的方法。作为researcher-turned-designer,总觉得「灵感」、「创意」之类的词离自己很遥远,但按照流程做下来,觉得设计有法可依,也没有那么可怕了。

还有就是重新思考了研究和设计的关系,以前因为两者分属两个职位,我总觉得一定要做出选择,但在这样的team,我懂得了研究就是设计的一部分,与岗位无关,只要team重视,自己也重视用户的感受,就有机会做研究。也因此,我更了解自己,知道了我在设计师的岗位中,想做什么,想获得什么。

如果你常看我们的「硅谷设计师周报」的话,就会发现我提到的很多东西都来自周报。所以我还想再次感谢挠挠,带我一起做周报,我确实学到了很多设计师的思考方式,越来越像一个设计师了。小伙伴们如果有喜欢的文章,也欢迎在后台和我们留言分享~~

发表评论

电子邮件地址不会被公开。 必填项已用*标注