Bindo POS 3.0的设计过程
以上是该应用上百个界面中的一小部分
早在2013年5月，Bindo POS的第一版，一款iPad登记软件，带着许多先进的业务功能问世了。然后它在几名设计师手中经历了多次迭代，其中还有才华横溢的Sean Farrell。不久后IOS7发布了，我负责进行改版设计，以迎合新的风格。2014年1月，2.0版发布了，如你所料，仓促赶出来的产品平淡无奇。
1.0与2.0，仅仅是视觉上的修修补补。
我们的产品中打包了许多功能。我们源源不断收到客户的反馈与新功能需求。正由于我们用户的多样性，这些需求往往专门针对他们所属行业。这些通常都是不容忽视的功能。如果不加入它们，产品则根本无法使用。我们支持的各种硬件设备，更加剧了它的复杂。例如，每种发票打印机模版配对方式都稍有不同。有时候感觉我们仿佛是在设计一套独立的操作系统。
我们没法关注多数用户，或者选取一通百通的最佳方案。这是单一功能的极简型产品的另一个极端。随着越来越多功能的加入，按钮数量剧增，应用变得臃肿。我们需要一套简练的解决方案，来适应尽可能多的使用场景。
一场大扫除刻不容缓。
最初的一些草图。我们画了将近400张这样的图。
线框图
我们从质疑上一版的决策着手，同时尽可能多收集客户反馈与功能需求。根据优先级分类列出所有可能的使用场景。这通常是简化事情的重点，只有少部分使用场景被认为是必要的。但是，既然我们要满足各种业务的需要，我们集思广益来提高灵活性。在这个阶段，用户调研扮演着至关重要的角色。
好吧。我也当了一回标题党。
简洁仍然是我们所追求的。只是我们无法立即摆脱其中诸多限制。但这不意味着我们无法使界面更智能易用。接下来这版更新，我们寻求的是环境的融合，甚至有时是可预期的。如果临近中午时分，或许你会需要午餐菜单。如果你向供应商订货，有可能你想查看需要补货的库存清单。我们严格控制按钮的数量，减少杂乱，避免屏幕上产生太多选项。遗憾的是，用户似乎并不会注意到所有这些简化工作，除非对比着给他们看。¯( ツ )/¯
怎样才算过于复杂？我们允许何种程度的定制化，考虑哪些使用场景？这些是在一开始就要确定的问题。线框图就是一种寻找最佳方案的绝妙手段，却不用投入过多的时间。
一切都需要经过设计——不论是有意的决策还是无心的过失。
当我深思所有这些设计意图时，我就真正开始相信自己的设计正在成长。一切都需要经过设计——不论是有意的决策还是无心的过失。以扫码界面为例。它看起来似乎千篇一律，但只要你提出问题，就会发现它显然不能凭主观臆断。有个框框来放置条形码，但这个框实际上并不是扫描区域的边界；它是一种指引，表明摄像头应该离条形码多远才能聚焦。方形的形状也不是巧合。长方形会暗示人们将条形码旋转到特定角度，而我们想表达的是，我们支持任何角度扫码。
像扫码界面这样无关紧要的细节，都经过了细致的构建。
原型
原型的画板已经近乎疯狂了。有如此多选项可供选择，每个都有其优劣。我们从线框图开始做原型，随着工作的进展持续推进。但我们为何感到困扰？
1.它使你尽早确认想法或发现问题，就不会等到代码都写完了才发现残酷的现实——它没有用。
2.在真实设备上预览设计十分重要。某个手势或许比你想象得更难操作，某个按钮也可能比你笔记本电脑上看起来更小。
3.不会成为开发团队的眼中钉，动不动找他们麻烦，他们会因此热爱你。
4.不用与工程师们来回折腾。你可以随心所欲对各种因素进行调整，直至完美。
5.不必撰写无人能懂的需求文档，你能直接分享交互式原型，准确演示你脑海中所想。
6.如今，制作原型实在太简单了，有那么多优秀的工具。为什么不用？
如果要用文字来解释复杂的交互，总是会令人疑惑。
但是并非一切都需要高保真原型。要快速测试用户流程，我们的选择是Marvel。配合他们新增的用户测试功能，你可以记录屏幕界面和使用者的操作，这对于可用性测试极有价值。
我们要求所有自定义动画都要在原型中体现，并得到充分测试。它们的目的应该是向用户交代界面的变化，引导他们达成预期结果。以我们结账流程的动画为例，结账按钮原先会触发一个完全不同的界面，虽然两个界面有部分是共用的。在这版更新中，两个界面结合成了一个连续的界面，通过动画来表现它们的关联。这个动画也可以通过滑动手势触发，可以快速开启结账流程。
下单界面和结账界面合并了。
动画也能取悦用户。加入多少动画，这能考验设计师自制能力。制作原型在这方面也非常有帮助。我们会在原型中实现动画效果，然后反复触发，直到看吐为止。（受虐狂啊，我懂。）用户更容易领会，并提出必要的问题。其中许多最终都被废弃了，或者速度加快了。我们使用Origami还有新宠Principle来模拟动画效果。用Principle来制作接近原生应用的交互式原型简直轻而易举。录屏和分享也易如反掌。
这是一个被废弃的锁屏概念动画，因为动画时间太长，它阻碍了交互流程。
制作原型的额外收获，就是我们团队可以在进入开发阶段之前，就着手准备市场推广材料和视频。
一段预览引导视频在开发之前就准备好了。
早期的方案倾向于明亮温暖的色彩。
视觉
出于某些原因，人们都相信面向商户的产品都很丑陋，我们想要改变现状。无论面向商户还是面向客户，我们都致力于尽可能使它在美学上令人愉悦。毕竟，任何用户都需要时时看着界面。我们都不希望优秀的产品以不尽人意的外观呈现，那会给人一种草率的感觉。谁是用户，并不相干。
UI流程确定下来后，我们探索了许多视觉方案。多数早期方案都鲜明大胆，有些也相对柔和。我们从中选择最好的创意，然后挑选某个折衷的方案。我们希望营造自信与友善的感觉，但不要过于嬉戏。鲜明的色彩保留下来了，使用上却不会过于放任。
统一性
我们先选出少数界面进行设计，作为剩余界面的参考。我们创造了一套粗略的风格指南，来描述各种元素的构成、摆放，还有字体、阴影、主操作项等等。而且，它还包含一套标准配色和通用图标集。
目标之一，就是培育出一系列产品，一眼就清晰可辨出自我们之手。在统一性与自由创造之间寻找平衡尤其困难。各平台限制条件各不相同，决定品牌如何展现，也是一项挑战。这是一段不断试错的学习经历。
我们所有的产品都有着相同的设计哲学。
我们后续还讨论加入了更多内容。就在我们完成改版之时，风格指南已经变得丰富了许多。这套指南会继续演化，在各种平台塑造我们其他产品的整体形象。
设计回顾
我们有一项非正式的日常设计“批评会”。我们通常不去会议室在墙上写写画画、展开讨论。但整个团队了解，我们是在批判作品本身，而不是它的设计者。不过当你的作品被批评时，难以完全剥离自己的感受，不为此感到泄气。所以我们才尽可能使整个过程舒适。我们在任何时候都会把不确定的事情拿出来分享。我们从来不发邀请函，或是为此专门找时间和场地。不由自主的天性会鼓励我们自由开放地交谈。这些交谈只有一条原则——“别得罪人”。
协作都是自发且非正式的。
可用性测试
把问题归咎于用户，对他们拒绝新事物感到忿忿不平很容易；专心聆听，从他们的角度看问题却难很多。
我们刚开始和每次测试版更新前，都会进行可用性测试。最普遍的反馈确实让人很震惊。人们天生就害怕改变，有时这会阻碍我们做出任何显著的改进。责任便落到我们肩上，告诉他们哪里有变化，为什么要改，如何才能尽可能无阻碍地切换到新版本。把问题归咎于用户，对他们拒绝新事物感到忿忿不平很容易；专心聆听，从他们的角度看问题却难很多。我们必须确保这种彻底的改变是有意义的。
最有价值的反馈来自测试版。所幸少数商家很有耐心，愿意当小白鼠，允许我们观察他们如何操作。真实的测试最残酷，却也最深刻。无需多言，有些看似精妙绝伦的创意，直接被打回来了。
在每项任务中，我们通常会向开发者提供用户流程图和标准UI组件指南。
执行
执行阶段不像部分人想象地那么简单。并非输出资源图片、准备好文档就完事了。在整个过程中，设计团队都与开发团队一起进行，也深度介入内部测试与品质保证工作。工程师们在构想我们希望的小细节上非常有帮助。他们需要思考真实的执行方案，提出技术问题，例如“如果没有获取到隐私权限怎么办？”还有“如果网络连接断断续续呢？”文档总是片面的。要产出我们想要的一切，沟通至关重要。
即便如此，也没有人喜欢每隔5分钟频繁提问/回答。与界面相关的每一个人都有一份Sketch源文件。开发者喜欢在里面查看你漏标的CSS属性、坐标、尺寸、距离、还有那些16位颜色值。
许多精力都花在让操作更加“迅捷”上。有个功能是让雇员上下班时用前置摄像头拍照打卡。在早期版本中，用户在锁屏之前，要等待照片上传到服务器。现在，我们会在后台上传照片，用户不必再盯着旋转动画看10秒钟了。
迭代
设计是一个迭代的过程。每次我听到有人对一个产品草率下结论，不尊重它背后的努力时，我就感到心痛。在我的观念中，设计的真正价值不是由最终产品决定的，而是我们倾注其中的所有心血——也包括那些不称职的设计师的。迅捷的反应，需要相当传奇的设计团队。
3.0版更新现在正处于最后的开发阶段中。很自然地，我们已经在进行下个版本的工作了。在产品发布前，设计工作都不算完成。我们持续收到反馈，做出相应调整与改善。无论复杂与否，解决问题都需要耐心。
设计产品的方式并非千篇一律。坚定、专注的策略很好，但它未必对每个人都有效。我们对这个项目的变化欣喜若狂，等不及让我们的客户用起来了。
关注我的Twitter和Dribbble了解我更多的设计想法吧！:)
感谢我亲爱的同事Nicole和Jillian校对这篇文章。
原文链接：https://medium.com/user-experience-design-1/when-simplicity-isn-t-the-answer-designing-for-vastly-different-audiences-aba2
