第 1 章 开发人员所追求的 UI 设计

第 1 章 开发人员所追求的 UI 设计——明确为用户提供的目标

文 / 五十岚启人(IGARASHI Hiroto) Cookpad 股份有限公司
译 / 卫昊

本特集主要通过 Cookpad 公司的设计师们常用的 UI 设计方法,讲解一些设计师和开发人员必须了解的基础知识。

作为特辑的开篇,本章将介绍开发人员对待 UI 设计应该持有的态度,即开发人员为了使自己开发的服务获得成功,应该如何理解 UI 设计,以及作为一名开发人员,UI 设计能使自己得到怎样的成长。

UI 设计的目的

UI 是你开发的服务与用户之间的连接点。用户通过 UI 使用你的服务,评价你的服务。而 UI 设计就是设计服务与用户之间的关系,这是一个非常有意义的过程。

说到 UI 设计,大家可能会联想到绚丽多彩、富有魅力的图形图像。图形图像固然可以提高用户对服务的印象分,使用户更加愉悦地使用我们的服务。但是,图形图像只不过是 UI 设计中的一部分,即便没有这方面的专业技巧也完全可以设计出漂亮的 UI。

实际上,UI 设计最重要的目的是:使用户认识到自己通过服务能达成什么目标,并指引用户以正确的方式使用服务所提供的功能来顺利达成这些目标。为此,我们不仅要针对用户操作的画面进行设计,还必须要从用户的整体体验出发进行 UI 设计。

开发人员必须 了解的基础知识

在我所效力的 Cookpad 公司,开发人员都被称为“造物者”,受到别人的尊敬。除了开发产品,我们还要深入思考这些产品能使用户获得何种价值和体验。

这是因为一个无法明确用户能获得何种价值的服务,最终在商业上也会变得毫无价值,而且浪费开发以及 UI 设计的资源。

设计用户通过服务可以获得的价值

那么,就用实例来确认一下 UI 设计和服务价值之间的关系吧。

Cookpad 一般被认为是一种“寻找食谱的服务”,但这并不是用户通过 Cookpad 可以获得的最本质上的价值。“寻找食谱”不过是 Cookpad 上的功能之一,其本质上想向用户提供的价值则是“发现今天想吃的东西”。

比如从搜索功能上也能看出这点。除了 Cookpad 以外,在搜索引擎上寻找食谱也是可以的。但是,Cookpad 的搜索功能想提供的从来不仅仅是寻找食谱,而是找到今天想吃的东西这一价值,我们需要以此为目标来进行 UI 设计。

在开发服务时,理解自己开发的服务要向用户提供何种价值是十分重要的。能否在此基础上进行 UI 设计,是决定 UI 优劣的关键性因素。

在平时就去体验各式各样的服务

那么我们到底该如何通过服务向用户提供最好的体验和 UI 设计呢?

对开发人员和设计师来说十分重要的一点是:在平时就去体验和了解由不同人提供的、各式各样的服务。这样自己在进行设计时,就可以选择同样的手法。

  • 体验其他 Web 服务提供的用户体验

    对开发人员来说,体验和自己所要开发的服务相似的,或者自己感兴趣的各种服务和应用程序是唾手可得的事情。开发人员可以先列出一张清单,上面写上与自己想要开发的服务、在工作中正在开发的服务相似的数十个服务,然后分别使用、学习。

  • 体验现实世界中的各种服务

    可能的话,体验现实中世界各地的、由不同的人提供的各种服务,对提高自己所开发服务的品质一定有着很大的帮助。

    例如,著名的设计公司 IDEO 为了再次设计医院急诊室的工作流程,就去观察美国有名的纳斯卡赛车(NASCAR),并从赛车修理站获得了灵感 1。乍一看二者毫无关系,但运送至急诊室的急救病人和进入修理站的车手一样,都是为了恢复正常,而变成了“任人摆布的状态”,在这一点上他们有着很相似的体验。

  • 体验各种事物时需要注意的事项

    在体验其他人下工夫开发的服务或 UI 设计时,我们需要意识到下面两个问题,这样才能够更加深刻地体会到对方的用心良苦,然后带着尊敬去“盗用”对方的成果。

    • 注意好的地方,而不是差的地方。

    • 发现并观察与自己性质不同的地方,而不是相同的地方。

    世界上有许多人在精心打造并努力提升服务的品质。让我们体验不同的服务,总结它们的特点并好好领会其中的精华吧。随着经验的积累,你也会变得更加注重用户的体验。

