本篇内容
  • 酝酿和使功能视觉化
  • 实施优先级排列过程
  • 维持良好张力
  • 准备活动和文档

从定义到设计

除非你的项目是世外桃源,否则你会有预算限制、时间期限,或者两者都有,这使你需要以某种方式关注和管理上述列表。

之前第四篇介绍了不同的项目方法或方法论,以及这些方法将会如何影响你和其他团队成员及利益相关方合作的方式。相比将定义和设计阶段通过审批步骤隔离开的瀑布模型,改进式瀑布模型的不同阶段存在重叠。

本章讨论在定义和设计阶段重叠部分可能发生的活动。
流程中的这个时间点适合进行以下几方面的工作。

  • 酝酿和可视化在利益相关方访谈或用户研究中没有包含到的功能点。在排列优先级之前和团队成员开展这项工作能让你思考和计划创新功能,从而满足业务需求和用户需求。
  • 为项目需求排列优先级。集合列表中包括业务需求、用户需求和团队成员想法,并确定其在满足项目目标方面的重要性级别。在这一点上,你将同开发团队一起共同确定为达成每个目标需要努力的程度。
  • 计划在设计中使用的活动和文档。这决定了你将如何与团队成员合作,以及其他人会从你这得到什么类型的工具或文档,如站点地图和线框图。
1
2
3
4
-种常见场景
已经定义和确认好了需求,并且正在按计划设计网站功能。在设计过程中,你发现提供特定工具将会对用户非常有用。想法很不错,但是并没有描述那种新工具的需求,因此,**如果现在要在项目中增加新工具,就需要对需求的优先级进行变更**。
你必须为变更需求列表提出强有力的理由,特别是如果这么做还意味着其他什么需求需要从列表中删除(决定删除什么需求需要时间)——或者会延误项目进度时。很可能只是简单地因为想法出现得太晚而不能被包含在项目中。
**尽管新想法可能会出现在项目的任意时间点,在完成需求收集之后和排列优先级之前,预留一些时间来酝酿新功能,这样会帮助你更旱地产生这些想法并提高它们被包含在需求中的可能性。** 它确保你花一些时间思考创新功能点,这些功能点可能是业务利益相关方或用户没有想到的。

9.1 酝酿和使功能视觉化

用户体验设计师拥有一系列特殊技能,可以帮助在描述(比如需求)和图景(比如网页地图和线框图)的心智差距之间搭桥。很多时候,人们可能会讨论需求并因为对方的语言争吵,而通常情况下,在看到以视觉方式呈现的概念之前,他们也许并未真正明白对方的意思。
另一方面,如果你过快深入到特定视觉细节中,你将会在解决大问题(如用户是否应该在一开始就填写特定表单)之前就陷入对小细节的讨论的风险。

有很多在项目中使用的概念设计技术可以帮你视觉化概念、流程和故事,它们可以使你在详细设计开始之前就吸引其他人参与。这些技术也可以在排列优先级之前帮你产生应加入到需求文档中的功能需求。
其中一种技术是协同创建故事版.在头脑风暴会议中,视觉化某一特定用户的使用情景,并将其在纸上或者白板上画成草图。接着,用户体验设计师以这些草图为基础添加更多细节。

9.1.1 故事版的基本流程

在故事版的准备阶段,你需要创建一个希望探索的使用场景列表。为了创建使用场景,思考下列问题并在这一阶段增加答案。

  • 谁是这一场景的主要用户?他扮演何种角色?这就是你的用户模型或人物角色派上用场的地方了。如果你已经得到了这部分结论,将它们拿到会议上讨论,这会有利于在讨论中聚焦,也可以确保项目团队对于如何在设计阶段使用用户建模工具有更好的理解。
  • 所选用户是第一次使用这个网站吗?如果不是,那么他是偶尔使用还是经常使用呢?这将影响你们讨论功能的所处的层级;大量的选择会使新手用户感受到压力,而熟练用户可能很喜欢这些选择。你也许希望从头到尾再讨论一遍使用场景,以发现每一类群体可能需要的不同功能,例如对新手用户的基于情境的使用帮助或者让熟练用户自定义功能。
  • 是哪种迫切需求驱使用户访问网站?用户希望完成什么及其中原因?可通过查看商业或用户需求中的高层次任务来产生想法,比如“发现推荐产品”。也许用户需要找到推荐产品是因为他需要一双雪地靴并且希望靴子不会渗漏而将脚弄湿。

