用书签打开书本
通过插图

要做的工作

编者按:我们很高兴分享一段节选自吉姆·卡尔巴赫的书,待办工作手册,题为“设计价值”,可通过罗森菲尔德媒体

在本章中,你将了解这些戏剧:

文章如下
  • 如何创建工作驱动的路线图
  • 使用作业故事来解决特定的设计问题
  • 如何架构解决方案的结构
  • 通过JTBD执导测试的假设

我曾经工作过的一家软件公司每季度都会举办一次名为“黑客周”的活动。这是一个开发人员“想做什么就做什么”的时代。给工程师时间玩技术,他们一定会找到下一个创新,至少理论上是这样的。

黑客周对我们来说是件大事。几十个人组织了这次会议,公司里的每个开发人员都停下工作来为这次会议做贡献。虽然代价高昂,但我们致力于“黑客周”。毕竟,新的软件产品来自于新的开发,对吗?

它是这样进行的:组成小团队,拼凑开始的项目,代表一些新技术的使用。在这周的最后,一个小组评判了几十个出现的概念,并对获奖的“解决方案”进行奖励。

但在我们这里,hackweek就像是在错误的方向拍摄的猎枪,而蒙住眼睛,希望击中目标。其结果是不可避免地寻找解决问题的概念的集合。这是在其最好的创新影院。

为了公平起见,并不是所有的这种形式的比赛都是不好的。一些组织协调与战略需要或客户需要这种形式的比赛。而且肯定的是,它也是很好的柔性创意肌肉和跨团队协作的做法。但由于其成本和不准确,这种形式的比赛往往是在生产使用的概念基本上是无效的。

问题并不是缺乏公司通常都在其中游弋的想法。和我们一样,许多组织对创新都有达尔文主义的观点:产生越来越多的想法,最好的肯定会上升到顶端。换言之,在大海捞针的时候,最好的办法是少加干草。

问题是知道该追求什么样的想法。创新活动的目标不应该是收集尽可能多的创意,而应该是找到对你所服务的人最重要的创意。

但更重要的是,真正的挑战是克服组织中抑制好想法的自然力量。其中最主要的是不确定性,这是阻碍创新的主要因素。对厌恶风险的经理人来说,新想法是一场赌博,即使在一个高保真的原型中得到了很好的表达。

JTBD提供了一种方法,通过首先确定要解决的正确问题来增加成功的机会。然后JTBD为您提供了前进的决策标准:押注于解决未满足需求的解决方案,以创造盈利的差异化。

首先专注于为个人完成主要的工作,并满足他们与工作相关的需求。从这个角度来看,在如何评估概念方面,编程马拉松和其他产生想法的工作可以被JTBD定义为输入和输出。

在理解了工作前景并定义了您所追求的价值之后,您可以继续使用JTBD思想来使团队围绕解决方案的设计进行协调。根据您的JTBD场景创建路线图,以设置公共方向。然后使用作业故事让每个人都站在同一个页面上,将本地设计工作与全局联系起来,并构建解决方案的结构。JTBD还可以指导您进行测试团队假设的实验。

创建一个开发路线图#第二节

在最高层次上,路线图是开发事件的序列——特性和功能将被构建的相对时间顺序。必威官网网址多少路线图是团队协调工作的中心参考点。它们显示了前进的道路,而没有定义单独的任务。

在敏捷和精益努力的年龄,路线图已经得到了一个不好的名声。人们很快指出,这是理所当然的,长期的计划注定失败:优先级的变化,不可预见的挑战出现,和时间表打滑。该解决方案,他们可能会说,是因为需要有没有长期的计划和对工作的灵活性,以改变短期举措。

但同时提供决策权力到地方的开发团队是有道理的,仍然是需要的整体对齐。查看路线图的另一种方法是看他们不是作为一个明确的项目计划,但由于您将如何创建一个产品,它的客户将价值的愿景。发展蓝图并非一成不变未来活动的预测,而是一种为的步骤顺序您的团队将设计解决方案提供了透明度。