1在 Diamond Online 的报道“仅拥有 600 名员工,却和苹果、谷歌并肩的世界上最具革新性的公司——IDEO 的思考方式”中提到过这件事。http://diamond.jp/articles/-/36808?page=3

如何明确为用户提供的目标

前一节叙述了在进行 UI 设计前,我们必须明确所开发的服务向用户提供何种价值。下面将讲解从整理服务的价值到进行 UI 设计前的这个阶段。

制作产品定义文档

在头脑中确定了服务应向用户提供的价值之后,为了明确服务的目标,我们还要将其落实成“产品定义文档”。

产品定义文档是非常有力的工具,它能与一起开发服务的伙伴共享目标,或让自己在一人开发时不偏离服务的方向。

产品定义文档只要包含下面的要素,以何种形式书写都没有关系。

  • 什么样的人使用这项服务?

  • 用户使用这项服务是为了解决何种问题?

产品定义文档根据人和团队的不同,有着各式各样的叫法、书写方式以及定义方法,下面介绍几个 Cookpad 使用的框架方法。

Emotion Oriented Goal Sheet(EOGS)

这是在 Cookpad 使用时间最长的一个框架。我们会列出主要的利益关系者,以他们的根本需求作为出发点,找出他们的共同目的,制定服务目标。因为拥有明确判断何为成功的标准,同时能够提供数字上的参考,所以这种框架在商业上也可以使用(图 1)。

图 1 EOGS 的例子

根据用户故事定义服务

这是在开发较小规模的服务或添加新功能时可以使用的框架。这个框架不以“能够寻找食谱”这种功能性的描述来定义服务,而是采用“互联网用户每日为吃饭烦恼时,能够决定想吃的东西并知道如何制作”这种形式,制作以解决用户问题为核心的用户故事模板(图 2)。

图 2 使用用户故事表的例子

价值假说

价值假说和❷很相似,但是更加关注用户遇到的问题。如图 3 中的模板所示,这个框架从用户的角度来定义服务的价值。

图 3 使用价值假说表的例子(按人气搜索食谱)

Goal Directed Design

这是通过创建虚拟的人物角色,并归纳这个虚拟用户的各种情感来定义产品的方法。这个方法将在第 2 章中以实例进行详细的讲解。

  • 苹果和微软推荐的方法

    在 Cookpad 公司内部,不同的服务规模和不同的团队都会有各种不同的框架方法,那么不同的企业当然也会有各种各样的方法。例如苹果和微软发布的文档中就推荐了如表 1 所示的方法。

    表 1 其他定义方法

    事例URL
    苹果提出的公司内部应用程序开发的例子http://www.apple.com/jp/business/accelerator/plan/define-your-app.html
    微软提出的 Windows 商店应用开发的例子http://msdn.microsoft.com/zh-cn/library/windows/apps/hh465427

    要想检验这些框架方法是否好用,将一个已经成功的服务或产品代入它们来一一验证也许是个不错的选择。

  • 修改产品定义文档

    产品定义文档的内容根据服务的状态和阶段会发生很大的变化。Cookpad 最初也不是把“决定每天该吃什么”作为核心的服务目标,而是以“能够轻松刊登食谱”作为其核心价值。

    为此,Cookpad 十分重视以传统地刊登食谱为目标的用户 UI 设计。不过也正是因为 Cookpad 在服务初期明确的这一核心价值,现在才有可能收集到如此之多的食谱吧。

撰写达成目标的脚本

明确了向用户提供的价值之后,我们还要为了确保用户可以顺利到达服务的“终点”(即使用服务达成某种目标)而进行架构设计。

  • 导致用户“迷路”的原因

    主要有两个因素会导致用户在前进时“迷路”。

    ❶ 无法认识到该以怎样的步骤达成目标,无法理解步骤间的关联性

    ❷ 个别步骤无法如愿以偿地使用

    UI 设计的主战场在第 2 个因素上,但如果因素 1 有理论上的破绽,那么无论在因素 2 上下了多大的工夫,也不会提升用户对服务的评价。以公交车为例,最近,电子票的引入使得我们在坐公交车时付钱买票变得非常简单。但是,根据地域的不同,有着前门上车、后门上车、上车付钱、下车付钱等各种方式,乘客必须在公交车到达的一瞬间,根据车体的外形区别、判断它们。公交车原本是达成“移动到别的地方”这一目标的手段,结果却给使用者带去迷惑和不安,让他们犹豫是否还要使用这个手段。

  • 撰写脚本的步骤

    为了让用户可以顺利到达服务的“终点”,让我们来撰写一个脚本范例,描述服务的使用步骤。

    • 将条目列在纸上

    • 在纸上画出简单的画面迁移图

    以刚才的公交车为例,按照共同的目标,将用户划分为等车、乘车等阶段,并列在纸上。讨论一下每个步骤中哪些事情是必要的,步骤的顺序是否难以明白,然后在纸上画出简单的模型。这个方法有很多具体做法,在第 2 章中将配合实例进行讲解。

    可能的话,我们还要与他人交换意见,按照之前定义的“产品定义文档”编写脚本,然后再进行各步骤的 UI 设计,并且为了用户可以如愿以偿地完成各个步骤而进行相应的调整。

