简洁行不通了——为截然不同的用户而设计

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版更新现在正处于最后的开发阶段中。很自然地,我们已经在进行下个版本的工作了。在产品发布前,设计工作都不算完成。我们持续收到反馈,做出相应调整与改善。无论复杂与否,解决问题都需要耐心。

设计产品的方式并非千篇一律。坚定、专注的策略很好,但它未必对每个人都有效。我们对这个项目的变化欣喜若狂,等不及让我们的客户用起来了。

关注我的TwitterDribbble了解我更多的设计想法吧!:)

感谢我亲爱的同事Nicole和Jillian校对这篇文章。

1 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部