用户体验设计在产品开发过程中是复杂，多变及耗时的阶段。组织良好的进程通过减少团队成员之间的误解和提供可预测性的结果可为团队减轻压力。在本文中，我想集中精力将主流方法映射到现实生活中的项目中并将可交付的成果整合在一起。

阶段1.想法

此阶段的目标是弄清楚目标客户的业务是如何运作的以及产品设计的目标是什么。低保真原型是一种有助于和股东确认产品的心智模型并讨论一般设计方法的工具。在这一点上，我们正在寻找“我们正在建设什么？”此问题的答案。

旁注：我觉得“我们在建造什么？”中的措辞比“我们在解决什么问题？”更好。它更广泛，因为它涵盖了我们现有的，持续做的项目或旨在将用户体验从优秀提升到卓越的案例。但是，如果你要从头开始做一个项目或对某主题感兴趣，我建议你可以查看斯坦福大学的“需要寻找工具”相关学科知识并了解Google Ventures研究的项目。

交付

·业务流程图

在深入研究之前绘制一幅流程图是很重要的，所以要注重流程而不仅仅是某一些特定的特性。此外，该图将有助于开发人员之后设计软件架构。我建议使用简化的BPMN或类似的方法。不要过于复杂化：制作流程图的唯一理由是让你的团队成员和你自己有一些时间来“阅读”这个过程，而不是让你的客户或管理层看起来感觉高大上。

简化的BPMN图表反映了第一艺术空间的根过程

·低保真原型

此可交付物的唯一目的是说明我们设计特定产品的方法。此时，我们所需要做的只是澄清中心场景的导航并定义设计模式（例如，向导，一组卡片，WYSIWYG编辑器等等）。

常见的陷阱

因下面三件事，通常会将此阶段挤压到最低限度或完全省略：

1.错误的印象，每个人都能理解，因为他们说他们会这样做。

2.这个阶段的所有元素，如小纸张和手绘按钮，从某种角度来看可能像个笑话。

3.有人可能认为这一步将会耗费很多时间，尤其是制作业务流程图部分，而且只需立即开始绘制场景就更有意义了。

另一个问题是设计师有时会忘记他们的想法。他们更倾向于深入挖掘细节，而不是专注于大局，所以在设计师还没意识到陷阱之前，产品需求正逐渐消失。

通常建议的手绘风格也可能一样令人眼花缭乱：人们可能会将逼近真实的高保真原型与实际为低保真的原型相混淆。我们可以轻松地使用基于UI工具包的低保真原型替换纸质原型。最初，纸质原型设计是为设计师节省了一些“工具学习时间”。当时也没有太多的专业性原型软件，所以用计算机进行迭代将需要花费太多的时间。如今，我们拥有好用的应用程序和UI工具包（Google和Apple提供这些资源）。 将控件从一个文档页面粘贴到另一个文档页面比使用铅笔绘制更快。

保真度对比

至于视觉风格，我建议使用和你要用于高保真原型的相同风格。 在这种情况下，你不用花费额外的时间将线框图从裸骨架发展为可完全交付给开发的成果。

阶段2.原型

在这个阶段，我们的目标是全面思考界面的各个方面，并为视觉设计和开发整理完整的文档。

共同原则

·为用户保持清晰，明显的导航：确保他们及时掌握当前的自己位置以及接下来会发生什么事情。
·制作移动应用程序时，根据相应平台指南进行设计。如果你必须这样做，请确保你有充分的理由来说服别人。并将此理由做好记录以方便未来讨论;
·如果没有必要，不要发明新的控件和模式，尽可能使用最常见的控件和模式;
·使用真实或类似真实的数据，包括姓名，文本和图片。但是，不要使用知名人士的名字，令人反感或含糊不清的内容 - 尽可能保持中立;
·考虑屏幕上的内容密度和系统的不同状态;
·注意在对需要移动输入的键盘进行设计时，留出足够的空间。数字键盘用于数字字段。

项目文档

关于这个问题我想说的第一件事：线框的最终用户是你的同行，软件工程师和产品经理。确保你的文档对他们是友好的。

屏幕注解，访客流程

