信息的沉淀和快速验证

在过去的48小时里，我以一个coach的身份参与了由Thoughtworks承办的Global Service Jam（以下简称GSJ）的活动。GSJ是一个全球范围的活动，通过全员参与由设计思维方法论为指导的共创过程，理解服务设计。这里提到了两个概念，“设计思维”和“服务设计”。

“设计思维”更多解决的是以用户为视角的产品设计问题，通过一系列工具方法孵化产品的过程。

“服务设计”是一种设计思维，用服务蓝图的方式展现整个服务生态，和角色在服务中的贡献，这些贡献可能是用户看得到的也可能是看不到的。

所以才有了这句话 “服务设计是你选择一家咖啡店而非另一家的原因”

对于用户来说，服务未必是一个非常具像化的产品，更多的是身处其中的感受。

每年的GSJ会有个保密的主题，在当天公布，全球参与者基于这样的主题，共创出一个服务方案。今年的主题是：

特别的是今年GSJ与社会公益做了结合，希望更多的人关注到社会公益，并通过GSJ这个平台给公益组织提供一些创意。

脑暴

当看到这个主题时，你想到了什么？黄色的大背景，黑色的字体写着BLUE。黄色是否代表一种警示，黑色的字体写着代表蓝色的BLUE让人有强烈的认知冲突，抑或当一个不认识英文BLUE的人看到这个题目，他是否会忽略“蓝色”这样一个属性。

在对大家的信息归类后，我们定下了小组的主题：

如何协助LGBT人群完成自我认同/社会认同，以此改善该人群与社会间的冲突感。

LGBT是女同性恋者（Lesbians）、男同性恋者（Gays）、双性恋者（Bisexuals）与跨性别者（Transgender）的英文首字母缩略字。

这个主题非常庞大，一开始的时候大家都不知道该通过什么方式入手，什么角度作为切入点。

同理心地图

很多时候，当我们接到一个大的命题，都不知从何开始，这是因为一个大的命题中包含了太多的概念和信息，虽然你认为小组已经定下了方向，但事实上每个人脑中对于命题的理解都是不一样的。比如社会认同，有的人想到的是消除旁观者歧视，有的人想到的是如何改善与父母的关系，有的人想到的是LGBT人群的法律保障。

这都是非常好的想法，因为大家已经开始以一个LGBT人群的角度思考，这个时候用一个同理心地图的形式就可以很好的收集组员对于这个命题的理解。

同理心地图有两个主要层次，1. 感觉；2. Facts（听到的，看到的.....），通过收集大家的想法，组员开始慢慢对用户有了初始的概念，但这个时候我们脑中的用户形象带着太多自我假设的信息，如何对这些信息进行验证呢？

用户访谈

其实收集用户信息的方式很多，有的是定性的，比如访谈，焦点小组，有的则是定量的，比如问卷调查，可用性测试。在这个阶段我们主要目的是能够验证信息假设，通过用户信息的验证对用户形象进行初步构建，在与用户沟通过程中逐步找到用户关注点（Focus）。

组员们列了一些问题框架，就开始了访谈。访谈过程却并不那么顺利，平时热爱聊天寒暄的组员一带着“收集用户信息”的帽子，突然发现不会聊天了。很多问题东一榔头，西一棒子，等到结束，却不知道自己收集到了什么。不过对于可能是第一次做用户访谈的小伙伴来说，能够做到主导访谈过程，做好记录还是比较棒的。

访谈的技巧多种多样，我这边主要举两个印象深刻的例子。

有个组员在设计问题的时候想到，LGBT群体作为性少数群体，肯定经历过认知上的挣扎，发现自己是少数群体的时候肯定压力很大，结果将问题抛出给受访用户后，得到的却是一个乐观开朗对自我接受度很高的回答，一下子让访谈不知如何进行下去。第一轮收集信息的时候，可以不要带太强的预设，顺着访谈对象聊，了解用户背后的故事。不要让同理心地图变成你用户访谈的限制。

还有个组员提到，用户跟我说了，他自我认同感很高，只是想多认识些直人朋友，这应该就是他的痛点了吧。首先，不要这么快去下结论，让我们想一想，作为一个非LGBT人群你是否曾有过特地要多去认识LGBT朋友的想法，很少吧？为什么对于一个自我认同高的性少数用户，却突然提出要多认识些直人朋友呢，他有什么在直人那里可以获得却在当前获得不了的，在日常社交圈中为什么他会觉得难以跟直人相处？多去深挖一下用户动机，会帮助你更好的理解用户需求。

用户画像

用户画像是一个很不错的载体，它可以将组员收集到的信息通过相对具像化的形式展现出来，让大家聚焦到某一类用户上。在构建用户画像的过程中，大家的用户理解也在逐步拉通。

这时候有组员提出疑虑，这是我们的聚焦用户吗？好像跟我采访的人有些不同，我采访人的用户特质没有体现啊。