在这个阶段召集参与头脑风暴的团队。这个团队可以只有你和另一人,也可以是一个由3、4人组成的小组(也可能人更多,但是这就会使得让大家都有效地围在白板旁并专注于手头的任务变难。)理想地,小组中至少有一个人负责呈现用户的观点,另一个人(例如,业务利益相关方或者业务分析师,如果这个项目中有的话)应该负责呈现业务观点。这并不意味着你不能转换视角,你可以并且应该在整个讨论过程中尽可能地考虑用户和业务需求。

如果你的团队已经组建好,请告诉他们此活动的目是理解一些需要满足的业务和用户需求功能点,并聚焦于后续设计。展示上面列出问题的答案以及需要讨论的情境列表。然后走到白板前(或者拿起笔和纸),询问团队关于情境的问题。

  • 用户如何访问此同站?考虑搜索引擎、横幅广告、口口相传或其他方式;
  • 如果脑海中浮现的是在线搜索方式,那么此需求是否准确地反映了功能或活动类型(如,因SEO需求而进行标签),以支持搜索?
  • 一旦用户来到网站,用户看到的东西会跟他们的需求相关吗?
  • 用户会使用什么路径来完成他们的任务?高度细节化地描述这一过程。
  • 任务有涉及到其他人吗?如果有,他们如何参与(电话、电子邮件、网站的协作功能),他们会如何影响主要用户的决策或行为?
  • 在整个过程中,用户会在哪里需要帮助?怎样获得帮助?
  • 当用户完成任务会发生什么——一种常见设计错误是认为用户任务结束时你的任务也结束了,但此时很适合鼓励用户探索网站的其他部分或让他们考虑购买相关产品。

在使用故事版以及其他类型的草图工具(如用户流图和概念线框图)时需要记住的是,这样的工具主要是为了集思广益。尽管一些很棒的观点来自这些活动,但是并不意味着这些草稿就是详细设计。因为它们的草图形式(相对于原型形式),我们可以很容易明白这一事实,但是它仍然受到业务利益相关方的特别重视,因为即使是在草图中看到的视觉化功能,有时也会让人们认为它们会在最终产品中出现。
另外一种危险是,参与者可能会在用户界面元素的争论中分散注意力,如某样东西应该放在页面中还是应该做成弹出框。很容易陷入细节讨论。因为相比使用情境所应解决的更大问题,那类问题通常更容易(或者更熟练)解决。为了提高做事效率并高效利用时间,不要让参与者讨论与优先级列表无关的事情。
它把我们带入到过程中的下一步。对你花费很多时间收集的美丽需求进行排序,此过程通常充满活力,有时也会很痛苦。

内容白板

9.2 实施优先级排列过程

你已经获得了一组业务需求,其中充斥着基于用户需求和你构思的功能。现在到了最有难度的部分之一:把他们削减到只剩下有重要价值的需求,对把这些需求进行优先级排序,生成排序列表

因为你已经走查了所有需要被排序的需求,拥有了项目目标以及用户模型,以帮你专注于对目标用户群的讨论。除你之外,在你作为用户代言人的角色中,排列优先级的过程还应该包括。

  • 代言业务观点的人(业务代言人)。
  • 代言开发团队观点的人(开发代言人)。
  • 代言项目需求的人(例如项目经理)。此人可能无需参加排列优先级的会议,但是需要对影响优先级的因素(如项目时间点和预算)设置限制,并确保最终的优先级列表满足这些因素。
1
2
3
用户体验设计师在优先级排列中的角色
很容易将排列优先级看做是项目负责人、项目经理和开发团队领导共同的责任,而不太容易将其视为用户体验设计师的任务。但没有什么比这离事实更远。
对优先级的讨论决定是否能制定出成功的解决方案。用户体验设计师有责任用他们的专业技能来支撑这些重要讨论。

