服务设计工具概述

产品小白专属,10周线上特训,测、练、实战,22位导师全程带班,11项求职服务,保障就业!了解一下

本文详细地为大家介绍了服务设计工具的使用方法,并结合研究成果或设计案例去进行阐述,以帮助大家更好的理解,并能够实际运用到设计工作中去。

暖阳假期,我在咖啡馆写下这篇文章。想和你分享一些关于服务设计的干货知识,这些方法和工具给我的学术研究、设计工作带来了巨大的帮助和启发。希望给工作中的你、为论文一筹莫展的你带来一些灵感和帮助。

在接下来的日子里,我将用九篇文章,详细的给大家介绍这套服务设计工具的使用方法并可能的结合我的研究成果或设计案例去阐述。帮助大家更好的理解和运用到实际的设计工作中去。

今天是第一篇「服务设计工具—概述」,会给大家介绍一下这套工具的来源背景和每个模块的大概内容,集中精力,开始阅读吧!

服务设计工具 — 概述

服务设计工具量表(Service Design Toolkit)是由NAMAHN、法兰德斯创意区(Flanders DC)、欧洲公共服务设计创新联盟(SPIDER)、三个机构联合研究设计。其目的在于通过这套工具,更科学系统的的对目标用户诉求进行挖掘和研究,对产品内核进行探索和梳理。

NAMAHN成立于1987年,是一家专门从事数字产品和服务设计的设计公司,如自助服务亭,电子政务和知识库。始终以用户的需求和要求为出发点,目标是使这些产品和服务尽可能地方便用户。该公司以与客户、用户和其他利益相关者的合作和开放关系为荣。通过采用完全以人为本的设计方法,推动创新。

Flanders DC法兰德斯创意区是创意部门创业精神的独特接触点。作为一个非盈利组织,该团队为佛兰德政府工作,采取中立立场。支持企业家的创业、成长或公司的专业发展。与此同时,佛兰德斯特区可以帮助寻找设计师,帮助完成服务设计流程,也可以帮助设计简报。

欧洲公共服务设计创新联盟(SPIDER)是一个拥有十个跨国合作的服务设计机构,总部设立在英国、法国、爱尔兰和比利时。该组织为共在欧洲开展了43个服务设计项目,60余场服务设计培训,为欧洲的公共服务设计做出来巨大的贡献。

服务设计工具量表(Service Design Toolkit)共16张,通过这16张量表,我们可以将抽象的服务设计方法以及研究结果通过可视化的形式呈现出来,让用户和研究人员更直观的了解整个研究过程,并更低成本的参与其中。整套量表16张,被合并为8个步骤。

服务设计工具 — 概述

研究步骤一(F1-1、F1-2):

框架设定(Framing),在这个环节中,主要针对项目服务设计目标和整体框架进行设定。其中包括服务目标(Objective of The Service)、服务背景(Service Context)、服务承诺(Service Promise)、最重要的结果(Most Important Results)、用户(User)、雇员和其它利益相关者(Employees and other Stakeholders)。

研究步骤二(U2-1、U2-2):

用户洞察(User Insights),在这个环节中,主要针对项目的相关利益者进行洞察和访谈,询问用户或员工目前的使用经验或工作经验,了解每一个步骤并让用户描述其感受。然后让用户阐述两个极端体验,最积极和最消极的两个维度,并说出他们的感受和造成这种感受的根本原因是什么。最后,让参与访谈的用户列出在整个产品服务体验系统中他认为最紧密联系的人和最疏远的人员名单,构建利益各方图解,综合分析服务系统存在的问题。

研究步骤三(P3-1、P3-2):

用户模型(Personas),在这个环节中,主要针对用户洞察(User Insights)中的相关数据,建立用户模型(Personas),在建立的过程中,我们要重点关注三个部分,行为描述(Description)、激励点(Motivating)消极点(Demotivating);在行为描述中需要描述该用户在什么样的背景下使用该服务,值得注意的是,在用户洞察(User Insights)中,用户的自我描述会带有强烈的个人色彩和主观意识,我们需要客观的进行转化并在用户模型(Personas)中呈现;在激励点中,重点描述用户在使用该服务时的兴奋点,什么样的体验最积极最让用户开心;在消极点中重点描述消极的维度,什么服务形式会导致用户选择放弃该服务。

研究步骤四(D4-1、D4-2):

设计范畴(Design Scope),在这个环节中,我们会回到框架设定(Framing),根据用户洞察(User Insights)、用户模型(Personas)的内容,重新思考我们的服务目标(Objective of The Service),与此同时我们会开始描述产品形式(Chinese Portrait)想象未来的服务形态时什么样子以及我们的设计挑战(The Design Challenge)是什么,我们怎样才可以达到用户目标。最后,我们需要思考项目成功的标准是什么,具体描述我们的验证指标和测量目标(Most Important Measurements of Success)。