路线图中的信息可以帮助整个组织保持一致,而不仅仅是开发人员。它是一种战略沟通工具,反映意图和方向。更重要的是,道路映射不仅仅是关于工件的:它是关于获得对您要去哪里的共同理解。从这个意义上说,路线图占据了远景和详细项目计划之间的空间。

JTBD可以帮助创建聚焦于组织打算为客户创建和交付的价值的路线图。诀窍在于找到正确的问题来解决。使用来自JTBD调查的见解来制定基于实际客户需求的路线图。

规划前进的道路#第三节

对于道路测绘的具体方法,我推荐这本书产品路线图重新由C.托德·隆巴多,布鲁斯·麦卡锡,埃文瑞安,和迈克尔·康纳斯。[1]在其中,作者清楚地阐明了创建有意义的产品路线图的步骤。

JTBD在满足客户需求方面扮演着关键角色,正如作者所写的那样:“我们建议从你打算交付的价值开始,这些价值将随着时间的推移而积累起来,从而实现你的愿景。”这通常是一组高级客户的需求、问题或需要完成的工作。”

他们的方法分解了好产品路线图的四个关键要素:

  • 产品愿景:愿景概述了你的客户将如何从你的产品中获益。工作测试人员将如何从解决方案中获益?解决方案到位后,完成工作会是什么样子?
  • 业务目标:路线图必须与组织的战略和目标相一致。业务目标对于度量进展非常重要。
  • Timefames:好的路线图不是承诺一个具体的日期,而是按照工作的顺序和为完成工作设定一个宽泛的时间表。
  • 主题:这些是客户在完成作业时所面临的关键问题,或需求的对齐的整体解决方案,以创建集群。JTBD有助于框架尤其是你的路线图的主题。

图5.1显示了他们书中一个虚构公司wom面糊软管的基本路线图概览示例,说明了这些主要组件。还要注意声明,指出路线图可能会发生变化。

图5.1:书中路线图的主要组件示例产品路线图重新2

将这些放在一起,创建jtbd驱动的路线图的过程可以分为四个阶段。

步骤1:定义解决方案方向。

定义你的整体产品策略的各个元素,以便就你将如何使用它们达成一致。除了您的解决方案愿景之外,还应与团队一起定义以下内容:

  • 使命:你的商业意图是什么?使命是关于组织希望最终实现的目标。
  • 价值观:你的信仰和理想是什么?你的组织的哲学和解决方案是什么?价值观定义了团队的哲学和信念。
  • 业务目标:您的产品将为组织实现哪些具体目标?用结果而不是产出来描述这些。

第二步:确定客户的需求。

其次,确定客户的需求追求。这里,作者产品路线图重新强调路线图在实际客户需求中的重要性。JTBD是这一步骤的核心。他们写道:

“确定客户需求是路线图过程中最重要的方面。路线图应该表达那些客户的需求。因此,路线图上的大多数项目将来自于客户需要完成的工作或客户必须解决的问题。”

正如在第2章“JTBD的核心概念”中概述的那样,需求是分层的——从高层次的期望到主要工作,从子工作到微观工作。找出要探索的顶层工作,然后深入到具体的主题目标。

所谓的“价值主题”可能来自工作地图。找出最需要服务的领域,并将这些阶段作为路线图主题的类别。或者,您可以对需要进行聚类的主题进行排序,这些主题不一定遵循作业映射的时间顺序。重要的一点是在对客户要做的工作的实际观察中确定路线图的划分,并将时间线与之对齐。

第3步:设置时间表。

其次,创造价值的主题,你的团队会努力的方向的序列。时间表可以是绝对的,相对的,或两者的混合。有具体日期的绝对时限进行改变,这反过来会引起混淆或低于预期的风险。

相对的时间线提供了更多的灵活性,但仍然提供了对未来和原因的洞察。有各种各样的术语可供使用,但时间线通常分为三个阶段:近期、中期和长期。例子包括“现在,以后,将来”或“去,下一个,以后”或类似的东西。找出最适合你的。

步骤4:使开发工作与路线图保持一致。

