策划用户分析

什么样的用户分析，对揭示在每个维度更深入的需求有帮助？举例来说，你需要知道一个任务需要多长时间（效率）来完成吗？，用户怎么逐步建立起他们对使用该产品的知识（易学性）？这其中每一个都在用户研究中，提出不同的重点和技术。

当用户研究和分析结束之后，你就有机会去了解用户研究的结果是否与最初的设想不同，或者是比最初的设想还有所延伸。和项目中关键人物一起来进行这些最初的工作，不仅仅帮助可用性专家了解他们的观点，并且也可能会揭露一些不正确的设想。

建立可用性目标和需求

每个用户对于5E的描述都可以作为可用性的目标的基础。在那些含蓄的描述中，什么才是一个产品必须去满足的需求？一个像“我怎么才能知道它是不是给我注册了正确的课程？”这样的用户描述，可能会引出一个“用户需要在做出最后的行动时对一切进行确认”这样的需求。或者一个程序有一些罕见的任务可能有需要典型的、经过训练的用户去完成的可用性目标，而不需要其他的训练和额外的手册。

无论用户描述是否提及到功能性的需求或者可用性目标，都应该在最初的对话中将它们与其中一个可用性维度联系起来。

这也可以表明需求的区别——或者强调的重点。例如，项目经理可能更关注工作的效率，并且认为是花在任务上的时间问题，而一个工人可能认为是一个错误宽容度的问题，并且认为是这个应用如何更好得支持他们工作的问题。

建立设计概念

怎样才能使设计方法更着重于可用性的最重要的尺度？什么样的设计元素能够帮助制作出针对用户需求的界面？会不会有一些用户偶尔需要某些快捷方式或者方法来处理超过一个“项目”，或者少数用户需要一个嵌入式的帮助来“提醒”他们如何使用界面？

每个5E都会建议一些方法：

维度：有效性
用户需求：准确性
可能的设计需求：

·为所有的动作提供反馈信息;
·排除错误的可能性|

维度：效率
用户需求：操作的速度
可能的设计需求：

·设计完美的工作流程，也留下改变的可能性;
·提供快捷方式;
·用互动风格和设计的小装饰支持速度问题;
·把屏幕上无关的元素减到最少

维度：吸引力
用户需求：被吸引其中
可能的设计需求：

·将“品牌承诺”结合到设计中;
·运用适当的词汇和术语;
·设置恰当的、有帮助的语气

维度：错误宽容度
用户需求：确认和批准
可能的设计需求：

·将“错误”转化成其他途径;
·运用可以帮助正确选择的控制;
·确认动作都是可逆的;

维度：易学性
用户需求：时间信息
可能的设计需求：

·让界面在最少的提示和操作说明下更有帮助
·为难度大的和罕见的任务创造有指导性的界面
·策划可用性测试

什么样的可用性评估能确保设计可以实现可用性目标？什么样的原型才能得到可用的结果？试例，如果一个应用软件要支持一个有效的运转工作，那就需要用高精度的原型或者程序初期的文本进行测试，需要最初的训练和一整套现实的工作来匹配典型的工作环境。一个产品可能需要用最初的概念原型进行测试，用以所定人群。

维度：有效性
可能的评估技术：

·为有困难的和不明确的任务创造演示场景
·根据任务被完成的准确性如何，和任务产生的不易被察觉的错误来评估一个任务

维度：效率
可能的评估技术：

·用足够的具有典型任务的副本架够测试，去创建现实的工作节奏
·运用工作软件或者高度仿真的产品原型
·收集时间数据，同时也访问参与者，看他们对程序的主观印象

维度：吸引力
可能的评估技术：

·运用满意度访问问题或者调查作为评估的一部分
·对设计表现做有对比的偏爱测试
·架构一个参与者可以选择放弃产品的测试

维度：错误宽容度
可能的评估技术：

·为可能出现的错误或者其他问题设置演示场景
·观察用户在遇到错误时，能不能简单、准确地修复错误

维度：易学性
可能的评估技术：

·控制需要给参与者多少操作说明，或者招募不同层次和知识水平的参与者
·将最常用的任务和不太常用到的任务或者场景混在一起

结论

对于每个项目或者个人来说，在项目的整个生命周期中，贯穿运用可用性维度将进程和设计决策联系起来，这是一种很有效的方法，它可以将所有“以用户为中的设计”的元素结合在一起；对可用性在特定环境下的理解，也可以让工作集中一致。5E可以作为新的可用性研究技术的基础，帮助“推销”可用性及其力量，并指导设计项目走向成功。

ui花园版权所有，经许可转载  英文原本地址点击

出处：UI花园
责任编辑：moby

上一页 可用性的维度 [3] 下一页