简单快速的设计方法:用户故事(场景)

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

对于理论以及长篇大论的需求文章来说,人们更能记住故事发生的场景,通过简短但是详尽的故事描述,让程序员和设计师来理解,产品的用心良苦,从而达到,为用户提供设计服务,而不是产品单方面的猜测。

让我们来了解一个简单而又强大的工具,这是一种很好的设计方法,你可以在所有项目中应用它,同时可以增强所有利益相关者的合作。

敏捷设计的核心部分是用户需求也就是用户故事。有很多关于 UX 和敏捷开发的文章,很多人都在喋喋不休地谈论敏捷开发如何使用户体验不友好,这两种方法如何无法协同工作等等,并且很难适用于软件项目,与其他学科合作很有挑战性。虽然我们正在努力,但我们可能会对许多缺点说“是”进行妥协,而且我们不会在一篇文章中解决这些问题。

今天我们关注的是一种简单快速的设计方法,称为“用户故事”,可以帮助您解决许多这些挑战。

为什么?

  • 用户故事简短,具体且面向目标。这是一句话,往往具有以下结构:“作为一个,我想这样”。
  • 用户故事是协作设计工具,期望所有项目利益相关者参与用户故事的定义和排序。
  • 用户故事将项目的重点放在那些使用者角度。

这听起来不是以用户为中心的哲学和发展过程的核心吗?然而,它是来自敏捷开发的工具。

那么,为什么不接受它们呢?

用户故事:显然是以用户为中心

当然,有些团队不进行任何用户研究,并根据他们的想法编写用户故事。虽然这不是最佳选择,但它比考虑“我”要好得多。一点想象力可以创造奇迹,同时注意用户与设计者的不一样。只是为了强调这种思维方式的相关性,你可以向所有利益相关者,解释一下像下面这样的小方案。

“例如,如果你必须设计一个迎合音乐家的网站,他们可以选择风格和效果来帮助他们创作歌曲,你需要考虑很多类型的音乐家。客户要求提供具有各种效果的菜单。可能你会突然想到的是汽车音响的CD上的一首歌,抛弃这个想法吧,因为你想的是“我”。

相反,想一想:

  • “我” 可以是任何专门研究一种或多种乐器的音乐家。如果你认为“我”是一个沉重的摇滚吉他手,那就回去考虑一下键盘手,歌手,贝司手和鼓手……或者,也许是一位古典作曲家正在起草一部歌剧,并希望查看一些关于乐谱的想法。
  • “我”也是任何类型的作曲家。这可能是轻松倾听,电子化,或者是,精致,沉重的摇滚乐。或者,它可能是一位古典主义者,他被委托为一部你未曾见过的电影编写原声带。

太好了!现在我们已经设法让团队思考“更多的可能性”以适应我们的用户,我们能够创造用户故事。用户故事的格式迫使我们站在他人的角度进行思考,同时将他们的需求放在焦点上,对于同理心的工作,可以让自己置于用户的角度。

也许,有时候,我们不会根据实际数据做到这一点,但这是一个开始。也许通过这种微小的同理心练习,管理层和团队成员可能会理解出去寻找目标用户的必要性!

理想情况下,作为用户研究员,您应该在用户故事的定义上起带头作用。您可以将您的角色(我们创建的虚构用户)和用户场景带到用户故事会话中,并为所有利益相关者构建正确的框架。如果没有用户研究阶段,只需确保收集尽可能多的现有项目信息。这可以来自日志或分析,来自客户支持,来自计算机研究,竞争分析等。在我们音乐网站的互动场景中,我们很幸运的是客户告诉我们,他是主要为电视节目中的音乐处理的键盘手。

作为用户体验设计师,您是项目开发期间用户的“声音”。尝试用尽可能多的现实环境进行思考,并将这个“用户声音”翻译成用户故事,以便每个人都记住它。

用户故事简单易懂

如果你来自“旧学校”,你可能还记得用户用例。也许用户故事会提醒你关于你用户的一切。好吧,虽然有一些相似之处,但差异性使得用户故事更好。

用例具有特定的语法和结构,因此,并非每个人都参与定义它们,只有负责定义要求或功能规格的团队或负责人才能编写。用例是客户端(有时是用户和开发团队)之间的桥梁,因此,促进“轮胎摆动”模型,我们看到会发生什么……

产品设计中的用户故事(场景)

在上图的模型中,我们发现了每个人对于用户的需求解析出现了一些可怕的错误!但用户故事以其简洁和专注,提供了避免此类情况的完美方式。参与团队的任何人都可以参与其中。他/她只需要了解特定语法的相关性:

  • 作为一个 。角色指的是做出行动和受益的人。
  • 我想要 。这是执行的动作。
  • 以便 。它是用户从操作中获得的附加值。

通过这个简短的陈述,用户故事可以缩短学习时间!如果您来自参与式设计方法,您还可以让用户参与用户故事的撰写。

用户故事是协作的

正如我们之前所说,您作为用户体验设计师的目标是促进最终用户的具体,现实和共享的愿景,用户故事是你最好的盟友。由于它们的可访问性和灵活性,您可以使用它们来构建公共语言和项目所涉及的常见心理模型。因此,您可以让所有利益相关者 – 客户,管理层,团队成员 – 使用相同的语言,并专注于用户以及项目正在尝试实现的目标。

用户故事促进了项目讨论方式的转变,我们不再关注解决方案和功能。我们专注于“真实”用户能够为特定目的而努力的目标,我们没有一个可疑的抽象功能列表,我们将项目的最终目标集中在如何让用户做具体和有形的事情上。

用户故事讲述的是现在和未来

用户故事通常写在Post-its上,起初,Post-it的数量可能是压倒性的,但它比永无止境的需求文档更易于管理!

