由于性格和习惯,我在工作中时常处于内敛闭塞的状态。但作为专职交互设计师,除了完善功能细节和发挥创意外,整合各方资源、监测用户体验风险、提升团队的用户意识,是同样重要的工作职责,而这些均需要在项目开发中和其他岗位一起推进。如何克服思维局限、避免怠惰心理、充分调动内部资源,做到项目结束不留遗憾,一直是困扰我的问题。也一直在思考一种简单易行的方法论,能通过外在规范来约束和督促自己。于是便有了被我称为「四三二一」的交互设计流程管理工具。

四、三、二、一分别对应了产品开发流程中的需求、设计、开发、总结四个阶段中应该采取的行动步骤,由前期到后期,由策划到执行,均需要对应岗位的合作。从数字上可以看出,越是早期,应该要求越高、越多,以防止后期的偏差疏漏。下面从「四」开始说起。

「四」是who、why、when、where

「四」分别指who、why、when、where,这是需要和产品经理共同阐明的四个问题。

 1. who,功能的用户群是谁

也许有人会说,产品的用户群不应在迭代中确认,而是产品最初应该定义好的,比如30~40岁之间的城市白领。这里要谈的其实是更加细分、明确的身份特征。比如产品经理想要添加一个笔记功能,那么我们就需要提前想到,什么人喜欢在听音频时记笔记,他有没有在其他地方记过笔记,喜欢什么笔记平台,习惯如何管理笔记等。竞品分析和跨界分析,此时就可以介入了。

2. why,为什么要做这个功能

用户的需求是多种多样甚至无穷无尽的,为什么我们要在当前时间迭代添加这个功能,功能的提出者是谁,验收标准是什么,有没有后续动作。一般情况下,需求提出者是产品经理本人;另一种是运营/内容提给产品经理/设计师的需求,比如要做专题活动或独立的内容模块。后者尤其需要注意,要直接找需求提出者而非转述者讨论功能细节和实现效果。why 和who 一起,共同确定了功能的「范围」层面,整体上把控住不要违背公司的「战略」即可继续执行。

3. when,功能使用场景有哪些

如果要增加搜人功能,放在搜内容后边,那可能就存在一些情况,用户希望首先出来的是人而不是内容。要做下载功能,一种是按照正常的查找对象、逐个或批量下载、等待下载完毕后收听;另一种是情况紧急,马上要出门了,需要地方把我可能想听的东西一键下载,越快越好。还有一些内部场景,如微信绑定,除了常规位置,也可以放在用户导入头像的时候。如昵称修改,除了常规位置,也可以放在需要临时隐藏身份的时候(直播间里)。场景切换可以给交互设计师带来无限的想象力和可能性,也是创意爆发,达到惊喜效果的一个突破点。

4. where,信息结构,即功能的位置和联系

界面和流程设计是交互设计的基本功,也是我们日常的核心工作。如VIP功能下,到期时间应出现在购买前、购买中、购买后的哪些地方;如工具栏上哪些功能需要放出,哪些需要收起。设计依据一般是功能的重要性、紧急性、使用次数、使用频率、界面分区等。

在和产品经理讨论执行的时候,有没有什么容易上手的理论工具可以使用呢?顺此延展一下,根据功能的工具属性和内容属性,我从衡量指标、体验要求、设计结构三个层面对二者进行了对比划分:

需要解释的是,「内容属性」和「工具属性」二者看上去处处相对,甚至有种相反的感觉,但其实二者在单个产品内更多是相互配合的关系。这里做成并列表格是为了方便理解,也是为了能利用二者间的张力为产品或功能快速定性。内容型产品中,工具要为内容服务;工具型产品中,内容要为工具服务。前者如我目前正在做的知识付费,后者如一些日历和天气应用。知识付费中关键的导购流程、使用流程和拉新流程,都是围绕内容展开的。能为此三大流程提供更快捷、更个性化、更有获得感的工具支持,是产品经理和交互设计师可以共同促进的地方。

为什么有的功能点击量很高却要收起?如微信朋友圈;为什么有的功能点击量相对不高却要露出?如电商的收藏、客服之类。其重要原因是前者里内容为工具服务;而后者属于应急工具,需要快捷感和效率性,如果做不到这点,它们本身的存在意义就大打折扣了。

敏感的读者也许已经发现,where 和when 有重叠的地方,因为使用场景也是信息结构设计的重要参考因素,甚至是整个策划和沟通流程的重要节点。它的作用,有些类似「用户故事」在迭代开发中发挥的作用。以上四点,是需要在迭代初期与产品经理深度沟通同步的地方。