通过走查每一个需求,优先级排列团队需要回答下列问题。

  • 在业务方面的重要程度如何?需求在达成一个或更多项目目标方面的重要性如何?如果去掉这个需求,会产生多大影响?
  • 对用户来说重要程度如何?这个需求满足了普通用户吗(或者它对主要用户群有重要影响吗?)如果没有这个需求,对用户体验会有怎样的影响?有没有其他类似的需求与之竞争?对于最后一个问题,要注意到的是,同一问题的多种解决方案之间会互相竞争并使用户感到困惑(也需要更多的努力来提供方案)。如果用户对最近几年才开发出来的选项不熟悉,你应该先从一个较小功能集开始。
  • 开发这个需求的技术可行性如何?需要多长时间开发?如果你正在使用一个相对较新的技术,估算的时间应该更长一些。
  • 开发这个需求的资源可行性怎么样?项目团队是否足够的人力、技术以及资金来开发这个需求?要考虑到购买和学习新技术工具的投入。

创建工作表单来收集为需求所做的决定。这可能包括基于上述问题进行的低、中、高的评分,或者你可以使用数值来度量,通过为每个需求指定一个数值来排序。随着你完成列表,你可能发现需要将类似的需求合并或将大的需求分解成一系列 代表独立工作单元的小需求。

要记住,这个系统只是简单地帮你分类和排列优先级,它并非对需求可行性的科学分析。然而,它在管理大列表、激发讨论以及掌握相对重要性方面非常有用。

为类别赋值会在优先级团队中激发大量讨论。你要如何帮助开展讨论和制定决策呢?你可以做的最重要的两件事是,了解(有时是提出)不同的观点,这是定义平衡解决方案的关键;帮助解决项目组内的冲突。

首先,我们讨论一下如何在优先级排列过程中提出正确观点。这涉及到在用户代表、业务代表和开发者代表之间创建和维持良好张力,因为它可以确保得到一种提供良好用户体验的平衡解决方案,满足项目的资源限制并同业务目标契合。

9.3 维持良好张力

在收集需求时,会遍历项目剩余部分,你可能会注意到在团队讨论中有三种角色在相互拉扯。

  • 业务代表:代表业务需求的团队成员,并且要保证业务需求尽可能被忠实地搜集和满足。业务代表最关心的事情包括满足公司和部门的战略目标,确保在项目过程中没有遗失业务观点,设置和保持对项目目标的关注
  • 用户代表:代表体验此网站的主要用户需求和观点的团队成员。用户代表的主要关注包括确保网站满足可用性方面的预期,提供满意和吸引人的体验,并鼓励支持项目目标的行为
  • 开发人员代表:他们代表技术和质量保障团队的需求和约束。他们最关心的事情包括:确保开发团队有效工作并且不超出资源范围,提供产品来满足用户和业务利益相关方期望的质量标准。

可以将这种景象形象的描述为三个代表在拔河。如果三者之间的张力保持良好(即没有哪一方完全占据优势),那么这三方可一起向良好平衡的解决方案努力,以满足项目目标。

每个团队成员都应该意识到,自己对维持项目平衡负有责任。如果一方占据主要地位,其他角色处于不利地位,这个项目就会面临无法达成目标的风险——或者为达到目标需要付出比预想大得多的代价。

在项目中你能扮演多种角色吗?绝对能,理想的情况是由不同的团队成员为每个角色承担主要责任,但并不意味着你不能偶尔换换角色。事实上,你可能在不同的讨论中承担不同的角色——甚至会随着话题的转变来转换角色。 虽然用户体验设计师最常扮演的是用户代表的角色,但是你需要理解全部三种角色的观点,并且为了创建成功的设计而保证它们一直得到代表。

尽管不时地转换角色很有益,但是对于自己承担多个角色的主要责任需要小心谨慎。随着项目的进展,你可能开始做出妥协方案,因为不会始终有“魔鬼代言人”来询问那些让你感到不舒服但却又非常重要的问题。如果你必须承担多个角色,请尝试找一名兼职人员来偶尔为你承担其他角色,以维持良好张力。

平衡关系

9.3.1 开发人员代表