首先需要说，用户画像并不是一个具体的人，它更多的是承载一类人的共性，而这个“类”是大家根据收集到的信息抽象出来的，把大部分符合这个人群的共性信息呈现在上面，方便大家能够对用户达成一致的理解，可以为这次“服务设计”找到一个focus。用户画像并不期待包罗万象，而是我们认为这样的特质是大部分这类用户的共性。服务优先解决用户大部分的需求，再去考虑如何迭代满足更多需求。

其次，由于这次时间紧加上访问用户量少的问题，确实造成收集的信息相对集中，用户画像很快的建立了。但现实中，我们可能会有多个用户画像，其次我们也会带着我们的用户画像回到用户本身，由用户来帮我们验证这样的抽象是否正确。

用户旅程地图

抓到了用户之后，我们开始绘制用户旅程地图。由于要解决的问题，是一个自我意识，甚至社会意识形态的转变。用户旅程的起点和终点就显得尤为重要。让我们重新回到最初的方向

如何协助LGBT人群完成自我认同/社会认同，以此改善该人群与社会间的冲突感。

认同感是整个转变的核心，于是我们抓住这个核心，定义用户旅程从发现自己不同开始，到可以以性少数身份生活为止。

Know yourself ——> LGBT-way life

因为小组中有性少数学员，所以旅程的定义过程相对顺畅一些。但这个时候一定要注意，不要在定义旅程的时候忘掉“用户是谁”。避免代入太多自己的主观判断，从抽象出的用户画像出发，通过访谈收集的信息逐步规划出用户旅程。随着用户走完这个旅程，我们形成了用户的心情曲线，识别过程中的心情波动，会帮助我们找到提供服务合适的时机点。

这时候有组员提到，用户画像的时候我们也有过用户痛点，为什么现在在旅程里的痛点跟刚才会有所不同？

其实用户画像的痛点更多的是一种描述，并不是通过具象的事件推演出来的，更多的是通过痛点的列举，让我们对用户本身有更多理解，让用户形象更加丰满。

而旅程当中的痛点，是我们在规划用户旅程的过程中，通过用户行为，接触点和心情等因素得到的，这时候更多关注到一个相对具像化的痛点。用户通过做这样的action，与其他人或者产品产生touchpoint，发生心情变化，催生出这样或那样的痛点。这么做是因为最终我们提供的服务解决的是一个具像化的事件体验，通过事件体验的优化为切入点，提高用户的整体感受。

How Might We.....

我们将用户旅程中的痛点进行了归类，从用户价值和可行性两个角度形成了四个象限，将痛点放置在象限中，留下了第一象限中的三个痛点进行了投票。

痛点的排列可以有多种维度，甚至可以收集用户对于不同维度的关注度，进行加权计算，排出痛点优先级。这里为了简便，使用了二维的象限方式。

最终我们抽象的痛点是

因为渠道少，信息杂乱，造成用户无法获取优质的LGBT信息，从而引发自我认知上的挫败感

其实这个阶段有的学员会有疑虑，想说最后聚焦的痛点似乎很简单，是我一开始就想到的，为什么我们还要走这么长的路才得到这样的结论。首先这个观点忽略了痛点的产生过程和这个过程上承载的其他信息。虽然我们抽象出了一个痛点，但是这个痛点是有信息基础的，是可以回溯找到产生根源的，在你设计服务的时候，往往解决的就是痛点背后的根源问题，而非直接解决痛点本身。

基于这样的痛点，我们用HMW进行了一次方案的发散。很多学员觉得这个过程很难，这时候不妨再回溯到痛点本身，也可以想想自己日常享受过的服务，是否曾有什么让你眼前一亮的方式可以用到这个场景。

过程不再赘述，最后大家达成共识“HMW让信息更具感染力和传播性，从而触及到我们的用户”。这里需要提一句，方案阶段往往最容易产生争执，这个阶段不要强调对错，更重要的是快速达成小组共识，完成初步原型，来与用户验证。过度强调对错，背后都包含了一定的自我判断。在大家都认可的情况下，只要这个方案是能够解决痛点的，可以先基于共识进入下一阶段，让真实的用户来做判断。

To-be 故事线

集思广益中，很多idea开始冒出来，比如与已有平台（抖音）融合，增强传播性，比如让直人体验LGBT生活来增强共情和感染力。最终大家的讨论满满集中在基于位置的社群活动信息展示平台这个想法上。因为LGBT信息相对隐蔽，很多宣传渠道难以触及用户，地图点亮标记的方式可以很好的让LGBT群体感受到社群就在身体，参与到附近的活动中去。

在这个过程中，有的组员开始反思，现在这种LBS服务好像更多强调了社交，这还是我们最初的方向和痛点吗？这是一个非常好的问题，我们快速的拉回到上一个阶段，当我们HMW的时候我们在解决什么样的痛点。

为了更好的了解痛点，我们重新回到用户旅程地图，试图回忆起发现这些痛点的原因。这时候我们发现，在我们设计用户旅程地图时，我们的起点定的很早，很多LGBT人员是在初中认识到自我的不同，同时终点又有点晚，LGBT方式的生活很有可能是一个已经进入职场，工作相对稳定的人群，这样的他还是我们定义的那个24岁初入职场的用户吗？