提供具有一致性的 UI 设计

前面讲述了实际进行 UI 设计需要的各种前提和准备。具体的 UI 设计方法和技术将在第 3~5 章中介绍,但它们都以如下几条内容作为基础。

为了用户不会迷失目标而进行 UI 设计

要想让用户可以使用服务达成目标,排除途中会迷惑用户的因素是十分必要的。为了使用户不会受达成目标以外的因素影响,进行 UI 设计时常常需要确认如下内容。

  • 服务是否与操作系统的标准 UI,或者与提供相似价值的知名服务的 UI 相似,用户能否凭借已有经验直接使用我们的服务

  • 是否统一了服务中图标与文本的显示和使用方法,是否可以预测用户使用 UI 的结果

向 UI 设计中增加新内容时,最需要注意的就是设计的一致性。没有一致性的 UI 设计会导致用户陷入混乱,注意力被分散。

而且,我们也需要慎重考虑用户是否真的需要这个 UI 或功能。开发人员经常会自作主张地添加一些不必要的功能和信息。总之,我们要慎重考虑新添加的 UI 或功能能否对用户达成目标提供帮助,仅仅保留绝对不能缺少的内容才会提高我们服务的品质。

使用用户可以理解的语言

UI 设计中开发人员很容易将重点放到图形和布局设计上,但是配合 UI 使用的语言也需要十分注意,特别是如下几点。

  • 一致性的书写和表达方式

  • 使用用户立场的语言(例如:加入会员需收费→加入会员需要交纳手续费)

  • 使用服务对象(即用户)熟悉的语言

99% 的引用和 1% 的原创

有时我们在开发新的服务时,会精心设计并准备新服务专用的 UI,而这正是最需要我们慎重的时候。

旧的 UI 经过长时间的使用,积累了各种知识和用户的反馈,是用户体验的宝库。学习和再利用这些经验,可以防止开发人员“重新发明轮子”,从而有效率地进行 UI 设计。参考类似的作品,你的服务中有 99% 的部分可以再利用已经存在的 UI,最后再加上 1% 精心设计的、具有你自己服务特征的 UI 就可以了。在 UI 设计上,引用成功者的成果并不是一件可耻的事。

学习各操作系统的设计指南

各个操作系统都会向开发人员提供一套标准的 UI 组件,让他们在开发服务时可以重复利用。而且,各个平台都会将各自 UI 组件的使用方法整合为“设计指南”并公开,开发人员可以从中学习到各个操作系统的 UI 设计模式以及“文化和理念”(Tone and Manner)。

具有代表性的设计指南如表 2 所示。在 Web 上搜索它们后就可以免费阅读。这些指南毫不吝啬地公开了各公司的顶级设计秘籍,我建议各位读者务必浏览一下。在和其他设计师、开发人员一同进行开发时,学习过各个操作系统中 UI 组件的名称,还可以使相互间的沟通变得更加简单。

表 2 具有代表性的设计指南

名称

URL

iOS Human Interface Guidelines

http://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/

OS X Human Interface Guidelines

https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html#//apple_ref/doc/uid/TP30000894-TP6

Android Design

http://developer.android.com/design/index.html

Windows 商店应用程序的 UX 指南

http://msdn.microsoft.com/zh-cn/library/windows/apps/hh465424.aspx

Windows 用户体验交互指南

http://msdn.microsoft.com/zh-cn/library/aa511258.aspx

而且,在进行非各操作系统原生应用程序的 Web 开发时,通过学习各操作系统的理念,吸收各个操作系统的优点,我们就可以设计出不针对特定操作系统用户的通用性的设计。

总结

对于想尽早开始 UI 设计的读者来说,本文到现在为止似乎都在“绕远路”。可是,开发人员应该抑制自己急于开始设计的心情,首先从自己开发的服务着眼,认真思考、整理,这才是使 UI 设计成功的最为重要的一点。

既然 UI 设计前需要做的准备都已经完成了,下一章我们将配合实例解说 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 的开发要点
  • 图灵访谈 赵望野:前端工程师的困惑