原文链接:Enterprise UX Case Study: Improving Usability Under Tight Deadlines by Jerry Cao Jerry Cao
原文作者:Jerry Cao
译文作者:shu℃
基于云的一款项目管理系统,Liquidplanner需要去帮助用户更快地创建dashboard。
在原先的过程当中,需要去创建dashboard,还有其他所有的小部件,全部都是从头开始。为了让dashboard能够被更多的用户使用,并提高它们的生命周期,产品团队着手去创建一个新的dashboard模板功能。
团队的目标是创建“一键解决方案”,用户可以创建一个有用的dashboard而无需任何配置。
在四个月的时间里,LiquidPlanner塑造了一个新的dashboard模板功能,这让用户印象深刻,并且有很高的使用率和很好的商业效益。
接下来,你会看到他们是如何做到的。
图片来自:LiquidPlanner
设置情景
在进入实际的过程之前,我们需要先确立用户人群和项目目标。
1、主要用户
LiquidPlanner有三个主要的用户的人群:
产品经理-这些人是产品的重度用户,他们几乎黏在LiquidPlanner上。这些决策者确保团队使用产品来跟进时间,合作,使用功能来帮助他们做的更好。
职能经理-像是以下其他的决策者,如UX经理,或其他主导团队的人,确保自己对产品负责。
前线贡献者-大多数使用产品的人。这些在前线使用产品的人,可能并不是他们选择了LiquidPlanner,但是他们每天都因为项目使用它。
2、产品目标
下面这些定量和定性的目标会确定dashboard模板功能的成功:
在30天内开放增加dashboard的使用率,使用Heap去跟踪应用内事件,他们发现在整个项目中,创建dashboard有许多的磕磕碰碰。
Grant立即获得了项目的关键信息,它不仅与质量有关,而且与速度有关。LiquidPlanner需要去简化访问数据的流程。
在三个月的时间内完成这个项目,从2016年的1月开始,预期4月初上线,留给了团队一个紧张的时间来给出正确的解决方案。
阶段一:发现&概念
(2016年一月上旬)
在实际执行之前,我们团队进行了头脑风暴和草图会话。项目经理,UX经理,和UX设计师Edward Nguyen也都出席了。
检查Heap的应用内模式,团队将最常见的dashboard进行了分类:
项目Dashboards
团队Dashboards
文件Dashboards
他们在白板上概述了自己的想法。这里主要涉及到用户流程图,画出屏幕上的体验。从用户流形成的基础上,最终演变成dashboard的完美解决方案。
第二阶段:创建和测试低保证流程
(2016年一月上旬)
在紧跟白板会话之后,Edward使用AI绘制了低保证版本的白板草图,这些低保证的流程,在用户进行高保真原型和测试之前,成为了关键的中间阶段的内部测试。
首先,早期的反馈收集,Edward展示了低保真用户流程给5~10个产品团队以外的同事,他管理这些单独测试,解释相应的问题,收集反馈,并用来指导dashboard的迭代设计过程。
这次非正式的测试也给了他一个机会来回答一些个人关系的问题。最终测试证明是成功的,没有负面反馈就是一个好的反馈。
阶段三:高保真原型
(2016年一月中旬-二月)
建立一个中保真的用户流程和内部反馈,团队准备创建第一个版本的功能设计。
1.创建
线框图和中保真的用户流程展示了产品可能是如何工作的,那么一个原型将是展示产品是如何工作的。
因为创建一个原型的目标是测试你的设计决策,第一步就是在可用性测试计划列出所需要的见解。文档优先测试最重要的目标用户的操作:
验证用户是否知道如何创建一个新的dashboard。
验证三个默认的测试模版是否有用(项目,文件,团队)
验证创建仪表盘的功能是否能在项目中被发现。
确认默认的组件在dashboard中是有用的。
可用性测试计划还包括部分如测试脚本以及撰写用户任务(即:你能为项目A创建一个模板dashboard吗?)
在这个阶段,团队做了一些数据挖掘库存和统计模板部件。这让第一个原型更接近最终产品。
创建dashboard模板流程的第一屏高保真原型
新的设计需要足够直观,让面对的用户没有困惑,爱德华选择了一个笨拙的左侧标签格式,来与团队最初画的多步骤过程做比较。最后他意识到他的选择比团队的更加易于实现,并且用户也能受益。
设计师不需要去创建有趣的图标,开发人员不需要构建一个多步骤向导,用户可以通过更少的步骤选择他们的dashboard。
Edward解释道,设计师不需要知道如何写代码,但是他们应该了解设计会涉及的技术。
2.可用性测试和迭代
团队进行远程会议,通过Join.me有14人参与了测试。
Edward主持了测试环节,另外一个团队成员观察并做着笔记。他们测试了两个主要场景:创建dashboard,在现有的项目中发现dashboard。
测试结果是快速的迭代到了下一个版本,然后进行同样的测试和结果反馈,直到团队想出了一个被证明是理想的设计。
“用户甚至误以为我的高保真原型就是真实的产品,告诉我感谢我们的开发团队。”Edward说。
高保真原型让用户误以为这已经开发完成了
可用性测试解释了设计是一项系统性的工作:
用户发现从标签布局创建dashboard模板,更易于使用和理解。
用户提及了默认的测试模板是有用的,并且符合他们的要求。
虽然大多数用户发现默认的小组件有用,但是有一部分用户说他们会按个人喜好选择小部件。例如,一部分用户没有找到“剩余工作”的linechart部件。另外一部份人则表示自己完全没有自制模板的能力。
用户一旦创建了dashboard,体验就会变得稍微困难了一些。
Edward花费了相当多的精力和时间去与项目经理讨论映射模式来增进理解。异常的评论适用于一些可操作的反馈。
为了让新建dashboard更容易被发现,Edward决定增加负空间,在“视图项目Dashboard”下标签出详细的视图。
进一步的改进,例如保存部件编辑的功能,在后来被用在测试,因为它们不属于MVP的范围内。
阶段四:研发并且上线
(2016年二月-四月)
在敏捷开发之后,研发冲刺紧跟着设计冲刺。
尽管Edward的团队仍在测试原型,研发人员已经构建了验证迭代。“协作高保真原型和测试的见解给我们的研发人员足够的信息,在代码中实现我们的设计决策。”Edward说。
团队中的有效沟通提高了每日站会的效率,Edward会公布任何新的研发人员对可用性测试的见解。
因为新功能测试效果很好,LiquidPlanner发布了新的dashboard模板功能,而没有发布beta测试。尽管团队可以测试大量的性能,他们仍需要让功能走出房门,因为现在的dashboard很不一样。
感谢高效的高保真原型和无间的合作,团队在2016年的四月九日推送了新的功能,在计划的时间范围之内,最终的结果是:
已经有超过17000的dashboard在LiquidPlanner中被创建,其中1700(10%)是在发布后的两周内创建的。
模板功能被75%的新dashboard使用了。
绝大多数的大型企业客户已经在使用并享受这个新的功能,因为它可以推动他们大型,复杂的项目。
“我要被这个数字给吹走了。”Edward说,“很高兴我的工作能够受到用户的欢迎。”
其它
基于LiquidPlanner的成功,我们可以将这些知识应用到我们的产品设计过程中去:
不要过于雄心勃勃地重新设计项目。新的设计需要对老用户足够的尊重,保持一致性,并同时还要能够吸引新用户。为了实现这一微妙的平衡,请保持一切尽可能的简单。
为了效率,当然可以直接从草图到用户流程再到高保真原型,只要你能够让测试跟上脚步。因为现有的视觉设计标准已经验证,所以高保真原型的风险较低。
压缩时间,确保设计人员能够领先研发人员一个sprint。
像Edward那种拯救“小部件编辑”的功能,不要害怕在上线之后测试过程中发现了新的想法。
与详细的高保真原型密切合作,研发人员可以实现代码的转化,并且会较容易的理解。