“UX”(用户体验)设计师是科技行业中最不被人理解的角色之一,很可能是因为在5、6年前这个角色还不存在。对于这个角色的混淆是由于它与UI(用户界面)设计器合并进而得到了压缩,尽管它们是不同的东西(也有许多重叠的职责)。这就是为什么我决定研究用户体验设计师从产生想法到创造原型的整个过程。
这里有一个方案:
假设你是一家公司雇佣的、唯一的用户体验设计师,这家公司想要创建一个你一无所知的全新应用程序。这家公司已经很好地建立起来,而且你也是一个全能人才,所以不要担心资源的缺乏(比如,如果你需要时间/金钱,他们会给你的)。
项目启动后不久,你将与整个团队合作,以便成功地开发应用程序。你可能想知道的一些问题是:你需要从哪里开始?你需要了解什么?为了让他们的开发者开始开发这个应用程序,你需要采取哪些步骤?
01
「 前期规划 」
首先……你需要了解公司想要解决的问题,通常会和客户开会,了解他们的业务,了解他们要你设计的产品有什么需求。
阶段1:调研
访谈前准备
与客户进行面谈可能只需要几个小时,甚至几天(取决于范围),但这并不意味着你需要在一个房间里和你的客户呆上6个小时直到你的问题得到回答。例如,可能需要对团队中的几个关键成员进行半小时的面谈,一次一个人。然而,在你去面试之前,自己做一些调查是合理的,这通常会得到客户的赞赏(因为这意味着你不会浪费他们的时间,而且在与他们交谈之前,你已经对公司有了更深入的了解)。
初步研究可能包括:
业务文件(使命陈述、战略文件、组织结构图等)
他们做过的任何研究(市场/用户研究,竞争对手分析等)
客户最近的年度报告
目前正在使用的广告示例
访谈
在面谈中,事先了解以上几点可以帮助你识别客户的书面文件和口头回答之间的差异(如果存在的话)。为了产生最有效的影响,你不想用大量的问题轰炸他们,最好对几个主要领域进行一个相对轻松的讨论。提前告诉他们你要问的问题,这样他们就能准备得更充分(也更舒适)。
在这个过程的最后,你应该得出一些重点,例如:
- 客户试图解决的问题
- KPI(关键性能指标)——这可以帮助您了解产品中最重要的特性
- 目标市场——这可能是有限的/基本的信息(你以后的工作将是更多地了解你的客户他们的潜在用户)
- 竞争对手是谁?客户有何不同/改善
- 客户的品牌价值
现在不是讨论应用程序的特性、功能或内容的时候,你需要了解客户的文化、目标和挑战。为了理解上面列出的要点,你需要尽可能多地进行面谈(例如,大约5-10点)。
阶段2:建立用户画像
集合、分析研究
基于你收集到的关于客户市场、竞争对手和潜在用户的数据,应该花些时间研究你了解到的信息,以确定什么样的人可能会使用这个产品。
例如,如果你的客户正打算在健身和营养领域创建一种新型的移动应用程序,他们可能有一个很好的想法,但没有很多关于潜在用户的信息。但是,如果他们的竞争对手也有类似的应用,你可以对其进行调查,以产生新的想法。这也有助于判断竞争对手做得好还是不好,以及他们的用户是谁。否则,你可能会想进行一些网络分析,进行调查,访谈,民族学(即观察)研究,等等。
如果有足够的研究,你应该能够分析您的新数据,以发现其中的模式/趋势。通过分析这些模式,你应该能够将数据提炼成一个“普通用户”的用户画像。
用户角色
“用户角色”是产品用户的原型表示;一个假想的人,可以让每个参与开发产品的人更好地了解他们想要吸引的人。本质上,人物角色只是用户用来交流他们的研究成果的工具,下面是一些用户角色的例子。

这样的工具有很多,但人物角色是最流行的工具之一,有些公司使用真人(如家庭成员或朋友)作为用户角色。在这种情况下,他们甚至可能联系那个人,询问他们可能会被整合进产品的具体问题;但是绝大多数的人物角色都是虚构的。
为了理解角色的动机,一些用户体验应用了一种叫做移情图的工具,它通常包括角色所说的、所想的、所做的和所感受到的。
下面是开发者Rafa的移情图的例子:

我们应该注意到,许多公司会创建大量的用户角色,比如5个不同动机和生活环境的人。这通常是比较重要的人物角色,但说实话,用户角色的最佳数量取决于数据本身。所以你不应该在创建角色的时候就对角色的数量有预判,(虽然我看到的大多数资料都是2-3个)。
一旦你的应用拥有了足够的人物角色,你就需要开始了解你的人物角色应该经历什么,因为人物角色的真正力量是在场景中使用它们。
02
「 发现和计划 」
在这种情况下,我喜欢“发现”(discover)这个词,因为它强调了设计师并没有所有的答案。在某种程度上,你必须根据用户的想法和需求来“发现”它,而不是简单地“创造”一种体验。一旦你发现了关于用户的许多事情,你就可以根据这些点来进行计划。
阶段3-A:常用技术
用户场景的映射
“用户场景”只是一个故事——一个旨在传达用户做某事的意图和主要步骤的叙述(也就是说,你甚至可以用简短的项目符号形式编写用户场景)。
但是使用场景的真正优势来自于可视化的实现。有许多类型的可视化方式,包括“叙述性场景”和“故事板”,但是我要谈论的是UX中最流行的方法之一:场景映射。
场景映射显示了执行某些任务的每个步骤,它们用于多种目的的任务中。首先,他们帮助传达角色完成任务的动机,这可能帮助我们发现和理解痛点,并帮助我们识别改进的机会。
下面的图片就是一个很好的例子。假设您有一个名为Paul的角色,Paul想在客户的网站上为他的妈妈订购鲜花。场景图显示了如何去到那里的每一步,以及你或与你一起做这项活动的其他人所添加的有用的附加信息(比如,想象自己是Paul,去经历每一步)。

其他的UXDs则更进一步,包括额外的便签、用于描述角色在每一步的言论、思考和感受。但是,您会注意到,这些步骤并没有描述任务将如何完成,而是描述了要到达目的地需要做什么。
这些功能的细节将在稍后公布——不在这个阶段。
要创建一个场景,你可能需要和你的客户谈谈,并讨论什么是关键任务(例如:不是登录或退出等常见任务)。一旦你知道了关键的任务,你就可以开始在你的场景中加入一些上下文(比如:谁,什么,何时,何地,为什么…但不是)。在应用程序中与其他利益相关者(用户、客户、产品开发团队等)一起讨论人物角色。如果场景映射变得更大,如下图所示,请不要担心。

映射场景的过程包括收集反馈、相应地重复以及收集更多反馈的过程,所花费的时间几乎超出了所有人的预期。但是,当你完成了关键任务的规划后,你会得到反馈,并确保一切都在按照应有的方式进行,之后再逐步回答问题,以便对该经历有一个更全面的了解。
你从这个过程中得到的数据可能还会帮助你发现将来可能需要添加哪些功能;或者,至少帮助充实用户旅程(在下一小节中描述)。记住,这并不是要求你从场景中定义一切……仅让您继续进行设计讨论便足够。
用户旅程
“用户旅程”的定义取决于你问的是谁。有些来源说它们是从各种场景中衍生出来的;有人说它们是叙事工具,可以帮助我们理解人物角色的动机;还有人说它们是用户和产品之间接触点的图表或模型;还有一些人说它们就像记录情绪的日记,“可能集中在解决方案的不同方面,包括后端服务器。”
它们的外观和叫法也有所不同(有人称之为“体验地图”或“客户旅程地图”);但是下面的图片很好地勾勒出了它们中的大多数的样子。

正如你所看到的,用户旅程地图通常是线性的可视化,用来传达用户体验产品时的情绪状态的某些方面。通过突出显示他们生气、惊讶或高兴的情绪,你会更容易发现需要改进的地方(也可能帮助你注意到应用程序的其他方面的问题)。用户旅程地图可以通过用户访谈、观察、前几个阶段的数据等获得反馈来创建。下面是一个详细的例子:

旅行地图可以用于当前的体验,或用于你打算创建的体验。如果你同时使用了这两种方法,产品开发团队就可以对它们进行比较,并确定为了达到这个目标需要改变什么。当然,随着新挑战的出现和克服,这两种旅程可能都需要改进。但是这个过程应该有助于让每个人都在同一个阵营中,这将使产品开发团队能够更好地前进。换句话说,你应该制定一个行动计划。
阶段3-B:备选方法
用户故事(和用户故事图)
我不想详细介绍每一项技术,但围绕“用户场景”这个术语似乎有很多混淆,很可能是因为“故事”这个词在谈论用户场景和用户旅程之类的事情时经常被口头使用——即使是我在这篇文章中也是如此(尽管我很注意不在其他地方写“用户故事”)。
让事情更加复杂的是,我们在 Agile development 团队中使用了术语“用户故事”,这可能会让设计人员感到困惑。设计人员可能会将此作为与开发人员沟通的一种方式,并给他们一些指导。我不认为这是一个问题,事实上这就是我将如何使用它的方法。请记住,有些设计师说“用户故事”来表达其他的含义;但是本节的其余部分是关于Agile的含义。
用户故事实际上非常简单——它只是描述用户如何与应用程序交互的一个方面,以一种开发者可操作的方式来进行。
例子包括:
作为一个用户,我希望能够改变鞋子的颜色;
作为一个管理员,我想能够访问页面,可以看到付款历史记录;
作为一名用户,我在上午9点到下午5点之间浏览到主页时,聊天机器人的聊天泡泡会弹出一句问候。
用户故事通常有三个部分:
- 所讨论的个人是谁(以及上下文是什么,因为可以有多个细节,如第三个要点所示)
- 一个动作
- 那个动作的结果
通过查看这些要点之一,开发人员应该对如何处理这些信息有了一个相对较好的想法,这就是用户故事如此广泛使用的原因。
创建用户故事甚至不在用户体验设计师的职责范围,但我想把它纳进用户体验设计师的职责范围内,因为如果不这样做,可能会导致在其他地方使用这个术语的人更加困惑。我们需要明确的是,像开发主管、团队领导或项目经理这样的人可能会基于(或结合)你创建的用户场景/旅程来创建用户故事。

至于“用户故事地图”,肯定有更多的文章谈论难以捉摸的可视化内容的,而不是它实际上展示出来应该是什么样子。大概是因为开发人员使用用户故事,而设计人员则撰写相关文章;
但无论如何,我想知道它们到底有多有用……但也许是我自己的经历影响了我的判断。
因为尽管在我作为开发人员工作的期间经常使用用户故事,但我从未使用过用户故事图。

服务蓝图
根据学习空间工具包:
服务蓝图是一种操作计划工具,为如何提供服务去提供指导,详细说明实物证据、员工行动和支持。服务系统/基础设施提供服务需要通过不同的渠道。

例如,为了计划如何将设备借给用户,服务蓝图在这个过程中有助于确定这将发生在哪一个服务平台,幕后需要进行什么样的维护和支持活动,用户是如何了解什么是可用的,它又是如何检入和检出,以及通过什么方式来培训用户,教会用户如何使用设备。
有些服务蓝图比你在这里看到的基于文本的例子更图形化,这就是为什么我在下面包含两个例子的原因——一个基于文本的例子有清晰的箭头,另一个例子有更多的图形但没有横断箭头。

原文链接:查看链接 ↗
作者:Ryo Mac
译者:益生菌菌
文章下篇将在后续推出
敬请关注~
原文请戳【阅读原文】
为尊重版权和译者
转载请联系我们
推荐阅读
「超级课」5星期学会UX交互设计全流程:零基础进阶交互设计师!
环球设计之旅第七周课程回顾\| 米兰理工学姐讲述IEKA宜家体验设计
我们

服务.体验.交互设计传道者


「一只朝菌设计学园」由毕业于清华大学人机交互专业的学长创办,致力于创造卓越的设计知识学习课堂,专注交互设计、用户体验设计、服务设计领域的专业知识教育。
教师团队来自于清华大学、同济大学、上海交大、北京理工大学、北京邮电大学、中山大学、华南理工、江南大学、香港大学、香港理工、台湾科技大学、Imperial、POLIMI、Delft、Oslo、Goldsmiths、Edin、Glas、Manc、Lancaster、Loughborough、Leeds、Arts London、BCU等国内外高校,以及Microsoft、阿里巴巴、腾讯、网易、华为、央视、百度、美团点评等企业集团。
清华大学有训曰:行胜于言。「一只朝菌」谨承母校百年教诲,时刻铭记师者之责,为好学者传道授业,为有志者掌灯引行。