最后,将设计和创建的具体解决方案概念化。使用工作故事将整个项目意图与客户需求联系起来,在下一节中概述。然后,围绕完成整个工作或其中与您的业务最具战略相关性的部分,对解决方案进行概念化。

在创建路线图之后,您可能需要详细的项目计划来跟踪进度。一个简单的看板板在很多情况下都可以达到这个目的。或者,对于更复杂的软件开发工作,可能需要跟踪软件。在敏捷工作中,史诗计划和sprint计划在你有了一个总体路线图之后才开始。

搭售的总体规划,以客户的需求给出了设计和开发团队,他们正在建设一些事情给客户的感觉。继续专注于客户的需求,有助于避免建设的东西你的客户不想要的。工作的性质保持不变,甚至功能可能转变。接地在JTBD路线图确保了其长寿和吸收能力会有所改变。

了解更多关于这个戏#第四节

伦巴多、C·托德、布鲁斯·麦卡锡、埃文·瑞安和迈克尔·康纳斯。[3]重新发布产品路线图。塞瓦斯托波尔,CA: O ' reilly, 2018年。

这本书提炼了丰富的实用信息到技术路线图上的一个简明指南。作者竭尽全力提供许多例子和故事来自真实世界的情况。他们用一个现实的,现代的方法,用于创建驱动,部分由JTBD的路线图。

对齐团队工作的故事#第五节

敏捷开发使团队和组织能够以灵活的方式工作。这种方法始于软件开发,但已经扩展到其他领域,包括政府和军队。敏捷开发的原则几乎可以应用于任何领域。

敏捷的一个关键部分是要打破的努力投入到工作的各个单位。用户情景是从最终用户的角度对特性和功能的简短描述。团队可以只关注整体的一小部分,并以可控的方式取得进展。

用户故事通常以三部分格式编写。第一个元素表示用户在系统中的角色。第二点是指一个人完成一项任务的能力。最后一部分通常描述使用该功能的好处或原因。

尽管特定的样式可能有所不同,但典型的用户情景类似于以下内容:

作为一名<角色>我能<能力>,使<好处>

在使用这种格式的故事,例子包括:

  • 作为一个系统管理员,我可以根据文件大小、创建日期和修改日期指定要备份的文件或文件夹。
  • 作为用户,我可以指示不备份的文件夹,这样我的驱动器就不会充满了我不需要保存的东西。
  • 作为用户,我想更新文档的名称,以便对其进行分类。

对于任何给定的系统,都可能有数百个用户故事。有些可以是非常细粒度的,例如描述单个按钮以及用户单击它的原因。然后,故事被组织到待建功能的backlog或repository中。团队在sprint或两到四周的工作周期中分解用户故事的逻辑组。

工作的故事#第六节

尽管用户情景有助于分解工作,但它们通常无法将正在构建的解决方案与用户需求联系起来。他们没有迹象表明为什么有人会以某种方式表现,以及完成工作所需的东西。事实上,用户故事通常来源于正在构建的功能,而不是观察实际行为。

工作的故事是用户故事的替代品。他们遵循传统,把努力分解成更小的部分,但通过JTBD镜头。这项技术最早是由Intercom的产品开发团队首创的,Intercom是一个领先的营销传播解决方案。他们希望避免用先入为主的解决方案来领导设计师,并将开发与公司愿景和战略联系起来。

对讲机产品经理保罗·亚当斯(Paul Adams)第一次写下了工作故事,他说:“我们把工作中的每一个设计问题都框起来,重点放在触发事件或情况、动机和目标以及预期结果上。”[4]

因此,他们的工作故事格式也有三个部分。但是,工作故事并没有聚焦于一般的角色,比如“用户”或“管理员”,而是以强调情境和背景开始,而不是个人:

当[情况],我想[动机],所以我可以[预期的结果]。

工作经历的例子包括:

  • 当一个重要的新客户注册时,我希望得到通知,以便我可以开始与那个人对话。
  • 当我访问别人的个人资料页,我想看看他们有多少职位各有主题,使我有,他们有最多的知识的理解。
  • 当我使用的应用程序多次,我得到碰一碰贡献,使我深受鼓舞参加。