·请记住，线框图本身并不是一个自给自足的可交付成果。它是一个可视性说明文档，可以帮助你将个人的想法传达给团队。使用文本注释，引用链接等。
·保持结构化：有意义地进行页面排序并确保它们反映业务流程。 避免将所有屏幕放在一个页面上：这将迫使软件工程师来回滚动图片。
·将标准规则放在指定的页面上，而不是将它们隐藏在线框图内。 例如，如果你有工具提示，请注解它的工作方式，并将文件与UI副本相连，而不是将它们绘制在任意位置。

一套适用于整个系统的制定规范工具

·交互式原型对于演示非常有用，但在大多数情况下，它们不足以直接进行开发。点击整个过程并创建产品是如何工作的心智模型需要额外的努力。不要让工程师的工作比应有的更难。不要将你的可交付成果限制在交互式原型中。

文档清单

每个人都会犯错误。最有经验的设计师也会犯错，但是层面不同。这里是一个简短的清单，旨在帮助你在进一步传递之前对基本级别的可交付成果进行故障排除。

这是帮助你的UX检查清单。下载后，复选框将是可交互式的。

常见的陷阱

·“人们不阅读”

这是真的。但是，人们也喜欢自信的做自己的工作。每当工程师在没有得到你的设计时，他们就会逼迫要求你澄清自己的想法，然后等待你的响应，记录下来，最后对此进行构建。否则，他们可能会误读线框图并构建错误的东西。这意味着你要让工程师负责记录你的解决方案。

还有一件事：如果某问题的答案可以在评论中找到，没有人会问我这个问题。我想我们毕竟不应该低估工程师的勤奋程度。开发人员甚至纠正了一次我的拼写错误。

·“很明显”和“这是默认行为”

事情就是这样：作为设计师，由于从业绩表现到个人品味的广泛原因，我们倾向于选择某一些解决方案而不是其他的解决方案。 没关系：用相同的问题请教两位杰出的专家 - 你有可能获得不同的答案。这意味着我们认为的最佳实践，从工程师的角度来看，是数十亿的模式之一。

即使是原生的iOS和Android应用程序也是自定义设计的，因此在Android应用程序中设计日历功能时，你不能说：“将其设置为默认设置。”猜猜为什么 ？- 因为根本没有默认日历这样的东西。你可以复制现有应用程序中的日历（顺便说一句，这是可以的），但你应该向开发人员提及，且不要期望他们从他们那里获取任何有价值的内容。

·“我们没时间做这个”

我们都在创造性和快节奏的环境中工作，在这种环境中，时间是稀缺资源。但事实是，无论如何，你都会花时间来评论你的设计。 在这里，你有两个选择。第一：你预先安排一些时间进行注解，并在准备就绪时传递文档。第二：每次开发人员需要澄清时，你口头（在信使中）发表评论。在第二种情况下，你会在当前的任务过程中反复分散注意力。

此外，你无法充分估计完成项目所需的时间，因为它没有明确的结局。因此，你可能会低估完成下一个项目所需的时间，从而无法在截止日期前保质保量完成项目。此外，想在几个月内理解未注解的项目几乎是不可能的。

验证

在验证方面，你有一些可选择的选项。

·同行评审

获得快速反馈的最简单方法是向资深设计师询问。第二种意见可能会派上用场，你也可以在展示你的设计时进行一些调整。虽然如此，你的同伴可能与你具有相同的认知偏差，因此他们可能很难找到概念问题。

·技术可行性评估

此类审核的主要目的是确保你的设计适合开发。但是，你也可以从工程师的反馈中受益，因为他们是从不同的角度看待项目。此外，如果你错过了一些重要的事情，他们可能会提醒你。

·可用性研究

方法和目的因方法而异，这取决于感兴趣的问题是什么。你可以做到便宜且脏，或者做得慢而且彻底，但不管你有什么样的资源，你都会找到正确的问题。我将在下一篇文章中讲述我在UX研究方面的个人经历。

结论

牛津词典将经验定义为“发生在你身上的事物，将影响你的感受。”这也就是为什么设计用户体验不仅仅是对屏幕进行排序和布置控件的原因。如果你的团队中没有专门的UX作者-那么你就是作家; 如果你没有研究员-那你就是。既然你是经验创造者，那你就是那个能让别人感到悲惨和无能或是有资格和有能力的人。

强大的力量带来了巨大的责任。

原文作者：Galina Kalugina

原文地址：https://uxplanet.org/ux-design-framework-402368bb6645