如果你内心里是一名用户体验设计师,当你设身处地为他人着想需求和目标时,你会成长。这种技能是无价的,它既能帮你执行好用户代表的角色,同时也能确保你同团队中的其他人进行有效的沟通和合作。让我们花一点时间用这种技巧来概述开发人员代表的目标。

一个好的设计讨论关注开发人员代表应该在多大程度上参与和影响需求收集过程,以及他或她在这个过程中扮演的角色。 如果开发人员代表过早地表达技术上的可能性和限制,可能会削减一些产生创新型解决方案的头脑风暴活动。毕竟,现如今一些看起来天马行空的想法可能会通过额外的技术探索实现。 即使想法不可行,对它进行讨论也可能产生一些你能解决的潜在需求。

下面是开发人员代表的目标和责任。

满足时间和预算的要求。

  • 确保团队效率(避免冗余工作,确保有效沟通)。
  • 充分利用工具和可用平台。
  • 选择高效的附加工具。

确保后续变更不会带来大量额外工作。

  • 使解决方案可扩展,以满足未来增长。
  • 使解决方案模块化,让每个部分可以被方便修改。
  • 使解决方案尽可能标准化:越少修改购买的系统,所需开发工作就越少。

确保开发团队运转良好。

  • 通过提供相对有趣和有回报的工作来降低失误。
  • 降低由于紧迫时间带来的筋疲力尽的感觉。

然而,如果开发人员代表没有尽早参与讨论,团队可能已经沿着某条道路前行很远,并发现此时再继续前行会太昂贵,以开发人员代表最终放弃一个或者多个目标来结束讨论。最后但同样也非常重要的是,开发人员代表能带来一些技术上的能力,如一些新技术或尚未被充分开发的功能,它们是能使你的解决方案生动起来的重要来源。

一种有效方法是在头脑凤暴完成及高级别需求收集之后,优先级排序过程开始之前,和开发人员代表一起规划关键评审点。这可以让开发人员代表在过程的开始就探索合适的工具,并了解什么可行、什么不可行,一旦感觉某些主题和想法更重要以后,就可以在需求过程中更深入研究。

如果你觉得在一些需求收集会议中,开发人员的出席非常关键,确保你在下面两件事上已经同开发入员代表达成了一致:他们在会议中的角色,以及如何获取开发人员代表提出的潜在需求。你也可以录下这些会议,并在后续同开发人员代表一起回顾。在你处于设计的层层迷雾中时,可能你会很需要他们。

信息收集过程中清晰的沟通以及相关的后续工作,对在团队成员间建立紧密联系至关重要,也对优先级排列阶段是否顺利会有很大影响。但有时,尽管你已经尽力了。在排列需求的过程中,冲突仍然不可避免。

接下来聊一聊如何帮助项目组管理这些冲突。

9.3.2 管理优先级排列过程中的冲突

如果存在大的分歧,那么排列优先级可能很耗时。并且,如果分歧未得到解决,在设计和开发过程中也将继续显露。

引发这些冲突的原因可能有多种;这里列出其中一些常见的原因。

  • 项目组在项目目标或者潜在业务策略方面没有达成一致(可能是误解、遗忘或者不同意)。
  • 对立的团队成员坚持某组特定功能集(可能是这些功能让他们感兴趣,或者是他们已经向一些相关客户或利益相关方做出了承诺)。
  • 业务需求和用户需求之间存在冲突,这不容易解决。
  • 使用的技术对开发团队来说相对比较新,因此他们感觉很难估算。
1
2
3
4
5
6
7
8
9
选择你的战斗
在优先级排列过程中,一些你喜欢的功能可能被大幅削减。这很容易让你不高兴,特别是用户需求似乎是最常被从列表中拿掉时。
如果你充满热情地为每一项需求做同等的辩护,你需要承担自己制定优先级排序决策的风险。 当你决定推动一个特定需求或做出妥协时可以问自己下面列出的问题。
- 这个需求怎样支持项目目标?
- 它明显地降低了特定的风险吗?例如,它降低了用户收到垃圾邮件的可能性吗?它降低了网站的负面评价吗?
- 其他网站需求必须依赖它才能正常运转吗?
- 如果没有包含这个功能会有怎样的影响?
- 这个功能的价值是否值得付出开发努力(即使以其他你珍视的功能作为代价)?
如果你对以上所有问题都能做出强有力的回答,将这些答案带到优先级讨论会上。如果不能,可考虑去掉它,但要告诉其他人你的理由,要让其他人明白你是为了项目的整体利益而妥协。这将展现你考虑更大业务场景的能力,并巩固你在未来的优先级讨论和需求变更中的参与程度。

