第 3 章 准确高效地实现!UI 设计的技巧

第 3 章 准确高效地实现!UI 设计的技巧——Cookpad 首页的设计过程

文 / 须藤耕平 (SUDO kohei)  Cookpad 股份有限公司 mail sudo@cookpad.com Twitter @sudokohey
译 / 卫昊

上一章我们就“为谁开发什么”这一主题,介绍了用户体验设计的方法。本章以 Cookpad 首页的重新设计为例,主要介绍在实现用户体验设计阶段定义的用户目标时,我们应该以何种方式向用户传达哪些内容等关于设计实现方面的技巧。

为了在最短的时间内实现可用原型

大规模开发时无法立刻完成原型制作

尽早实现最初的可用原型并实际对其进行测试、取得反馈并修改,这是在进行 UI 设计时最可靠的方法。

笔者在添加单一功能或者开发极小规模页面时,能够毫无怨言地不停编写代码,但是在开发新的、规模较大的服务或者站点时就不可能也是如此了。当我们所开发产品的规模较大时,实现硬件设施的时间、参与的员工数、意见的数量一般也会有所增加。

重新设计 Cookpad 首页的项目也不例外。访问 Cookpad 首页的用户,都有着许许多多不同的目标,他们都希望网站可以满足自己的各种需求。而提供服务的我们,又想赋予这种功能,又想赋予那种印象,也会有各种不同的想法。即便使用上一章介绍的人物角色、编写脚本等方法,或者运用其他框架可以让大家保持开发方向一致,可令人意外的是,在具体落实 UI 设计之前,或者说在实际设计工作开始之前,UI 在大家脑海中的印象仍都是各不相同的。

在这种情况下,为了能尽早统一大家的印象,缩短制作最初可用原型所需的时间,怎么办才比较好呢?

图 1 Cookpad2012 年 11 月版本的首页

制作介于线框图和综合设计之间的模板

  • 线框图和综合设计的问题

    服务开发的一般流程是:由策划人员提出线框图,设计师据此制作出详细的综合设计,然后交给工程师去实现,在实现到一定程度后就进行最初的评价工作。当然在综合设计阶段也可以进行个别内容的评价,但是这时被提出的往往是“这里的颜色浓一点会不会好些?”“按钮再稍微大一些怎么样?”等评价人员对产品外观的主观意见。这些与参照前期假设来解决问题等本质内容无关的讨论,往往会浪费许多时间。

    本来是为了避免这种状况,我们才制作线框图的,但现实却未能如愿。很多人将线框图看作是粗略的框架,或者是为了可视化设计而设计的草图。而且,不从事开发的最终决策者仅看原型的话,他也很难想象出最终设计的 UI 是什么样子的。

  • 制作模板

    为了解决这个问题,我会首先制作介于线框图和综合设计之间的模板,其诀窍就是制作单色模板。单色模板最多只可以使用 5 种层次的颜色来承载不同的信息,因此不用考虑跳跃率、图版率等多余的装饰,对于仅需要设计出大体框架来说,这种模板是非常实用的。

    顺便说一下,在这个阶段虽然并不需要追求设计细节的完成度,但是因为需要通过实际去观看、阅读来进行评价,所以关于图像和文本,我们应该尽可能使用实际的数据,而不是留空它们,而且要尽量使用值得反复讨论的数据。如果不这么做的话,留空的部分每个人会擅自地去填补它们,从而导致该部分产生不同的含义。

    评价人员一同观察这个临时的状态,仅仅把要将何种要素、以何种程度、布置到哪个位置和表现出何种印象作为评价的对象,那么讨论的重心自然会放在它能否达成设计好的用户体验上。

    另外,模板在从开发小组以外的人获得反馈时也会发挥很好的效果。人们对下了一定工夫制作的原型,往往会下意识地回避负面的反馈,只有在模板阶段既能够在整体上有所提高,又能够正确收到信息,这正是获得高质量反馈的大好机会,错过就可惜了。

    这种制作中间模板的方法,不需要太在意外观,也不需要实际实现的技术,所以没有必要在一开始就指派很多员工,也可以在较短的时间内完成模板。这个可以缩短最初可用原型制作时间的技巧,请大家务必要尝试一下。

图 2 制作单色模板

不遗漏也不重复的画面构成

这部分说明一下关于制作单色模板的具体问题。

大多数的情况下,我们通过页头和页脚、主栏和侧栏等多个部分的组合来构成一个页面,而构成页面的关键点就是要明确各个部分的职责。

