用户体验设计答疑对话

产品经理

[前言]:搭往公司的班车,遇到其他部门的同事,他问了很多关于我的工作的问题,由此引发这篇文章。这些问题,我也经常被其他人问到,其中既有我们亲密合作的伙伴——如产品经理、开发工程师(程序员),也有对于产品决策有绝对发言权的老板,也有平时和我们工作交集不多,但是却是一个成功的产品生态链上重要的一环的角色,例如来自客服部门和销售部门的同事。所以做些加工,整理成文,希望有助于大家了解用户体验设计部(简称 UED)在网站开发流程中的角色和作用,从而有助于不同部门的协作和配合。

产品经理

Tom:请问你是什么部门的?

Heidi:我是国际站用户体验设计部的,就是UED,听说过吗?

Tom:哦,了解,是不是我们网站布局都是你们来改的?

Heidi:应该是的。

Tom:我是负责客户培训的,我想问一个问题,你们为什么要经常改我们的网站啊?我给客户培训,经常打开网站,就发现布局换了,我的讲义也需要经常更新。

Heidi:这……改动总是有改动的理由的嘛(笑)。也许是要提高转化率,也许是为了新的产品上线做拓展,也许是用户的需求更明确了……其实首页来讲的话,平均2年也需要大翻新一下的,老是同一张面孔,多枯燥啊。不过我们每次大的改动,都会通知到可能会受影响到部门的,比如销售、客服等,都有相关的邮件抄送给接口人。我回去确认一下你们部门是不是也在抄送名单里。

Tom:恩,谢谢了。对了,做你们的工作的,专业背景都是什么啊?都是学计算机的吗?

Heidi:不是。其实我们部门分四种角色,每种角色的专业背景是不一样的。

Tom:都是什么?

Heidi:比如,用户研究员,专业背景可能是心理学,人类学,社科等学科——但是也有其他专业背景。交互设计师专业背景可能是工业设计,也可能是其他设计专业,比如平面设计——但是也有完全和设计不沾边的专业,比如心理学也有。前端工程师的专业背景可能是计算机,也可能是其他专业,比如我们团队曾经有从演艺圈出来的杰出前端。还有一个角色是视觉设计师,专业背景有可能是平面设计,也有可能是动画设计。啥专业都有可能,不能笼统去讲……

Tom:你刚才说,有可能是学工业设计的,我觉得很奇怪啊,工业设计我想的不是都一些现实的产品吗,比如汽车,洗衣机等……

Heidi:毕竟国内专门的交互设计专业很少,专业的也不多,还是会借鉴很多来自成熟的工业设计领域的一些理论。工业设计可能本身发展比较成熟,而且研究的方向也是人机交互类的,也需要研究用户的特点,行为和习惯,进而设计或者改进产品设计,让它简单易用。所以,和交互设计是有很多相同的部分。我个人感觉交互设计是从工业设计领域衍生出来的,而且并不局限于网站和软件界面……可能在不同的领域有不同的叫法吧。

Tom:那其实,网站、软件和洗衣机设计是同一个道理,只不过是虚拟的和实体的……

Heidi:也许可以这么理解。

Tom:做一个网站很难吗?你们为何需要这么多人?不是就给程序员一个图,写些代码就可以了?

Heidi:……恩,单纯做网站是挺简单的。做好,不容易。做个房地产宣传的网站,挺容易的,做个小企业的形象网站,也挺容易的。做好支付宝网站,不容易,做好阿里巴巴网站和淘宝网站,不容易。网站这个概念也不能笼统去讲。越是要用户去使用的网站,设计难度就越高。而且,也并非一个ued的团队在“做”网站,我们几百个人的工作都聚焦在这个网站上。有做产品规划的,有做运营的,有做客户支持的,也有做海外推广的,有做数据分析的——只是大部分的人的工作,需要最终流转到我们手里得以分析、实施。(Heidi注:做网站看起来简单是因为对于其他人来讲,只能看到20%的工作,但是这个20%是靠那些看不到80%决定的,参见图1。)

产品经理

图1.网站用户体验层次:用户看到的是简单的20%

关于此图的更多说明:此图参考的原图,请点击查看。我原本是想把这张图做得更加形象一些,想到了冰山模型。后来发现用植物更加能够说明问题,战略即是那棵种子,如果种子不好,再多的肥料都无济于事。而土壤和水代表了做出成功的产品必需的资源(团队、时间、资金),植物的根部是一套协作系统,代表了不同的部门做的不同的事情,比如产品团队、用户体验设计团队、开发和测试团队等。而土壤里也会有害虫来危害产品,这正意味着产品开发中也会遇到种种的风险。于是……就产生了上面的图。

Tom:那你们UED平时都是怎么工作的?

Heidi:做新的产品和优化老的产品的流程不太一样。如果是新的产品规划,很早之前就开展了工作了,交互设计师,用户研究员配合产品经理(此阶段,大部分是以产品经理为主导)做一些目标人群的调研,分析,看我们的产品针对的目标人群都是谁,他们都有什么需求,都有什么特点。这样才能够帮我们找到产品的真正定位,确定核心的功能以及功能的优先级等。

