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

今日绵阳 阅读(580)

每个人都是产品经理,我想昨天分享

对于理论和长期需求的文章,人们可以更多地记住故事的场景,通过简短但详细的故事描述,让程序员和设计师理解,产品是用心的,从而为用户提供与设计。服务,而不是产品单方面的猜测。

image.php?url=0MuR5gEDiw

我们来看一个简单但功能强大的工具。这是一种很好的设计方法,您可以将其应用于所有项目,同时加强所有利益相关方的协作。

敏捷设计的核心部分是用户需求,即用户故事。有很多关于用户体验和敏捷开发的文章,很多人都在谈论敏捷开发如何使用户体验不友好,两种方法如何不能协同工作等等,并且很难应用于软件项目,并与其他学科合作。这很有挑战性。虽然我们正在努力工作,但我们可能会在许多缺点上妥协“是”,我们不会在文章中解决它们。

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

为什么?

用户故事简短,具体且以目标为导向。这句话通常具有以下结构:“作为一个,我想这样做。”用户故事是协作设计工具,期望所有项目利益相关者参与用户故事的定义和排序。用户故事将项目集中在这些用户视角上。

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

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

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

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

相反,想一想:

“我”可以是任何专门研究一种或多种乐器的音乐家。如果你认为“我”是一个沉重的摇滚吉他手,那么回过头来想想键盘手,歌手,贝司手和鼓手.或者也许是一位古典作曲家正在起草歌剧,并希望看到一些关于音乐的想法。 “我”也是任何一种作曲家。这可能很容易听,电子,或精致,沉重的摇滚音乐。或者,它可能是一位古典主义者,他被委托为你以前从未见过的电影编写原声带。

大!现在我们已经设法让团队考虑“更多可能性”以适应我们的用户,我们可以创建用户故事。用户故事的格式迫使我们从他人的角度思考,同时集中他们的需求,并且为了换位思考,我们可以将自己置于用户的角度。

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

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

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

用户故事易于理解

如果您来自“旧学校”,您可能会记住用户使用案例。也许用户故事会提醒您有关用户的所有信息。好吧,尽管存在一些相似之处,但差异会使用户故事变得更好。

用例具有特定的语法和结构,因此并非所有人都参与定义它们,并且只有负责定义需求或功能规范的团队或人员才能编写它们。用例是客户端(有时是用户和开发团队)之间的桥梁,所以为了推广“轮胎摆动”模型,我们看到会发生什么.

image.php?url=0MuR5g9ANN

在上面显示的模型中,我们发现每个人对用户的需求分析存在一些可怕的错误。但是用户故事以其简洁和专注,提供了避免这种情况的完美方式。参与团队的任何人都可以参加。他/她只需要知道特定语法的相关性:

作为一个。角色是指行为和利益的人。我想要。这是执行的动作。为了。它是用户从操作中获得的附加值。

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

用户故事是协作的

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

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

用户故事讲述了现在和未来

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

用户故事具有正确的详细程度。在更抽象的层面上,我们有“史诗”。在敏捷开发中,“epics”用于对所需功能进行高级概述。因此,他们收集了一组用户故事。如果要构建关联图,则epis将是一组常见用户素材的名称。 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]》

本文由