进行界面设计时，很显然我们一上来就会想着画出整个流程。但这真的是最好的方法吗？ 我曾偶然进行了编写一个具有想象的人机对话，之后我再继续使用画流程的方式。
编写人机对话的方法改变了我的思维方式，我再也没有上来就先画流程图。这篇文章将解释我作这种决定背后的原因。
我一直是Basecamp的设计师们的崇拜者。前一段时间，我阅读了其中一位叫Jason Zimdars的设计师的推特内容：
“UI设计始于对话。 “他不是在开玩笑。转发及评论有很多，也获得了很多赞。每个人都明白他的意思——除了我以外。
编写对话
当我不得不设计一个界面交互组件时，我习惯地一上来就使用草图来画出所以可能的解决方案。 (产品设计是由许多层构成，例如Jesse James Garrett的对讲机结构层（PDF），在这里单指交互层。)
对讲机的产品设计层
我习惯于使用一种我知道的或通过复制别人的问题或类似问题的解决办法的这种模式。想象一下，你要设计一个网站的注册表单。你可以先“偷”其他设计师的解决方案。或者，如果你有信心，你可以阅读需求，然后画画草图。
我呢就是使用画这种方式。
曾经我设计一个电子商务的网站设计的购物车过程。 虽然我不知道为什么，但当时，在研究可能的解决方案之前，我想象着如果是我在超市中进行付款时我应该做什么。我想在网络上复制一个类似的经验，以此通过利用web的数字能力可能改善它。我在超市收银台写下来会发生什么：
收银员：您好，你有会员卡吗？
我：是的，有。 (我把它给她。)
收银员：谢谢。
我：谢谢你。
收银员：请问需要袋子吗？
我：是的，两个。
(等等。)
我意识到想象谈话比白色的画布上画要容易得多。 我不确定，但我想，对大多数人来说：对话是人性的一个内在部分。并且我们已经进化成为一个可以说话的物种。
而且，当我想象一个谈话，我运用了我的真实体验，更少的抽象对设计是有益的。如果用户与计算机交互的类似于现实生活中的经验那样，那么界面可能会被认为易于使用，难道不是吗？
此外， 当我写的时候，我更多的关注是对话及其意义。这样做的好处是，当我画草图时，在副本中我会犯更少的错误。因为复制是界面中极其重要的一部分，这也是写出对话的一个伟大的附加作用。
一个真实的例子
想象对话是很容易的，想象一个不同对话也很容易。回到超市的例子：我可以很容易地想象收银员询问我的优惠卡后会问我是否需要袋子。很容易能够想象到收银员会问我不同的问题。这也许会也许不会改变界面的草图。现在如果这不能改变什么也不重要了，重要的是，我已经考虑进去这些。我能想到的演变越多，我会觉得在我的最终设计中更有信心不会遗漏什么。
通常从产品需求到用例列表再到mockup(即低保真草图或高保真线框图，根据情况而定)，这成为HTML原型的基础。理想情况下，这个过程是线性的，在现实中，这是一个循环，每一步为我提供反馈，并改变之前步骤中的一些事宜。
我的设计步骤
因为写作使我看到更多的变体，它提高了“用例”和“草图”之间循环的有效性。
让我们来看看这个例子。以下对话来自于一个实际的项目，一个名为Mediaddress的web应用程序，一款新的新闻办公室软件。这是一个记者的档案地址。项目的要求之一是，人们应该能够发送电子邮件到一个或多个接受者。
我正在考虑的用例是这样的：用户错误地从100人的列表中选择5人并忘了取消他们，而是想发送电子邮件至100人的整个列表。
演变1
人类：我想发送一封电子邮件。
应用程序：您选择的五人或所有这些吗？
人类：所有。
应用程序：写邮件，你喜欢使用你的电子邮件程序还是更喜欢自带的编辑器？
流程图演变1
草图演变1
演变2
人类：我想发送一个电子邮件。
应用程序：好吧，我将给您选择的5人发送一封电子邮件。写电子邮件，你会更喜欢使用你的电子邮件程序还是自带编辑器？
人类：不，等等! 我想发送一个邮件给100人不仅仅是我选中的5人
应用程序：好的，没有问题，我将这样做。那么写电子邮件，你会更喜欢使用你的电子邮件程序还是自带编辑器？
流程图演变2
草图演变2
基于用例，我写一个对话，可以很容易地转化为流程与草图。然后，我想象着谈话的一个演变，于是产生了不同的流程与草图。为了更好地理解流程与草图，我对用例进行比较。
假设用户从列表中选择5人但他想要给整个列表中的人发电子邮件。这是最常见的情况吗？ 我不这么认为。不为这些真正想给5人发送邮件的用户做优化难道更有意义吗？
设计包括权衡，我们不得不在用户选择的成本和收益间进行权衡。但是我不想细讨论哪种决定是最好的解决方案。这里有很多标准，我的观点只是展示对话场景是一个有用的设计工具。
我在对话，流程图和草图之间来回跳转，但是指导工具是书面谈话。我觉得这是去想象一个交互最简单的工具，图表和草图(或线框)随即而来。对话可以创造秩序并帮助我看清楚步骤，同时也是一个与开发人员和其他利益相关者沟通的更好的工具。
总结一下我的观点：
- 想象一个人机对话，然后画草图比直接绘制界面更容易。
- 想象的对话是来自现实生活的经验，而直接画草图更多是源自于记忆中的设计。
- 复制是任何界面的基础，先写后画能够使我们在正确的时间专注于它。
- 想象不同的谈话比想象不同的草图要容易得多，这使得它更容易想出更多的设计选择。
- 写的时候我更有创造性(因为我可以想象更多的变化)，我倾向于少复制别人的解决方案。
那么杰森的观点呢？
最后，我明白杰森在他的推特上写得那句话的意思了吗？ 为什么不直接问他呢？ 我写一个电子邮件询问他关于我这种方法的意见。他非常友好地回答我：
“我阅读了这篇文章，我认为你非常了解我想说什么。想象一个用户和计算机之间的谈话是一个简洁的思考方式。在我的工作中有一些稍微不同的地方。除了电脑，我试着想象我会怎样给朋友解释功能。这种明确和有帮助的会话具有重要意义。我认为不考虑计算机也是特别有用的，因为它很容易进入我们都见过的模式”电脑说“，这很简洁，让单词听起来不像任何人们实际上说的那样。我希望我的UI读起来像我说的那样，这意味着它具有自然语言和完整的句子。
我肯定会修改很多次草图的形式，继续完善在整个过程。比起一开始就写很少的话，更好的做法是先写后期再去调整和优化。这就是为什么我更喜欢这种方法去画草图。画时，你过早地考虑布局和可用的空间，及太久了以至于不能合适地画上一个按钮。那些都是当前需要处理的限制，而我发现最好就是立即写对话，然后再想视觉设计。
这有个简单的例子，首先是你可能画的电脑对话版本：
- “删除文件”
- [好][取消]
现在你可能会有另一个版本：
- “你确定你要删除这个文件吗？”
- (是的，永久删除它)或者(不，我想把它)
这有点做作，但你懂的。我觉得当你一开始画的时候电脑对话版本就是一个简单的陷阱。如果空间是非常有限的，我当然可以查看第二个，但是为什么不从一开始就出你最好的版本，然后再考虑其他原因呢？
我从中得到的是：
- “我认为一开始不考虑计算机是特别有用的，因为它很容易使我们落入我们都见过的模式中”； 简洁的“电脑说”脱离语句并且听起来不像任何人们实际上说的。
- “这就是为什么我更喜欢这种方法画图。 当你画时，过早地思考布局…我觉得当你一开始画的时候电脑对话版本就是一个简单的陷阱。”
- “比起一开始就写很少的话，更好的做法是先写后期再去调整和优化。”
紧接着我又问杰森一个问题，就是如果这个方法确实奏效，那它如何帮助他找出流程：
比方说你有一个功能并且开始写，写作是否让你想想流程或功能，正因为你改变了流程或特性？ 或者是一个单独的流程或功能的思考过程？或许通过一个例子我可以让自己更清楚些。想象一个书签应用：
我：保存这个网络地址。
电脑：好的。
第二个版本：
我：保存这个网络地址。
电脑：我保存它之前，你想改变页面的标题吗？ 你想添加一个简短的描述页面的内容吗？ 你想标记页面(这样很容易检索)吗？
第二个版本改变了流程。现在，当我想保存一个网址，会有个弹窗。在第一个版本中，我就只看到确认反馈。
杰森的回答是：
所以，流程如何有效取决于场景。很多时候功能并不完全隔离，它们融入现有的流程和屏幕——或者至少从那里开始。所以，我脑中对流程已经有一些想法。 但如果写作让我通向另一个方向我总是乐于提高。但是，即使这是一个全新的时代，我将还是从写开始，因为它帮助我理清流程。如果向你的朋友解释流程需要很多步骤，那么它在软件中需要分解成类似的文字结构步骤。所以，就像我提到的流程，典型的写作草图可能包括几块的副本。我认为联系的重要部分是指出在现实世界中你是如何认为的，而不是简单地认为这纯粹是一个软件问题。所有的这些将导致新的见解。
这两个邮件似乎验证我的方法，它们也给我新的见解。并且来自高级设计师的反馈让我非常高兴。
原创文章，作者：Tinadmin，如若转载，请注明出处：https://www.iamue.com/7939/
