关于 User Story 的一些思考

首先放上近期在看的视频和文章,恰好与 User Story 有关:

  1. Airbnb 体验部总监采访视频 - #1: Airbnb's Director of Experience, Katie Dill, tells us why Airbnb uses "stories" to design

  2. 用户故事传达出的设计理念 - UX Stories Communicate Designs

  3. 用户故事在敏捷项目中的应用 - Accounting for UX Work with User Stories in Agile Projects

想起来,最早与用户故事( User Story )这个概念搭上边是在上人机交互课程,让我们写人物角色( Persona )和情景剧本( Scenario )的时候。虽然这两个概念与真正的 User Story 有些差别,但在与授课教师沟通的时候也明白了当以这类概念为基础进行思考时,与传统软件工程中所思考的角度是不同的。

比如之前在写软件文档时,只需要知道有哪些角色类型,并不关心这些角色是否拥有自己的名字、社会关系如何,而在写人物角色的时候,需要构造出这个人的基本信息、爱好习惯、家庭、工作等背景。对于软件文档来说,关注的是用户做出了什么行为、触发了系统怎样的反馈、哪些系统状态发生了改变,在写情景剧本时,则关心用户的目的,在什么情况下发生了何事,然后使用系统的某个功能来解决问题。看上去并不难,但由于没有摆脱写文档的习惯,第一次写情景剧本时,仍然不自觉地构思用户是点击了某个按钮,触发了对应的功能,进入了页面,以细致到刺激-响应序列的维度上去思考了。

后来在上培训课程的时候,才算是慢慢将思维进行了转变,接触到了用户调研的手段、故事板( Storyboard )等方法。收集他人的作品集时,看到一个人在自己的每个作品开头都概括这是关于什么的故事,也觉得眼前一亮,比平铺直叙地按项目流程展开有意思得多。不过「讲故事」对我而言还是一种很神奇的方法,可能因为「绘制故事板」只是闷头苦干行为,虽然也需要表达,但在做个人项目的时候似乎不用考虑到当面展示给别人看,故事板自带的图片属性也削弱了需要滔滔不绝讲解的恐惧。而「讲故事」,在我看来,变成了带有表达性质的行为,给人的直观感受就是要对着一屋子的听众说个不停,在个人项目中自然没有听众需要我去打动,也就不用考虑使用了。

这种奇怪的误解也让我直到昨天才第一次尝试构造用户故事,虽然实际上没有数据支持,但对我个人起到了不小的作用。在此之前,先谈谈「讲故事」能怎么用,有什么好处。

近期开始思考用户故事的契机是一次需求评审会,评审的是一个系统重构的需求,涉及到了 10 种左右类型的单子。可以说光是弄清楚单与单之间的关系就足够让人头大了。会议由负责该需求的产品经理主持,参会人员有项目经理、开发们和一个交互的我。我在会议开始没多久就走神了,一个原因是我在此前已经看过正在讲解的需求,也参加过需求方的会议,对要做什么已有大致的了解;另一个原因,则是产品经理的讲解方式。

这些单子大致分为四类,每种类型又包含两到三种不同的子类,子类之间存在着某种逻辑上的对应关系。仅是这样描述我已经觉得很难让读者明白了。产品经理的描述方式是逐个单子进行讲解,因为他在整理需求的时候已经把这些关系弄得很明白了,也画了每个单子状态变化的流程图,所以他从逻辑的角度入手,语调平平地快速讲解着。在大家听起来就是这样的: A 类单通过 [ 1 操作 ] 后变成 k 状态,然后由 [ 2 操作 ] 可以变成 m 状态,此时 B 类单又与 A 类单中的 @ 字段有对应关系, A 类单中还可以建立多个 ¥ …

不难理解我为什么走神。但在当时我只觉得是我无需认真听,只要再看开发的反馈、项目的排期就行了。

大家就这么沉默地听着,我悠哉地做着自己的事。在会议的后半程,一位开发人员打破了这个局面。他问:「你能不能以故事的形式来讲述?」一语惊醒梦中人吧,我抬起头来,听他接下来要说什么。他接着说,这样讲解很难让人明白,可不可以用 storytelling 方式,分几个角色,每个角色在这个过程中都做了什么事。从产品经理的描述可以得知,这些单子是由不同人员操作的,但只是单纯地在讲解单子操作时略略提到。产品经理不太明白这个请求,解释这些操作只和开放的权限相关,给其他人员开放权限也是可以的。直到会议结束,我与产品经理对原型,向他确定每个单都是由什么角色操作时,他还是感到奇怪,问为什么我和开发都想知道角色。

他问我之前,我已经从开发的描述中体会到了 User Story 的作用,他问我之后,我开始思考为什么。

在上述情况中可知,User Story 的作用是让不熟悉项目的人能快速了解项目内容,让参与者能理解用户的痛点、产品的意义。通过讲述一个故事,设置了一项操作的上下文,即使听到的都是陌生名词,也能依据故事内容快速地与其他部分关联。此外,当产品与生活息息相关时,User Story 能唤起听者的同理心,感到自己或者身边朋友也会遇到类似的情况,加强参与感。

但是为什么故事就能加深我们的理解呢?只有想明白了为什么,我才能顺当地承认这个方法。从这个项目入手开始思考,我想到的是认知与常识。项目中,有一个角色是客服。提到客服,不难想到一个面带微笑接电话的人(在这里我突然想了一下构建故事的「政治正确」)、一个与用户直接接触的人,他们能第一时间对用户的情况进行反馈与记录,记录完后再提交给其他部门。还有一个角色是维修厂工作人员,我们能想到他拿着扳手对车辆露出微笑,从收到的单子上看到哪些地方需要维修。只需提供一个角色,我们就可以结合日常认知进行细节的补充,将与这个角色相关的流程放到合适的位置:首先要让客服与用户接触才能建立相关单,维修厂人员需要根据确认过的单子去维修、提出修改。

包括我在讲用户故事这个概念时,也先说了一个故事~~,包含的常识大概是产品经理在项目中难以与相关人员沟通~~。NNg 的一篇相关文章则是以故事板的形式进行了说明,十分可爱。

除了上述的好处,User Story 还能提升设计人员对用户的关注,明白用户在使用产品的整个过程中会发生什么事,能挖掘出更多的痛点。既然用户故事如此之妙,为什么我没有将用户故事应用到项目中?除了上文说明的「奇怪的误解」,在看了开头提到的视频和文章后,可以得知,用户故事的背后必须有一定质与量的数据进行支持,否则只是空想,实现的可能是虚假的需求,一场自娱自乐。而用户数据收集与研究,又是一个很大的课题了。

不过我昨天确实通过自娱自乐切入并熟悉了一个新项目,又是一个新的体验。可以下篇再说。嗯。