Tom:有点像目标市场划分?

Heidi:确实是有营销的分支在其中。其实卖产品要想事半功倍,一定要先有需求才有产品。而不是先生产出产品,再去市场上找能够卖给谁。

Tom:那你们什么时候开始设计呢?

Heidi:刚才说我们前期要投入一些人力去做分析和调研,接下来,在产品经理去细化需要什么功能时,我们就可以开始设计工作了。(交互设计师有可能和产品经理同步开展工作,共同得到产品功能需求文档,也有可能由产品经理先进行需求文档工作后再开始交互设计)但是不像你刚才说的,直接去出一张图。而是先由我们这个角色,也就是交互设计师去做一些线框图。

Tom:线框图,就是草图对吗?

Heidi: 你可以理解成草图。就好像大楼要施工之前,也需要有一个蓝图一样。先得把蓝图确认了才能开工。

Tom: 这个我理解。做草图是和别人去讨论是吧?视觉设计师设计不也是要出很多稿草图吗?

Heidi:我们设计的草图和视觉设计师做的不一样。我们是在他开工之前更早的一环。但是你说得没错,我们确实可以不出这个草图,而直接让视觉设计师去做。但是这个视觉设计师会非常非常痛苦。因为他需要花很多精力在草图上,然后他接受很多意见和建议,而且他去优化的方向无从把握,很多,结果导致迟迟确认不了。

Tom:为什么会这样?

Heidi:视觉嘛,每个人都有自己的感受,视觉的评价标准是大部分建立在主观评价上的。你觉得紫色好看,老板觉得红色大方,视觉设计师需要找到一个契合点去让所有决策方达成共识。

Tom:这本来就应该这样,即使有你们,他们的痛苦也不会减少多少吧?

Heidi:的确。但是我们的存在会帮助视觉设计师减少大部分痛苦(当然我们存在的价值不限于此)。因为我们会缩小他们确认的内容范围。如果没有交互设计的存在,就会把所有的可能性都抛给视觉设计师。在视觉确认时,会发现布局a和布局b,布局c存在各种偏好,而颜色a,颜色b, 颜色c 也存在不同的偏好,版块a的位置,存在不同的偏好……结果布局、颜色、结构的排列组合会非常非常多……( Heidi注:如图2所示,视觉设计师的大部分痛苦来源于对各种意见无法控制,从而有效达成决策)

产品经理

Tom:恩,我理解了,会不会有人说:我觉得这个版本的结构很清晰,但是颜色很不好看,你看看能不能把另一个版本的颜色换过来看看?

Heidi:经常!但是这样来回排列组合,会诞生出更多的排列组合……

Tom:恩,想法有时在设计的时候也会收不住,也会诞生出一些自己的新的想法。

Heidi:是的。所以我们通常会在交互设计阶段先从理性上确认一些问题,比如布局,信息结构,内容的逻辑性等。这些内容可以不那么感性去评价,更多是靠一些说服性的东西去说服大家接受。

Tom:那你们怎么说服别人接受?

Heidi:如果有数据,就用数据;如果有用户的生意就用用户的声音。如果有已经了解到用户的特点、行为,都可以拿来应用到设计方案的说服框架里。另外,大家都会尊重专业的观点。另外,知识就是力量,专业让人信任,把自己武装得更加专业一些,会有比较大的帮助。

Tom:就是一样要说服别人?

Heidi:其实有时也不能叫说服,我们最起码自己得相信那就是最好的解决方案,如果自己不确信,就让更多的人去帮你看看是不是有更好的解决方案,如果时间和资源允许,就引入真正的用户去帮我们看看。之后别人都会相信这是目前阶段最好的解决方案。但是,即使交互不像视觉那么感性主观,但是依然每个人都有自己的想法,我们就需要说服他们相信这是最好的解决方案。

Tom:所以还是要找一些支持。

Heidi:数据,用户声音,都很有帮助。实在没有资源,就需要我们去描述使用场景,让其他人觉得自己就是现实的用户,进入到我们描述的使用场景里去,我们把这个说服的方式叫做讲故事( Heidi注:图3,讲故事已经成为一种业界的术语,storytelling)。[br]产品经理

图3:讲故事是将用户使用场景具体化形象化的方式,成为交互设计师说服框架里重要的一种技能。

Tom:&8221;讲故事&8221;很有意思!那是不是你们就提供一张页面的草图给视觉设计师就可以了?

Heidi:不但是单个页面的草图结构和布局。我们最主要的是设计任务流。

Tom:任务流?

Heidi:比如用户的目标是上传产品,为了达到这个目标,他需要经过几个步骤,完成哪些任务等。我们要做到尽可能让用户在最短的时间内通过最少的步骤达到目标。哦,其实,我们的目标不只是这个,更高级的是,用户在这个过程中感觉到简单,容易,放松。最有效率有时需要和“用户的感受”平衡,也需要和我们投入的成本和用户投入的成本相平衡。