JTBD的作者和领导者Alan Klement在改进工作故事格式方面做了大量工作。[5]他认为,增加更多有关环境的信息可以更好地显示因果关系。关注上下文将注意力从人物角色转移到情境中。克莱门特建议,不要写模糊的情况,而是要尽可能具体。

例如,考虑作业故事的第一要素这三种可能的情况:

  • 当我饿了......
  • 当我迷路的时候…
  • 当我想检查我的电子邮件…

相反,克莱门特建议详细描述情况:

  • 当我饿了,迟到了,不知道什么时候再吃东西,担心很快就会因饥饿而疲惫易怒……
  • 当我在一个城市,我从来没有去过,我迷路了,不知道当地的语言,很担心我会浪费我的时间的地方,我不希望在...
  • 当我想查看我的电子邮件,但不想让我周围的人知道我在查看我的电子邮件,因为他们会认为我很粗鲁…

每个示例场景都为设计适当的解决方案提供了更多的上下文。

工作故事#第七节

工作故事是模块化的,为设计人员和开发人员提供了以不同方式解决问题的灵活性。工作故事基于现实世界的洞察力,在指导解决方案方面,它们比用户故事更强大。但是创建工作故事的形式比其他JTBD技术更加自由。不过,你还是可以遵循一些模式的。使用第2章中的元素,我建议作业故事采用以下结构:

当I [+环境工作阶段/步骤],我想[微作业],所以可以[需要。

例子:

  • 当我是每天更新我的社交媒体feed的顶级海报之一时,我想把它显示在我的个人资料中,这样我就可以增加作为这方面专家的认知度。
  • 当我的同时完成一个艺术项目所需的材料用完了,我想找到替代材料,这样我可以最大限度地发挥我的电流供应的使用次数。
  • 当我为我的通勤和迟到做准备时,我想知道我的旅程中目前的天气,这样我可以最小化淋湿的可能性。

考虑最后一个例子。第一个元素结合了有关环境的信息(迟到)完成主要工作(上班)在程序的某一阶段内(准备上班)。

第二个元素指向一个更小的步骤或微作业(检查预测)。应该制定没有提及具体的技术,而是要具体足以让设计人员和开发人员创建一个特定的功能。

最后,最后一个元素可以直接从您的需求列表中获取。在这种情况下,作业执行者(通勤)要避免显示到办公室湿(尽量减少湿着上班的机会)。您可以直接在任务故事陈述的制定充分利用你的JTBD景观已发现元素的研究。

在研究这本书中,我遇到的各种替代办法来制定工作的故事。安德烈山,JTBD对社交媒体重要拥护者,提出了一种略有不同的方法。她认为直接指向一个功能或者某种解决方案,从而明确地从问题空间到解空间穿越中间元素。她的基本格式如下:

当我[环境],我想[解决能力],所以我可以[需要]。

关于上一个上下班例子的工作故事可能是这样的:

当我准备通勤上班时,我想把天气预报推送到我的手机上,这样我就能把淋雨到达的几率降到最低。

Steph Troeph是英国的一名研究人员和JTBD讲师,他以另一种方式研究工作故事。她用这个公式来思考它们:

当我[环境]时,我想[工作],以便[解决方案提供的好处]。

不管你怎么解释,关键是找到一个一致的结构并坚持下去。你最终得到的形式需要适合你的团队和你的情况。

乔布斯的故事#第八节

最终,工作故事扎了本地的设计和开发工作,以更广阔的JTBD框架。由于工作的故事的格式包括背景细节,他们是便于携带。换句话说,工作故事应该有意义,而不必知道大JTBD景观或作业地图。其结果是,工作的故事有一个经常需要敏捷设计和开发团队更加“插件和播放”的多功能性。

例如,敏捷规划人员可以像管理用户故事一样管理工作故事的积压。如果一个给定的sprint变慢了,或者改变了方向,没有处理的故事就可以转移到下一个sprint。在设计和开发阶段,对要完成的较小任务有更小的、自包含的描述是有好处的。

但需要说明的是:我发现工作故事很典型完全替换用于开发的用户情景。相反,工作故事引导并构建解决方案的概念化,而不是跟踪实现。它们是创建或确定概念方向和设计的最佳设计工具。开发人员和工程师可能仍然需要用户故事来衡量烧坏率和总体进度。

你的工作地图为你的JTBD环境提供了一个整体的方向,并且允许你集中精力在一个特定的区域进行设计和开发。路线图为您提供了一个高层次的开发序列和规划活动的基本原理。工作故事更具体,并指导本地设计和开发功能和功能。

请按照以下步骤根据您的JTBD研究,以创造就业故事:

第一步:了解工作阶段和环境。

底座上之前的采访和观察的相关工作和环境。对于您的解决方案开发的每个区域,考虑的主要工作步骤。然后向下钻取并列出小步骤,微作业,从而使用制定JTBD的规则。还确定了适用于特别是主要工作的一部分的情况。

根据你之前研究的深度以及你和你的团队对工作的理解程度,你可能不需要做更多的研究来创建和验证工作故事。再次和人们交谈并深入了解他们的具体问题和目标从来都不是一个坏主意。在额外的面试中,问“怎么做?”?“直到你对次级目标和目标有了更细致的理解。

第二步:构思工作故事。

作为一个团队,编写特定于您的设计和开发工作的作业故事。为工作故事确定一种一致的格式,并坚持下去。

努力写出独特的、相互排斥的故事,针对特定的工作和环境。避免冗余。例如,在前面的示例中,您可能不需要将乘火车和乘汽车通勤分开。开发最重要的工作故事,并集中在有限的部分上。你可能会在每个项目或sprint中得到3到8个工作故事。

第三步:为工作故事解答。

使工作故事对整个团队可见和透明,以解决工作故事。例如,在头脑风暴会议上发布一个相关的工作故事列表,让每个人都能看到。或者在设计评论开始时列出工作故事,这样团队就有了发表评论的环境。使用JTBD指导设计和开发决策。

然后也可以使用工作故事来回顾解决方案的适当性。首先,设计团队可以使用与项目相关的工作故事作为启发。他们应该不断地询问他们的设计是否符合用户在工作故事中设定的目标。

然后,您就可以针对作业场景与用户一起测试解决方案。向用户展示你的解决方案(例如,作为一个模型或原型),并询问他们如何处理工作故事。这可以通过面试的方式或者调查的方式来完成。工作故事最终成为衡量设计成功与否的标准。

在设计产品或服务时,工作故事让你回过头来看看工作的背景。在这方面,工作故事填补了客户观察和解决方案开发之间的一个重要缺口,将对客户需求的洞察与个人特性和开发工作联系起来。

相关办法:需要声明#第9节

设计思维是创造性解决问题的广泛框架。它植根于以人为本的方法,寻求对人们产生深刻的同情,然后设计出满足他们需求的解决方案。在设计思维中,在产生解决方案的选项之前确定要解决的问题是很重要的。

从研究中提炼见解的一种技术是生成需求声明,在形式上非常类似于工作故事。但是这些陈述与第二章中定义的“需求”不同,因为设计思维中的需求陈述并不仅仅局限于完成一项主要工作的结果,它们在本质上是有抱负的。

在设计思维需要说明也往往更集中于一个角色或个人,而不是情节。例如,写诺曼尼尔森集团,吉本斯萨拉是指代表一个系统的用户一个点的视图需要语句:[6]“用户需求语句是一个可操作的问题语句,用于总结特定用户是谁、用户的需求以及需求对该用户重要的原因。”

与作业故事一样,需求声明有三个组件:用户、需求和目标。该用户对应于基于研究基于目标的人物(第4章,“定义值”所概述)。一个需要表达独立的功能或技术。该目标是满足需求的结果。吉本斯举了一个例子:

Alieda,两个多任务,技术娴熟的母亲,需要没有给她留下的舒适区,以花更多的时间做的事情,真正的问题快速而准确地比较选择。

请注意,在这句话的结尾,“做真正重要的事情”的洞察力是非常广泛和难以衡量的。另一方面,工作故事倾向于更具体的背景和结果。例如,通过工作故事的视角重写上述示例可能会产生如下结果:

当我在匆忙中同时处理多个任务时,我需要一种熟悉的方法来快速、自信地比较选项,这样我就可以将寻找解决方案所花的时间减到最少。

像设计思维需要报表,工作小说也为避免功能或技术提。然而,他们更针对特定的任务和它的上下文。尽管从设计思路都需要声明和工作的故事可以喂到创意生成的解决方案,工作故事将提供更直接的指导,但没有规定一个解决方案。

但是需要在设计思维上可以有很大的不同。例如,IBM的企业设计思维方法还包括生成语句的准则。[七]毫不奇怪,有三个部分:一个用户,需要和利益。下面是从IBM网站的例子:

开发人员需要一种方法来理解最小设计,这样他们可以更快地创建原型。

这个例子比吉本的方法更具体,但仍然避免提及具体的解决方案。没有“追求毕生梦想”之类的励志元素,而这些元素有时会出现在设计思维的其他地方。IBM的需求声明方法更接近于工作故事方法,但在描述使用环境方面也做得不够。

从某种意义上说,工作故事之间的差异,即使在格式和需求声明上有所不同,也表明了JTBD和设计思维之间的一个关键区别。前者更关注环境,而不是人的心理状态。当设计思维以获得对个体的移情为出发点时,JTBD试图在将情感和个人方面考虑在内之前,了解实现目标的情况。

了解更多关于这个戏# section10

克里门,艾伦。“用工作故事替换用户故事。”JTBD.info(2013);“写工作故事的5个技巧,”JTBD.info(2013);“用工作故事设计功能,”内部对讲系统(2015)。

克莱门特做了最广泛的工作,制定工作故事技巧。这三篇文章来创建他们勾勒betway体育注册的基础。该技术已略有演变,但克莱门特明确指出他是如何更新他的做法。克莱门特和其他人对他们的发展努力使用广泛发布,但这些资源开始。

范·德·Keuken,马克西姆。“使用作业故事和乔布斯待完成的软件需求工程”。论文,乌得勒支大学,2017年。

本文提供项目的工作故事如何应用于日期详细的调查。说明工作的历史故事后,范·德·Keuken表现为在实践中看到工作中的故事,他的应用原研变化的结果。这项工作大大有助于制定工作的故事软件需求工程的一个比较正式的一部分。

关于作者

吉姆·卡尔巴赫的照片

吉姆·卡尔巴赫

吉姆Kalbach是著名的作家,演讲家,并在用户体验设计,信息架构和战略讲师。他目前是客户体验的主管壁画领先的在线白板。吉姆与大公司,如eBay,奥迪,SONY,Elsevier科学,律商联讯和Citrix合作。

在德国生活了15年,2013年回到美国之前,Jim是欧洲信息架构会议的联合创始人和长期组织者。他还共同创立了IA Konferenz,一个领先的用户体验设计活动在德国。之前Jim是box & Arrows的助理编辑,这是一个著名的用户体验信息杂志。2005年和2007年,他还在信息架构研究所的顾问委员会任职。

吉姆的主要工作的创造性出口外面的音乐;他扮演的泽西城,在那里他目前的生活即兴演奏和爵士的连续技低音。他的德国出生的妻子,娜塔莉,是一个众所周知的混合媒体艺术家。2007年,吉姆发表了他的第一个完整长度的书,设计Web导航(O'Reilly,2007年)。他的第二本书,映射的经历(O’reilly, 2016),重点研究了可视化在战略和创新中的作用。他的博客experiencinginformation.com推特在@jimkalbach下面。

没有评论

有话要说吗?

我们已经关闭了评论,但你可以看到人们说的话,我们没有这样过。

更多来自阿拉巴马州

betway必威app

语音驱动的内容挑战了我们可用性测试的许多方法。普雷斯顿把它们变成了媒体本身的机会和优势。
内容

跨文化设计

在这段来自跨文化设计的节选中,塞翁戈·阿克佩姆讨论了当你希望接触到全球受众时必须考虑的版式设计的许多方面。
设计