原文链接：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那种拯救“小部件编辑”的功能，不要害怕在上线之后测试过程中发现了新的想法。
与详细的高保真原型密切合作，研发人员可以实现代码的转化，并且会较容易的理解。
原创文章，作者：ioued，如若转载，请注明出处：https://www.iamue.com/16923/