Tom:看起来又比较复杂。

Heidi:其实很简单,打个比方,你在一栋停了电的大楼里,有15层楼高,你需要下楼。最快的方式就是吊个绳滑下来,最舒适的方式是叫个直升机来接你。但是前者虽然效率高但是不安全,你会担心不敢尝试。后者虽然舒适但是成本太高……

Tom: 所以,从楼梯上慢慢走下来,也许才是最好的。

Heidi: 恩,从楼梯上慢慢走下来,对比其他两者,才是最合适的解决方案。我们平时选取设计方案也会有多个维度的(图4)。

产品经理

图4:好的设计方案应该能够满足多个维度的评审标准

Tom:我了解了。但是你刚才说收集用户需求,你们都是通过什么渠道?其实我们是负责客户培训的,才是每天面对客户的人。

Heidi:客户和用户还不是一个概念。你们培训接触的客户是其中一类用户,也就是国内的供应商,对于他们的需求收集,我们有时也会“上山下乡”,直接派一些设计师去他们的工作地点去观察他们如何用我们网站。当然,我们也通过内部渠道,比如来自销售、客服部门反馈过来。另外,我们也可以很方便邀请他们过来我们公司,中国站有专门的实验室,可以让他们在实验室里做一些可用性测试。但是另外一部分用户是海外的买家和供应商。他们离我们很远,他们不容易过来,我们也不能过去。这些用户是我们网站的买家,服务好买家,才能够让卖家受益,所以他们的需求非常重要。

Tom:那你们怎么办呢?

Heidi:只能尽可能挖掘渠道。每年的广交会,国外的买家会来不少,我们也会去广交会参加用户调研。平时有专门的团队,BI部门(网站参谋部)会定期做一些海外买家的问卷调研,并逐渐沉淀出一些买家分层研究,我们可以通过他们知道很多买家的需求和问题。另外,我们自己也会偶尔做一些远程的在线的用户调研和测试。

Tom:但是我们网站不会经常推出新的产品,你们平时闲着吗?

Heidi:(汗)………我们也想啊……但是事实上是我们每天都很忙,而且还在不断招新的人。大的战略级的产品非常不会经常推出,但是小的产品会经常出现。但是一些老产品的优化是不断在进行的——打个比方,刚发布时,注册表单的转化率是50%,之后的优化目标就是将这个转化率提升到70%,目标在不断提高,就需要有后续的行动。

Tom:不能一开始就做的很好,以后就不会经常需要优化了吗?

Heidi:也许快速迭代就是互联网产品的明显特征吧。刚开始大家就是想把产品做到线上去,这时也许本来就解决最核心的功能,和主要的流程没有问题。我们也无法一开始就做到尽善尽美,一个原因就是资源不允许。另外有可能是,我们确实不清楚到底完美的方案是什么,那些耗费大量资源的功能到底有多少用户需要,所以我们有时就会先发布一个简单版本,之后随着用户使用的数据和访谈的声音,去迭代优化。另外,我们对于在线的页面、功能都有数据监测,会分析流程中的流失率,我们去判断可以优化的点是什么,然后去改,再监测。

Tom:但是依然没有百分之百满意的时候。

Heidi:每次优化要保证数据是正向的。不是正向的就返回老的版本,继续思考。但是确实不可能说什么是永远不用再优化的。网站的体验就是一点点被优化升级的啊。

Tom:我明白了,谢谢。我之前理解做网站太简单了,想不到这么复杂。

Heidi: 哈哈,我们也常说,我们不纠结,用户就纠结。简单是复杂的结果,复杂是简单的必备过程。

[总结]:在用户的视角来看,我们也希望他看到的都是最简单最愉悦的一面。作为客户培训师,你不需要知道产品数据在我们后台是存储在什么服务器的。用户搜索产品时,也更加不需要了解一个检索词是经过了多少词解析判断计算,跑了几台服务器,最终把结果呈现给他的。但是作为工作人员,我们得了解需要怎么做,才能够把最简单最愉悦的结果呈现出来。(Heidi注:如图5所示)

产品经理

图5:简明网站产品建设流程图

这个图呈现的流程,依赖于多个部门的通力合作。从战略层高瞻远瞩的判断、从产品经理对于市场的分析以及功能、内容的规划、描述,到用户体验团队,开发和测试团队的全力配合,而网站产生后,还要依赖于SEO、市场营销、销售和客服的工作。

成功的网站,一定是多个部门一起围绕相同目标运作的结果,但是其中一个环节失败,则可能会造成全盘皆输。

本文虽然篇幅已经很长,但是涉及到具体的流程、方法,都只能简单带过,希望大家要记住这是对话的场景,不要以偏概全哦。[br]你对他提出的问题,想如何回答呢?如果你有问题,质疑,鼓励……欢迎交流。

原文地址:http://heidixie.blog.sohu.com/160442979.html

关键字:AliUED, 交互设计, 用户研究, 知识分享

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部