这样的信息回溯帮助我们很快的找到了问题，因为旅程的时间跨度太大，让我们在方案阶段失去了焦点，我们快速进行了调整，将用户当前阶段定义在已经接受自我，正在寻求社交和亲密关系的阶段。

其实这个时候很适合将这个阶段的旅程再做一次进一步的细化，挖掘可能被丢失的信息。

我们将这个阶段的痛点做了复盘，这个阶段的信息痛点主要在于渠道少，信息很杂找不到适合自己的信息。回溯到具体事件，很快的将方案设计又拉回到我们的聚焦。

我们决定以位置为载体，将社群信息可视化在地图上，让用户快速找到社群信息。我们定义用户大概有三类，第一类是“漫游者”，他没有明确的目的，只是想看看有什么社群活动，尝试第一次参与，第二类是“需求者”，他有明确的需求，想要通过一个社群活动收集信息解决他具体的困难，第三类是“贡献者”，他参与了很多社群活动，他通过分享活动体验，来对社群作出贡献，甚至组织社群活动。因为时间的关系，我们决定把方案设计聚焦在第一类用户上。

用户验证

方案设计阶段大家都很兴奋，开始聊到很多具体细节，包括怎么参与活动得到积分，怎么让他找到伙伴聊天。我们会发现，细节很容易让人focus，因为它更具体，更可触，更有熟悉感。但陷入细节会让你的信息层级错位，这样的错位会造成在某个细节点上走的太深，忽视了其他点的重要性。

这个时候不妨回到故事线，作为一个漫游者，他想看到什么，他关注什么，然后设立一些初步方案，比如社群信息的可视化，找同去小伙伴消除紧张感，看别人的分享来了解社群等等。带着这样粗粒度的方案与用户做第一轮验证。验证过程中，你很有可能发现用户并不关心别人的故事，或者并不需要活动积分换取的礼品。所以在第一轮用户验证之前急于进入细节会造成信息错位，并且很有可能并不会达到你想要的效果。

第一轮用户反馈不错，也提出一些建议，比如原来方案中用门类区分活动，有点复杂，用户希望可以用hashtag的方式让我知道这个活动和哪些主题相关。还有在用户想去参加活动后，原来方案中更强化看到所有参与活动的人，但用户更关注我哪些好友会去，如果好友没去，有哪些跟我年龄情况相仿的人可以同去。

通过这样的方式很快的得到一些用户反馈，也给学员一些反思，在快速完成方案的优化后，又进行了第二轮用户验证，形成了最终的方案原型。

创新可以是细节

排演的过程非常兴奋和愉快，很快到了展演阶段。展演结束后，其他小组的成员提出，你们这些功能平时都见过啊，没太多新意。

这时候我们不妨想想创新是什么。

有很长一段时间，苹果被定义为创新的标杆，它出过很多优质的产品，建立了线下的直营店网络，完善了整个售后流程，形成自己的生态圈。但苹果的每一步都是带有“新意”的吗？触屏？脸部解锁？NFC？似乎技术在很长一段时间不再带给我们新鲜感，而为什么用户还是选择苹果呢？

服务设计是你选择一家咖啡店而非另一家的原因

其实最常被提到的是“细节”，细节上的极致优化，是不是也是打到客户的一个创新点呢？比如苹果手表的抬起唤醒，听上去是一个非常小的细节，但你能想象失去它吗。抬起手表一片漆黑，点击才能看到时间，那我为什么我不去看手机。正是这样一个创新细节，打到了核心痛点，而为了完成这个细节，背后的支撑活动却是非常庞大的。要考虑如何抓取用户抬起操作，如何保证落下时熄灭，反复抬起是否耗电等等。

说了这么多，我想强调的是方案是一个载体，方案中的细节可以在强化过程中解决用户的一些核心痛点。以我们组的产品为例，大家看到LBS并不新鲜，交友也并不新鲜，但我们抓住的细节是对于一个24岁从没参加过社群活动的“漫游者”，如何让他消除紧张感来线下参加活动。在这个点上，我们强化了寻找同去小伙伴的功能，让所有想去同时又不愿意自己去的人聚集在一起。如果再往下深入，可以通过标签的形式，让用户快速找到附近相似人群，一起参与活动，并通过私密故事加深了解。

所以有时候创新不一定是颠覆，而是一种锦上添花，可有时候这点锦上添花就能够让你吸引到目标受众。

虽然我们没有完整的设计完整个服务，包括信息发布者，积分兑换产品的生产商，供应商，物流等等。但在这个过程中，我们让学员感受到如何从一个开放式问题，逐步在信息的沉淀和快速验证中找到切入点，在切入点上深挖，形成方案，强化方案亮点，打到最终我们定义的目标受众。

一次实践，并不会让大家一下子成为一个服务设计者，更多的是强调设计过程，建立服务设计概念，最终解决现实生活中的实际问题。

“Think Big, start small, move faster”