精益用户体验(UX)：摆脱只注重结果工作.pdfVIP

精益用户体验(UX) ：摆脱只注重结果的工作 By Jef f Got helf f ro m SmashingMagaz ine.co m 翻译编辑:DamnDigit al, (转载请说明翻译来源, 尊重我们的 力) 网页 （以及交互设计 ，界面设计 ，等 ）传统上是基于可交付的形式来执行。框架、网站地图、流 程图、内容清单、分类系统、原型和规范文档 （又称 T he Spec” ），帮助定义网站在其起步阶段的 执行。这些结果构成了一个系统的用户体验的衡量标准。 随着时间的推移 ，这个注重交付成果的设计过程却将用户体验设计师放在了交付业务上 ，用来衡量 和补充他们设计成果的深度和宽度 ，而不是所设计的用户体验的质量和成果与否。设计师已经变成 了以文档为目标的专家 ，他们了解由他们所创建的文档的质量而不是设计开发最终的用户体验。 当与一系列瀑布式开发方式相结合 ，这些花费的大量时间和金钱的设计成果最终只是一件废物。废 物即指那些对最终产品开发不具任何作用的东西。。 内部人员沉浸于旷日持久的设计周期 ，缺乏冒险精神 ，从而失去市场机会。Engaging in lo ng draw n-o ut design cycles risks paralysis by int ernal indecisio n as well as missed w indows of market o ppo rt unit y. Image by o penso urceway. 想要在变幻莫测的市场竞争中保持优势 ，就必须保持灵敏度 ，所以快速进入市场变得尤为重要。由 于内部决策的优柔寡断而将时间浪费在冗长的设计周期上 ，导致错失市场先机。换言之 ，当公司内 部在决定产品应该如何设计的同时 ，市场需求已经发生变化。 瀑布式软件开发看上去像是这样的 ： 定义 →设计 →开发 →测试 →部署 （投放 ） 设计阶段通常分解为 ： 等待需求定义生成并获得批准 → 消费需求文档 → 开发高级网站地图以及流程图 → 获得认同 → 为各部分体验开发界面框架 → 向项目利益人汇报并获得认同 → 为每个线框图进行视觉设计 → 向项目利益人汇报并取得认同 （重复汇报流程 ） → 确定设计规范 ，详细至每个像素和交互 → 对将来的提升空间进行可用性测试 → 提交开发部门审阅、批准 ，开始执行。 根据项目范围的不同 ，这个过程可能会花费1-6个月的时间 ，不但浪费时间也使设计师们备受煎熬。 进入匮乏的用户体验 精益用户体验 灵感来自于精益而敏捷的开发理论 ，精益用户体验是将我们真正自然的工作快速进行实践 ，减少强 调成果而更加重视实际过程经验。 传统的文档将被丢弃 ，或者至少剔除原本缺少的部分 ，只提供执行时所需的最低数量的必要信息。 相比较冗长而细致的设计周期 ，我们更推崇简短、迭代、低保真的设计周期 ，并且可以更早、更频 繁地接收来自执行团队所有成员的反馈。整个团队的相互合作是产品取得成功的关键。 不足为奇的是 ，精益用户体验设计方法的直接受害者是那些项目受益人 ，他们在一旁默默地工作 ， 只是在项目完成”的时候邀请他们看一眼。这种心态也成为广泛施行这种方式的最大障碍。 让我们来看一下精益用户体验的过程 ： 保持精益 ，聚焦体验 ，而不是停留在纸上谈兵。 看上去很熟悉 ？是的 ，如果你熟悉敏捷的或是其衍生产品。整个过程从轻量级的概念开始。它可以 在一块白板上、一张纸巾或者是快速线框图上生成。它的目的是将创意或者流程的核心概念快速展 现在你的团队面前。 团队开始提供他们在这个设计方向以及可行性上的见解与观察。也许会对原来的想法有所更改 ，也 许将原本的概念完全推翻而提出一个全新的想法。起初草图阶段的投资是非常小的 ，即使是完全推 翻原来的方向也不会产生显著的开销。一旦一个方向在内部商定 ，一个粗略的模型有助于将概念有 效地展示给客户。这样的方式有助于改善创意 ，循环重复。 在这里最重要的是 ，精益用户体验严格关注软件开发过程中的设计阶段。无论你的机构选择什么样 的方法 （瀑布型、快速型 ，等 ），这些概念都可以被应用于你的设计任务当中。 这不就是由委员会设计 ？ 精益用户体验鼓励你 ，设计师 ，更早更多地向你的团队展示你的工作 ，收集他们的见解而后将其嵌 入设计的下一个迭代中。 对许多人来说 ，这听起来像是可怕的 由委员会设计” ，这在过去几年已经 扼杀了许多设计。 事实上 ，即便堆积了如此多的反馈 ，设计师还是保持对设计的话语权 ，他们评估什么才是对商