缺乏对项目方向的共识

团队对项目目标或者内在的业务策略没有达成一致。
让我们把冲突的来源分解为两个部分:沟通和协商一致。
如果项目目标或业务策略的沟通是问题所在,问问自己应该如何行动才能改进沟通效果。将目标或策略张贴到所有项目成员都能看到的地方是否有帮助(比如贴在作战指挥室或者线上协作区,或每张会议日程表的顶部)?或许需要对目标或策略进行视觉化的展现,以引起团队注意并激发团队成员对工作愿景的热忱。还记得本章最开始讲到的可视化技巧吗?使用这些技巧来创建一幅可以被容易打印并张贴的图片,或者在白板上快速地画出草稿来帮助团队成员保持沟通。

如果未能达成一致是问题所在,问问自己,如何才能帮助大家团结一致。 是否因为担心给用户发布一个非常不同的功能集,而导致冲突发生呢?或许可以用一些研究方法来帮助解决观点不一致,如问卷调研、访谈、实境调查。或许你可以利用实施技能来组织对不一致观点的结构化讨论,一个一个点的进行,直到它们被解决。

对青睐功能点的冲突

针锋相对的团队成员都坚持他们自己的功能集合。

设想培训部门主管需要集成的、基于主题的教程,而销售部门主管希望发布一个令人激动的视频短片来引发人们的兴趣。 同时,你还有其他领域的十多名业务利益相关方——并且他们都有迫切的需求。你如何帮助他们达成一致呢?

方法之一是应用你在之前读到的方法的变种:亲近图。用这种方法,你可以基于已有的需求集开展工作,或让利益相关方头脑风暴来得出他们自己的需求(如果在需求收集阶段的早期,此方法尤其有用)。如果基于现有需求开始工作,可以将它们打印到一页页单独的纸上,并将其粘贴到墙上。否则,就让利益相关方将他们想到的需求写到一些记事贴上。

你将需要以下几种资源。

  • 一间足够大的房间,能让利益相关方随意走动;并且要有一个或多个大的空白的墙,可以把记事贴贴在上面。
  • 一叠大记事贴,起码保证每名利益相关方一本。
  • 可以贴的磁贴(你可以在办公用品商店买到它们,它们有多种颜色),每名利益相关方各有10个一组的磁贴。

将主要利益相关方聚集在一个房间中,让他们每人花些时间写下关键需求点,一张记事贴上写一条。给他们15到20分钟的时间做这件事。

让每个人把需求贴在墙上。接着让他们上前解释贴在墙上的内容。当在房间中转完一圈后,尝试将类似的需求分到一组。

当完成了对需求的解释和分组后,将磁贴发下去。告诉利益相关方可以通过将磁贴贴在记事贴旁边来标示需求的优先级。 如,如果他们觉得某组需求很重要,可以选择把十个磁贴都贴到这个需求旁边,或者也可以将十个磁贴分给十个不同的需求。当人们贴好了磁贴后,你会很清晰地看到人们的喜好。

当大家完成了贴磁贴的工作后,让他们在结果前走一圈。当要求他们选择这种方式时,利益相关方将展示他们心中的优先级,这样接下来的对话就会变得容易一些。

这种方法可帮你快速启动优先级排列过程,或者重启由于不一致意见而导致的优先级排序暂停的情况。 一旦获得了契机和共识,完成优先级文档就会变得很容易。

在优先级排列活动的同时,应该着手准备接下来的全面设计工作。 准备工作计划将帮你估算创建详细设计所需的工作量,将你的工作与团队成员的工作整合起来,协调努力以达到项目里程碑。 下-小节涵盖了可帮助你计划的一些考虑。

