人们往往低估低保真线框图（wireframe）的审美价值，如果说这一组组灰盒子仅仅是我们工作交付成果的话，那么外观也无关痛痒，对吧？错，大错特错。
　　视觉表达过度的线框图的确会破坏人们对其想法的理解，就像是一个人穿着Stormtrooper服装去参加重要的大使馆会议一样。尽管Stormtrooper是星球大战粉丝聚会上非常耀眼的服装，但它绝不可能帮助您在大使馆做任何事情；反之，如果你递交给项目经理一个丑陋的线框图，并没有附带任何描述，你觉得你的同事能按你的设想采取行动吗？他们会怎么想？最后依此做出来的产品是否能满足用户的需求？我想并不会，交流不畅的设计只会给项目带来混乱和误解，如果用户体验设计未被PM和团队重视，最终想要获得高质量的产品也将会是非常艰难的。
　　这就是我强调线框图美学的原因，阅读你设计文档的人在某种意义上也是用户，你需要谨慎地对待他们。但这是否意味着我们将被迫花更多的时间在项目的构思阶段？我想并没有：设计线框图就像其他工艺一样，需要许多规则的实践，一旦你熟悉了这些技巧，它仍能保证项目进度不受影响。在这里我归纳了几条线框图美学原则作为参考：
　　1. 消除所有干扰物
　　只有当消除干扰物后我们才能有效沟通，那么什么是线框图中的干扰物呢？略举几例：
　　不适当的配色
　　不合适的保真度
　　丑陋的图片和icon
　　无意义漫画/诡异的字体
　　其他只有你才看得懂的代码
　　这些都属于让读者远离你设计理念的东西。说来有趣，我认识的一个UX设计师有一种特殊的习惯，他在每个占位符（交叉矩形）上都使用了缩写来标记他期待什么类型的图像，我想这对他而言当然有一定的意义，但外人却无法理解。所以如果你将和你的团队分享这个文档，千万别让这些缩写扰乱他们对设计意图的感知。
　　2. 小心使用颜色
　　线框图必须是一系列非黑即白的长方形，还是说允许五颜六色设计的出现？Neither，实际上想清楚地传达设计仅需遵循一下简单的原则：
　　使用灰色阴影作为界面的线框结构和内容
　　使用不同灰度的区块来表达层次
　　将所有图片和icon保留成灰色以防视觉上的突出，在不同元素间适当使用对比保证可读性可以适当考虑使用颜色高亮，表达特殊意义：例如蓝色代表链接，红色代表警告，绿色代表确认等避免黑色，黑色的边框会让线框凌乱，在许多情况下“真正的boxy”反倒会成为干扰物
　　3. 避免过度设计
　　过度设计是新手用户体验设计师的常见错误，尝试以简化、清晰和快速的方式传达设计理念，不要太花哨。仅仅因为线框图不要看就花费大量时间制作界面元素会很浪费时间，因此每当思考一个特定元素是否准备好时，请问你自己如下问题：
　　它是否能帮助（读者）对该产品用户情境上下文流程的理解？
　　它能清楚地传达其意义和价值吗？
　　你的同事能理解它吗？
　　不要自问设计是否好看，请自问是否合理。
　　4. 使用真实（近似）尺寸
　　务必建立一块真实尺寸的画布。例如Web应用程序的宽度为980px，则也应在980px画布上进行wireframe的设计。为什么非得这样做？的确在1200px的画布上进行元件布局要比980px的画布上容易太多了，但我们最终还是得将内容压缩到指定规格的空间中去。在引起产品开发的混乱前，还是乖乖遵守这种约束吧。
　　5. 记得功能可见性！
　　用户体验设计之父唐·诺曼曾借詹姆斯·吉布森提出的“功能可见性”（affordances）的概念来描述用户根据感知到的某些事物获取暗示，从而产生行为的现象。例如界面设计中的按钮往往看起来像是能被按下的；标签栏似乎能提醒用户在内容区块间进行切换的行为等。因此为了清楚表达你的idea，你的按钮就必须要像按钮、标签栏就必须要像标签栏。对于最终产品，功能可见性的意义在于指示某种特定行为，而在线框图绘制阶段，它能让你的表达更容易被直观地理解。
　　综上，我们已经遍历了所有wireframes的设计原则，如果你的确遵守了，我相信你能做出一份很好的交付成果。但在这里我还想说的是，如果脱离了整个故事（story）的上下文（context），即便是极具美感的wireframes也不能帮你传达设计思考。我特地在这里故意使用了“故事”一词，因为就像是你喜欢的故事书一样，在设计中你也会遇到：
　　一个主角（也就是你的用户）
　　一段情节（也就是用例）
　　一个问题（也就是用户面对的问题）
　　如果你精心制作的线框图仅仅讲述了故事的一部分，片面地呈现了一个用例和问题且并未交代与主角有关的信息，那么你的读者可能很难把控整个画面。想象一下没有任何英雄的一部指环王，如果它仅仅简短地提到了戒指，索伦之战以及大量对中土世界的大量描述，你仍然会摸不着头脑，没有继续读下去的意愿，毕竟太难理解了。
　　如今一提到用户体验设计（UED），人们就往往想到Wireframing、画线框图啥的。但与其说UED就是设计Wireframing，不如按照字面意思将它理解为对“体验”本身的设计——我们希望能通过一些方法对目标群体与产品交互的行为方式产生影响。为了做到这一点，我们就要写下完整故事，以具有说服力的方式告诉团队和利益相关者，从而鼓舞他们采取行动。你有一大堆工具和方法在帮助你完成这项任务：
　　用户画像（Personas）
　　用户故事和用例（User stories and use cases）用户流程图（user flows）
　　概念图（Conceptual diagrams）
　　商业模式画布（Business Model Canvas）以及其他牢记你的目的永远是描述清楚用户是谁，问题是什么，以及解决方法是什么，所以务必选择最有利于你连贯且吸引你的听众的叙事手段。
　　想象一下某天一个铅笔供应商突然闯进我们的办公室，要求我们在明天前做出一个大量售卖铅笔的网站（也就是说我们并没有时间进行初步的调研和项目启动），我们还是不是应该立即打开线框图编辑器开始画概念图呢？
　　当然不是，一个更好的解决方法应该是这样：我们首先需要确定用户是谁，并召集整个团队来采访你的客户来挖掘业务主要的目标群体；之后再通过创建用户画像对用户的共同行为模式、态度、动机以及基本人口统计特征进行归类，将关注点放在他们的问题，而非具体的特征上。在此之后你需要继续详细描述这些你所需要解决的问题，并对整个项目进行配置。你的委托人可能对此不以为然：“我需要卖更多的铅笔！”他尖叫着，但你无需理会，因为这并非一个待解决的问题，而是项目的结果。毕竟真正问题总是待在用户那儿。
　　阐述一下，为什么是用户画像上的这些人想要买铅笔？他们遇到了什么问题？他们的动机、目标和态度又分别是什么？和你的委托人谈谈业务方面的事，确保自己了解了合同上的需求。这些讨论和思考的过程可能花费较多的时间，但我相信它确实有助于更好地了解项目并创建故事，直至你们真正令用户满意。
　　本文译自designmodo上的博文《The Aesthetics of Wireframes and the Importance of Context》，若翻译有误欢迎指正。
　　作者：Marcin Treder
　　译者：ARILIANO
　　原文链接 https://designmodo.com/aesthetics-wireframes-context/