在确定设计范畴之后,开始分析设计范畴中用户的高级需求是什么,在设计挑战(The Design Challenge)中确定用户的高级需求,至少3个。然后分别从六个维度进行需求的分析,物理情景(Physical Context)、互动关系(Relational Context)、活动(Activites)、目标(Objects)、情感目标(Emotional Goals)、理性目标(Rational goals),最终整理出最具价值的高级需求并在后期进行开发实践。

研究步骤五(I5-1、I5-2):

灵感(Ideation),在这个环节中,我们会使用莲花解构(Loutus Blossom)来做竞品分析,在量表的中间,写下一个设计挑战(Design Challenge),围绕设计挑战写下8个需要设计的功能,每个功能设计需要寻找一个优秀的竞品案例并记录下来,然后分析每个优秀案例的8个特征,证明为什么它的设计是优秀的,鼓舞人心的。

通过这样的方式,可以最本质的找到竞品的优点,而不是流于表面的模仿学习。最后,我们需要挑选出在这些优秀的案例中,最佳的理念或特征元素和我们未来的服务解决方案相融合,获得更优秀的服务设计解决方案。在完成莲花解构(Loutus Blossom)之后,我们会对创意进行筛选(Idea Selection-Cocd Box),在这个过程中,我们会展示所有的设计解决方案,让参与者使用不同颜色的贴纸,在量表中排列想法并决定其想要进一步发展和思考的创意想法,我们会将创意归类到四个类别中,分别是:普通且不可行的方案(Ordinary and Not Feasible)、普通且可行的方案(Ordinary and Feasible e)、独特且不可行的方案(Orignal and Not Feasible)、独特且可行的方案(Orignal and Feasible)。

研究步骤六(S6-1、S6-2):

服务概念(Service Concept),在这个环节中,我们会通过严肃游戏(Serious Play)开发用户故事,拆解用户使用的各个阶段:获得通知、触发控件、引发思考、做出决策、使用场景、寻求帮助、使用后的感受等等。在量表中把每个阶段都描述清楚,并询问用户在这个阶段中的思考和感受,并观察其关键触点是什么。

在完成服务概念(Service Concept)的录入之后,我们开始整理用户旅程图(Users’ Journeys),整个旅程图被拆解为使用前(Beforehand)、使用中(Using The Service)、使用后(After Use)三个阶段。每个阶段,分别会从用户的角度和企业的角度来思考,从用户的角度来看,主要思考两个问题,用户想要什么和用户想干什么,而在企业角度来看,主要思考如何让用户接触到服务,如何解答用户的需求,员工可以干什么,网站可以有什么效用等等。

研究步骤七(P7-1、P7-2):

原型及测试(Prototype & Test),在这个环节中,我们会先做一些准备工作,例如,先决定要测试哪些触点,然后思考想要如何进行测试,谁来负责和执行整个过程,需要哪些工具,需要什么样的人来被测试(用户、员工等)。

接下来开始我们的测试,在测试的过程中,我们要积极的询问用户在这个触点中,用户的行为是怎样的,评估他的情绪动线,哪些积极或者消极的经历是反复出现的,思考我们如何来加强积极情感的体验和解决消极情感的问题。

研究步骤八(F8-1、F8-2):

可行性(Feasibility),在这个环节中,我们会先制作用户体验蓝图(Blueprint),在研究步骤六-服务概念(Service Concept)的基础上,增加后台运维(Back Office)的方案,考虑内部程序和系统在幕后需要做什么,外部程序的生态需要做什么。

规划好用户体验蓝图之后,制定可行性路线(Rodmap),可行性路线主要分为几个模块,首先是提出最小解决方案,这是未了减少企业的开发成本,我们在蓝图中找到服务流程中的触点,包括前台和后台的相关的开发流程,尝试共同探讨低成本高效率的解决方案。然后我们会选择其中的几个部分作为试点项目,记录想要推广的产品,制定计划,最后全面推广。

好啦,以上就是整套服务设计工具量表大概的研究流程,对于每一个研究步骤,在接下来的日子里,我都会单独撰写文章详细介绍。需要说明的是,但由于每个企业和项目都具有其特殊性,因此,在使用的过程中,并不是一定要完全使用所有的流程,我们可以根据项目的情况,选取部分量表和相关的研究方法进行设计工作。

感谢你的阅读,欢迎点赞、评论和转发!😄

内容皆由笔者以往的研习经历和工作经验沉淀总结,如有不正,欢迎指正讨论。

 

本文由 @吾先生 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!