「三」是交互说明、demo、自检表

「三」分别指交互说明、demo、自检表。需要的配合资源是交互设计师、(GUI)设计师、测试工程师等。

 1. 交互说明

使用 axure 制作的线框图结合文字说明,包括功能需要的全部界面,方便设计师和测试进行对照设计与规划测试用例。

与产品经理配合,尽量把产品文档中的规则和规格部分兼容进来。

在样式上与其他交互设计师和GUI设计师确认有没有违反既定规范的地方,在颜色、透明度、间距、大小、形状上为设计师提供专业建议。例如在重要的地方使用高亮,使用频繁的地方放大面积。

以交互设计师制定的文案规范为基础,与运营、产品经理和设计师商定元数据。注意系统平台的用语习惯和审核要求。

2. 演示用的demo

使用axure、keynote或墨刀制作,展示关键流程和动画效果。

与动效设计师明确,如果需要添加动效,预期是什么,并为其提供对应参考目标。包括为交互增强操作反馈,让流程更顺畅;为信息传达增强获得感或鼓励感;为功能增强仪式感或趣味性。如弹窗动画、金币掉落动画、开红包动画。

与开发工程师协调,流程需要解决什么问题,即用户故事。这样可以激发开发人员自带的创造性和积极性,灵活积极地应对开发难题,甚至超预期实现目标。例如某个交互动作经过调研难度较大,则可以在明确要求后,允许其根据经验自由发挥,交互设计师从旁协助。

向测试工程师说明,demo演示的只是关键部分,或静态画面和语言难以形容确切的部分,「交互说明」内会涉及到其他测试用例。

3. 简易的交互设计自检表

在交互设计师单人作战,独立决策,快速制图的日常工作中,怎么把疑虑、重点、期待、用户感固定下来,既容易掌握实现,又可以凝结以往的经验和规范,做一张简单的自检表就行了。我认为其中内容不应该拘于交互层面,也应该把产品、开发和测试的突破点写下来。宜精不宜多,方便贯彻。保证每次迭代均有不同,描述范围可大可小,且在上述的讨论过程中逐步确立。以下仅举例:

  • 点击区有及时反馈,不依赖于网络和身份
  • 文字有说服性
  • 用图片增强感染力
  • 高频率功能可以快速到达
  • 新功能有邀请
  • 无法挽回的操作有强制确认
  • 标题显示完整
  • 可以查看具体发布时间
  • 告知用户使用规律或意外情况
  • 有招牌交互

「二」是开发评审、开发走查

「二」分别指开发评审、开发走查。需要的配合资源是开发工程师。

1. 开发评审

依托以上文档向开发讲解功能点,从功能来源开始,第一遍讲创意,结合对现有功能的修改点,对其他产品的参考点。第二遍讲细节,包括用户身份、网络状态、极限情况、跳转和返回对象等。第三遍讨论关键节点和设计顾虑、招牌交互、动画效果等。如果产品经理对相关功能有多次迭代计划,也要同步给大家。以用户体验为理论基点,同时了解开发质疑和困难。

2. 开发走查

开发过程中,也会多向开发和测试宣导本次迭代的设计重点和预期效果。根据这两个岗位的工作节奏,是从基本完整开始测,从整体框架开始搭,而非按照界面顺序逐个实现。所以要注意角落处零碎的细节是否慢慢在添加,不能着急,也不要遗漏。如果发现自己设计上有坑,不要迟疑要立即提出来,再和团队商量是否立即填上,或等下次迭代。立即公开是防止问题在之后被运营、用户或公司领导偶然发现时,相关人员没有做好准备,不能快速响应。

「一」是1个教训

「一」指1个教训,即自我总结不足。

没有完美的项目迭代,对交互设计师尤其如此。我经常是迭代刚开始,自己就有了更好的交互方案,或迭代进行到一半,发现场景不对。不能不说是遗憾。上边谈到的均是如何与其他岗位资源协同,求助于人。而自己要从已结束的迭代中发现问题,总结技巧,分享收获,也把填坑方法说出来,可以让更多人看到你的努力,更加信赖你,方便以后开展工作,和推广用户体验的设计理念。

结语

以上四三二一走完,流程上并无新异之处,我把重点放在了资源协同和沟通对象上。愿交互设计师除了能成为用户的好朋友,也能努力成为同事们的好伙伴。

点赞
收藏 49
继续阅读相关文章

发表评论 已发布 3

还可以输入 800 个字
 
 
载入中....
3 收藏