优先级工作表

9.4 准备活动和文档

当完成了需求排序列表,理想情况下,还有一些早期概念设计工作(例如在本章前面介绍的故事版)后,项目经理会开始询问你将在设计中具体你将做些什么。
设计活动有几种不同类型,每一种类型都会对如何设计、花费多少时间以及最终输出的文档类型产生影响。 这是通常意义上的 “文档” ,它有多种类型,可以是白板草图、线框图或原型。
在接下来的三章中,我们将介绍一些交互设计中的活动。当你规划要采用的活动时,请记住下面这些问题。

  • 整个过程需要如何迭代?理想化地,你可以通过快速探索几个不同概念(例如通过草图)来开始交互设计,然后认可其中一个概念并对它进行深入设计。这种方法也可能涉及到把一种或多种设计概念呈现给用户。
  • 在设计过程中如何合作?如果你与团队在同一地点密切合作,在设计中可以更多地包含与他们共同召开的白板会议。 如果团队是分散的,考虑通过网络会议的方式同他们深度合作,以克服距离阻碍。
  • 如何同更大的团队分享设计文档?你是通过电子邮件将其发送给一个小团队,还是将它们发布到在线社区中?这对文档大小的限制以及版本跟踪过程意味着什么?
  • 在后续的开发过程中设计需要详细到何种程度?如果文档是正规的质量控制过程的一部分,你应该确保让质量控制团队的成员尽早参与,以便使他们理解他们将从你这里获得哪些细节?
  • 文档需要 “生存” 多长时间?对于复杂的项目,当你停止了对文档(例如一系列线框图)的更新时,它就开始逐渐“灭亡”——随着时间的推移,它的细节将变得越来越不准确(这并不总是坏事,只要你开始讨论那些改变)。专注于提供一般性指南的文档,例如品牌指南文档或交互设计模式库,往往生存的时间较长。
  • 每一种文挡的主要用户是谁?答案在项目的不同阶段会有所不同。概念设计文档的主要用户通常是业务利益相关方和设计团队,他们使用这些文档来沟通和交流想法。详细设计文档的主要用户是开发者,他们需要将设计开发出来,这些文档提供了具体方向。
  • 还需要遵循什么其他类型的文档?你需要为功能优先级列表和创建设计之间提供某种联系。你也需要关注几种其他类型的文档,来确保大家达成共识。这些文档可能包括品牌指南、内容开发计划、功能规格说明书或测试用例。
  • 如何估算每种类型文档所需的工作量?这项工作比较复杂,因为对一个项目来说,有很多能影响时间进度的变数。但是,通过粗略的估算来设置一个基准,就能有一个开始,并且随着获得更多信息,你能验证估算时间。例如,你可以设置一个基准值,估算每个详细线框图的创建需要花费6小时。如果你预计一个特定功能需要5页线框图(例如,基于本章前面所描述的故事版方法来估算),对该功能所需时间的初始估算就是30小时。如果最终你发现每页线框图花8小时才能画好,尝试去找到原因。如果认为原因会一直存在,则需要调整对时间的估算,有时可能还需要调整优先级。
  • 还有什么额外因素会影响文档的完成时间?整体时间包括与团队以及与利益相关方的复审时间,也包括你认为需要发布的版本数所对应的时间。对于网站的详细设计而言,可能还包括将你的设计文档同其他文档整合起来的时间,比如详细的功能规格说明书(例如用例)等。将这些假设写下来,方便以后对照检查。
  • 你是否会同多个设计师一起工作,如果是,你们怎样分解工作?如果你们对网站的不同领域并行开展设计,就可以相对独立地创建自己的设计文档。如果你们把工作以一种相五依赖的方式分解,就需要为整合你们的设计计划时间,并且可能也需要一种跟踪和整合文档版本的方法。开始时就规划好设计过程,可以避免在后面遇到令你头疼的事情,并且尽早设定设计指南, 能确保你们在关键要素(例如导航)上保持一致。

温习:

  • 功能视觉化
  • 优先级排列
  • 平衡关系
  • 准备活动和文档

(完)