构建商场的入口

Cookpad 这次重新设计的首页将主栏分为四个职责(图 3)。

图 3 将页面构成划分为 4 个区域

  • 招牌

    如果将 Cookpad 网站的首页看作是商场的入口,那么最重要的事情就是传达出我们以何种商品作为中心,也就是说需要招牌这类的区域。所以,首先要布置的就是每天在这个区域刊登由工作人员挑出的精选食谱。

  • 展示窗

    然后,还需要有一个与新商品展示窗功能类似的区域。因为这里更新频率也很高,所以把这部分和看板并排,作为首屏。

  • 指引牌

    接着是经过商场入口一定会看到的东西,那就是各楼层的指引牌。为了直截明了地展现 出 Cookpad 有哪些种类的食谱(也考虑到那些不习惯使用搜索的用户),我们选择最主要的类别,将它们以列表的形式布置。

  • 各楼层的推荐商品

    最后剩下的中央区域集合了各个卖场的推荐商品。由于这里的面积比较大,所以把它们按照“寻找食谱”“购买食材”和“学习制作料理”这些目的进行了细分。

像这样根据各区域的职责来考虑页面的构成,可以使内容的整合更加容易。将广告分散穿插在内容中的网站不在少数,可是为了用户着想,还是将它们安排在一个地方比较好。Cookpad 所有的页面都将广告集中到了右栏中。

标签的注意点

即使在制作模板的阶段,各个内容的标题和描述文本也是非常重要的部分。不要采用线框图中直接写着“文本内容”这种临时占位的处理方式,而是应该仔细斟酌后进行选择。这部分的关键点是保持简洁以及避免重复。

  • 简洁表达

    Windows 的用户体验(UX)设计指南中记述了如下内容。

    在打印设计时,我们要将执行最重要任务的元素标为重点,也可以进一步将 UI 文本内传递有用信息的个别单词标为重点。然后确定非重点元素,讨论是否可以从设计中删除它们。如果没有什么问题,就将它们删除。

    ——_Power and Simple_

    http://msdn.microsoft.com/ja-jp/library/windows/desktop/aa511332.aspx

    实际尝试后会发现,即使删除了也没有什么问题的文本出奇得多。减少单词量,使用“○○ 的 ××”这样两个词语就足够表达的情况也不在少数。

  • 避免重复

    像用于标题含义的“话题”“特集”“推荐”这种形式不同但意义差不多的词语如果频繁出现,很有可能是由于各区域的职责不够明确。这时开发人员应该讨论一下页面构成,看看能不能再进行一次总结。

  • 避免特有的措辞

    除非有特定的用户群或者特殊的目的,一般来说网站中应该避免使用特有的单词或表达方式。在 Cookpad 中有一个功能,可以给食谱作者发送一个名叫“值得一做”(就是很好吃、点赞的意思)的反馈。对于初次造访 Cookpad 的用户来说,理解“值得一做”这个文本的意思并不那么容易。

    特别是在首页用词的选择上,开发人员需要格外地慎重。

可以直观理解的格式设计

接下来让我们一起探讨一下在各个区域中,应该以什么样的元素组合成格式来表现相应的信息。

相邻的区域使用不同的格式

这部分的关键点是相邻的区域要使用不同的格式。例如,“精选食谱”区域使用了大图表示,那么它右侧的“最新内容”区域就不使用图片,而是以列表形式的文本来表示。因为最右侧是矩形的广告区域,使用列表将两张大图分开,既可以消除两张图片因为过近而造成的视觉冲突,也可以让每个区域都更容易被用户看到。

在整体页面中,为了不让图片和图片之间、列表和列表之间过于接近,我们可以将标题栏作为分割线使用,或者在区域之间的距离上下一番工夫,总之要尽量让各个元素都可以独立展现。

其实本来就没有明确规定某个信息应该以怎样的格式展现,但是参考上面这些技巧也不失为一个好的选择。

图 4 不要让图片和图片互相接触

照片和插图分开使用

Cookpad 上有许多用户上传的、美味料理的照片。为了展现视觉上的华丽,很多人就会想以缩略图的形式大量布置它们,但实际上我们不应该这么做。缩略图本来是为了预览所链接的内容,或者为了吸引用户目光而存在的。但是缩小到 50 像素的料理照片,甚至没法让人看清这到底是什么料理,过多使用的话很可能直接就被用户无视了(图 5)。

{%}

图 5 缩略图不等于“速度”和“节约”