用户故事具有恰当的详细程度。在更抽象的层面上,我们有“epics”。在敏捷开发中,“epics”用于所需功能的高级概述。因此,他们收集了一组用户故事。如果您正在构建亲和关系图,则epics将是一组常见用户故事的名称。 Epics使项目中的每个人都可以从许多用户的角度看待设计,那么任何不合理的方面都可以显示出来。用户是否需要“尝试”未经计划或计划得好的东西也可以通过此得以验证。

用户故事必须足够具体,以便项目团队可以在冲刺期间选择并处理它们。在此之前,团队应该从一开始就深入研究细节并解决可用性问题。作为用户界面设计师,您应该成为项目团队的一员,并与开发人员合作,使用户故事真实可用。

用户故事的简单语言有助于每个人了解每个sprint中正在构建的内容,所有利益相关者都可以查看他们的关注点和需求是如何得到解决的。因此,用户故事非常适合设置阶段和定义项目范围,它们也是定义后续步骤的理想选择。因为它们处于完美的粒度级别(即完美的细节级别),所以当项目遭遇特殊变动时,用户故事可以帮助你更好地看清一切。

选择

用户故事一开始是作为敏捷和SCRUM开发方法的一部分,作为用户体验设计师,我们需要拥抱它并使用这种简单的方法来实现我们自己的“好处”,这对于用户而已也是很好的设计方法!

用户故事为设计人员提供了创建用户的真实,具体和共享理念所需的一切:

  • 用户故事基于用户目标; 因此,他们可以专注于产品的核心用户;
  • 用户故事是易于访问和管理的; 因此,它们促进利益相关者和团队成员之间的协作;
  • 用户故事有助于从一开始就创建“项目心理模型”。

通过一个非常简单和具体的结构,用户故事可以帮助项目专注于许多方面,例如:以用户为中心,以目标为中心,以及在每个阶段应该实施什么内容,如何选择和抛弃。

敏捷开发是一种很好的以用户为中心的设计方法,不单单是因为它可以为我们提供研究和计划的一个更好的方向,同时他还可以帮助我们构建以及创造出项目中每一个可能性的转折点,用户故事为我们提供了在最重要的用户研究和用户需求方面的一个可靠的理解和体会。

个人感想

我作为一名产品经理,当我去开启一个项目,进行背景以及功能点的解说是,我通常会采用用户故事的方法来叙述整一套的用户流程,同时我也希望我的团队这么去做。对于理论以及长篇大论的需求文章来说,人们更能记住故事发生的场景,通过简短但是详尽的故事描述,让程序员和设计师来理解,产品的用心良苦,从而达到,为用户提供设计服务,而不是产品单方面的猜测。

建议大家可以多采用 Persona 以及 Scenerio 来为更多人讲述你设计的产品的初衷。只有当你成功的说服了别人,人们才会愿意为此埋单。

 

本文翻译自:《User Stories: As a [UX Designer] I want to [embrace Agile] so that [I can make my projects user-centered]》

本文由@ vivi 翻译发布于人人都是产品经理,未经许可,禁止转载

题图来自Unspalsh, 基于CC0协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
评论
欢迎留言讨论~!
  1. 作为译文而言,翻译水平无可指责,但原作是有上下文、有与这篇译文不同的阅读群体的,你应当考虑到这些差异,会点进来看这篇文章的大部分应该是希望了解并学习“用户故事”这种设计方法,而不是来看“用户故事很好用”,大家并不知道它是什么样子的。这篇译文描述了用户故事的特质和优点,却没有具体案例,实在不适合单独阅读。译者可以看下站内同样介绍用户故事的几篇文章的结构对比下。

    回复
    1. 好的,谢谢。

      回复
  2. 首先感谢分享。其次文章结构上确实有些难以理解,太多的理论和优点介绍,但我看完之后无法认识到用户故事具体是什么样子的。建议放几个实际案例和对应的用户故事,以便于不知道什么是“用户故事”的读者理解,而不只是告诉已经知道“用户故事”的读者这是个好东西。

    回复
  3. 目测作者是设计转产品,我猜的可对?

    回复
    1. 为什么这么说呢

      回复
    2. 因为工科背景的产品在年复一年与程序员的较量中已经会发现,就算他们不理解你的场景,只要按流程图、交互原型、数据流图实现功能,就肯定错不了~与其花心思讲故事,不如画图性价比高

      回复
    3. 花心思讲故事,其实是为了让程序员更好地去理解使用场景,以及实现的目标。流程图,原型图都是一种方式,去硬生生地把一件东西还原。就好像你看书一样,说了很多理论,你好像懂了,其实还不如一个故事来的简单。

      回复
    4. 团队合作大型项目讲究明确职能边界,标准工具就是能起到这个作用,摆一个故事在哪,研发跑偏了算谁的呢?绝大多数都是为了工资去工作的,并不会积极去理解项目,只想完成任务而已,讲故事太理想化

      回复
  4. 感觉作者的逻辑有点乱,说的全是大道理

    回复
    1. 请问能否具体指出一下?

      回复
  5. 说了一大推废话,不知道说些啥,举几个贴切的例子,通俗易懂点,你这用户体验极差

    回复
    1. 其实整个的核心就是:
      – 作为一个 。角色指的是做出行动和受益的人。
      – 我想要 。这是执行的动作。
      – 以便 。它是用户从操作中获得的附加值。

      去叙述用户场景,其实文中,作者是有举例的,但是并不多。文中可能没有提及太多的例子,所以造成了你觉得废话连篇,可能是我翻译的不够到位,或者你可以看一下原文。看看是否对你会有更大的帮助?谢谢

      回复