在菜单分类的这个地方我们使用了信息量较少的插图或图标(图 6)。对比一下缩略图和插图,大家可以发现,实际上插图要比缩略图直观得多。

{%}

图 6 使用插图“储蓄罐”“计时器”直观展现

特别是在照片较多的首屏部分,大图的使用最多不要超过 3 张 1

1在刊登广告的站点上则应该是 2 张。

考虑到触摸式设备

在这个阶段,我们也应该考虑触摸式设备的问题。由于使用触摸式设备时,用户点击较小的文本链接会很困难,所以在 Cookpad 首页中,各元素的区块整体都是可点击的部分。

用户在用鼠标点击各区块时,主要的文本会附加下划线,缩略图会添加些许高亮等,在这种能提高交互性的细节上我们也下足了工夫。当然也可以在编程的阶段进行这些 UI 的细节处理,但如果开发人员能事先有所考虑的话,后面的阶段就可以节省很多时间、做更多的事。

在修正产品的同时注意细节

经过以单色模板为基础进行的本质问题讨论,小组成员建立了对 UI 的共同印象,在这之后就可以进入实现的阶段了。

视觉设计和编程同时进行

以我的经验,实现时能够根据需要,把可以使用 Photoshop 设计细节元素的人当作原型开发的主力,并同步进行服务端的编程是最理想的状态。为了能近乎实时地修正与用户最终使用的 UI 无限接近的产品,开发人员需要和能够提供客观意见的人结对编程。

在开发的基础部分,多少都会有一些需要复杂逻辑的地方,这些地方要依靠专业的工程师以库的形式来编排。在这种分工下,如果他还可以承担一点包括设计部分细微修正在内的修改任务,那么产品的完善周期将会大为缩短。在现实中的大部分情况下,视觉设计和编程是完全分工进行的,但即使是这样也需要制定不必等待对方任务完成也可以同时行动的工作流程。

Cookpad 在几年前并没有专业的设计师,负责产品开发的工程师同时负责 UI 设计工作的情况也不在少数。这种方式的弊端是很难保持服务整体中 UI 的一致性,但是却可以高效开发产品,大大缩短产品到达可公开状态的时间。

不过现在引入提供统一 UI 组件的框架,也可能同时满足一致性和高效开发两个要求。

灵活使用 Pull Request,提前记录有问题的事项并将其解决

作为开发人员记录并解决自身专业以外事项的一种手段,Cookpad 将 GitHub Enterprise 的代码审阅引入到了流程中。

  • 进行了设计上(外观)的修改时,贴出变更前后的截图(图 7),请求设计小组来进行审阅

{%}

图 7 在 Pull Request 概要中贴出截图

  • 进行了可能对性能有所影响的修改时,例如添加了全体页面都要使用到的功能等,则请求专门的员工进行审阅

决定了这些简单的规则后,我们会发现这样可以极大地减少服务公开后,看到错误日志才发现的问题。

而且,如果在编写代码时就去进行审阅,开发人员可以尽早地发现设计师完全没有设想到的、需要再添加进去的功能。类似这样的优点还有很多,所以我十分推荐这种做法。

根据公司员工的试用不断改善

最初可用原型准备完成后,就去邀请尽可 能多的人来使用吧。无论是自我感觉设计地多么好的产品,在实际使用时,通过在显示器上显示、移动鼠标、点击等操作还是会发现许多之前从未注意到的问题。

在 Cookpad,我们使用自主开发的名叫 Chanko 的库,将开发中的原型作为正式的网站部署,员工可以轻松地作为用户试用。使用 Chanko 在公司内公开的原型,会覆盖原有的功能,也就是说部署之后,公司的全体员工几乎都会强制性地看到新上线的功能。这就和用户习惯了旧版界面,但某一天突然发现这个界面更新地面目全非时一样。当然,根据原型内容的不同,我们也无法排除会发生员工业务受阻的可能。

仅在这点上,内部的公开就需要和正式上线时同样慎重。但更重要的是,在这个阶段无论是好还是坏,都要尽可能多地取得反馈,讨论并改善它们,看看在正式上线时,到底可以让质量提高到何种程度。实际上,开发人员在正式公开后也仍然会立即地、持续地重复这个步骤,所以趁着修改所带来的影响仅限在公司内部的这个时候,偶尔特意去尝试一下大胆的措施也是一个不错的选择。

至少听取 5 个人的意见

在不能使用 Chanko 这样的验证工具时,开发人员应该至少选取 5 名与目标用户相近的员工,从他们那获取反馈。经过这 5 个人的测试后,应该改善的大部分问题一般都可以被发现。带着可以正常使用原型的一台笔记本电脑,到 5 位员工的桌上就能进行测试,所以在构建测试环境比较艰难的时候,请大家一定要这样尝试一下。

其他影响提高用户体验的因素

速度是最重要的功能

Fred Wilson 在演讲中曾经说过这样的话 2

210 Golden Principles of Successful Web Apps http://www.avc.com/a_vc/2010/03/10-golden-principles-of-successful-web-apps.html

速度不只是“功能”,而且是“最重要的功能”。没有人会使用反应迟钝的应用。

大家谁没有过这种经验呢?无论怎样以用户的角度设计体验,为了实现这些体验反复精炼 UI,结果却因为回应速度过慢,导致产品完全没有办法使用。正如上面引用的话所说,我认为速度是胜过一切优秀功能的优势。例如,一个可以将许多食谱分类保存,任何时候都可以搜索的功能,响应速度却十分缓慢的话,会怎么样呢?用户本来很期待保存食谱之后能够随意搜索,但因为响应速度过于缓慢,就会觉得自己之前保存时花费的时间也白白浪费了,从而失去了对服务的信赖。用户对服务的信赖十分重要,一旦用户认为某服务“无法使用”,想让用户再次去使用该服务则是一件极其困难的事情。在开发服务时,这种非外观上的、性能上的问题,我们也要十分注意才行。

使用测试代码保证用户体验

有时会发生因为用户输入不准确或者访问了不存在的 URL 导致即使程序正确运行,用户也无法得到预期结果的情况。这种情况下,把原因反馈给用户并确保用户下次可以进行正确的操作,也是设计师的工作之一。使用测试代码保证常规行动是毋庸置疑的,但是当用户进入非常规流程时,为了避免上述情况的发生,测试代码就需要保证能够和用户进行恰当的交流。

这里的关键点是要站在用户的角度,思考如何能够帮助用户回到正常的操作流程,并为此准备相应的测试代码。这样,用户体验自身就得到了程序上的基本保证,设计师也可以更加放心。

总结

从模板设计、实现到通过公司内部验证不断改善的方法,上文配合实例尽可能地介绍了一些实践性的内容。虽然我经常一个人执行所有的步骤,但正常来说在大多数公司,采取的都是分工的方式。这种情况下,小组成员应该认真明确各步骤的目标并建立成员对 UI 的共同印象,适当使用本章介绍的内容,尽量缩短从项目开始到产品初次发布所需要的时间。

服务正式公开后,等待着我们的是验证假设、不断改善这一永无止境的循环。下一章我们将介绍验证假设的具体方法。

目录

  • 版权声明
  • 编委会
  • 分栏目录
  • 编委点评
  • 第 3 回 扁平化设计
  • 特辑 1 UI 设计实践
  • 第 1 章 开发人员所追求的 UI 设计
  • 第 2 章 为了 UI 设计而进行的用户体验设计
  • 第 3 章 准确高效地实现!UI 设计的技巧
  • 第 4 章 提高 UI 设计成果的验证技巧
  • 第 5 章 为多元化环境提供相应的 UI 设计
  • 特辑 2 Web 支付入门
  • 第 1 章 支付的基础知识
  • 第 2 章 信用卡的基础知识
  • 第 3 章 信用卡支付的信息安全
  • 第 4 章 实现 PayPal 支付
  • 第 5 章 实现 WebPay 支付
  • 第 6 章 实现在 iOS/Android 应用内支付
  • 特辑 3 “边做边学”数据可视化
  • 第 1 章 数据可视化的基础知识
  • 第 2 章 D3.js 的导入和设定
  • 第 3 章 实现地理数据可视化的方法
  • 第 4 章 实现人际关系数据可视化的方法
  • 特约文章 Gradle 让构建更高效
  • 第 3 回 Android Studio 速评 !
  • 第 3 回 使用 serverspec 构建测试驱动基础设施架构
  • 第 22 回 如何开发使用 Coro 的简易网络爬行器
  • 第 8 回 从 Go !开始的 AOP
  • 第 9 回 抢先看 Web Components
  • 第 8 回 使用 RDBMS 顺利处理图的方法
  • 第 8 回 数据缓存性能设计的要点
  • 第 8 回 使用 Fluentd + FnordMetric 进行实时数据可视化
  • 第 17 回 从 Pecolodge 来看 HTML5+Canvas 的开发要点
  • 图灵访谈 赵望野:前端工程师的困惑