作者 David Cronin
引 子在 过去几年里，在Cooper公司的工作中，我们学到了一个经验：不管项目有多大，与客户的密切协作是取得成功的关键因素。这是我们吃了不少苦头后得出的经 验教训；协同工作可能相当杂乱、不可预测，有时候还会逼迫我们不得不妥协，放弃我们自己认为是极其优秀、清晰、卓越的方案。尽管这些痛苦依然存在, 但我们已经开始接受那些不可预测的情况，学会让步；并通过对客户协作加以良好的管理，我们的设计变得越来越好，变得可以更好的服务于客户的需求、更好的满 足最终使用者的需要。 本文是一篇实践研究的文章，向大家介绍并讨论我们在项目中曾经采用过的方法，这些方法有利于尽可能的发挥和利用客户的专业长处和反馈信息，同时也保留了创造的动力，最终帮助我们按时完成每个阶段的任务。 在开始讨论这些方法之前，为了更好的理解，我们先讨论一下客户的目标，并且简单介绍一下我们在和客户的工作中遇到的困难。 客户希望达到的目标客户和我们一起协同工作的首要目标是设计出最有效、最创新的方案，来满足使用者的需求和商业需要。我们的有些客户已经明确知道他们的客户需要什么，渴望什么和什么最有用；而有些客户则时常冒出新奇的想法，我们很乐意将这些都纳入设计的方案中。 正 如David Kelly所说,“一个成功的设计是由团队中的所有人共同努力完成的。一个人的创造力只能完成设计中的一个跨跃，只有来自团队中所有人不同的智慧和努力才 能完成整体设计。所以团队中要拥有跨学科的多种人才，需要有掌握不同技能的人来解决不同的问题。否则，设计的大方向就只能让一个有能力,或说话最有分量的 人来左右了。”[1] 在此种精神的指引下，在我们的设计过程中，我们努力考虑不同的利益群体(stakeholder)。作为设计者，我们不但要展现出创造力，还要作为辅助者来推动团队解决问题和创造活动 协 作要达到的另一个同等重要的目标，就是要全力支持所提出的方案，并且要培养一种主人翁的感觉，和客户一道把工作坚持下来直至最终完成。软件的构建过程是一 个困难并且花销很大的过程。为了我们的工作能够服务于最终使用者,我们必须先完成设计。支持设计方案并履行对设计方案的承诺，对保证最终产品符合先前制定 的规范是至关重要的。通过紧密参与设计活动，能够更好的发展承诺精神和主人翁责任感，所以，如果一些必要的、合适的人员能够早点参与进来，则可以避免后期 的一些不必要的修改和不确定因素。 最后要谈的目标是按时完成任务，这关系到客户的利益（和我们自己的利益），这是很重要的。正如我刚 刚提到的，软件的构建过程的成本是很高的，如果计划安排不明确，并且组织的不好，成本就更高的可怕了我们在项目过程中，要考虑到客户的知识水平和理解能 力，这显然是关键的。因此，在项目计划中考虑客户的知识水平和理解能力因素，这也是同等重要的。 问 题 和 困 难我 们中的很多人都感谢是客户养活着我们。但我肯定很少有设计者没有说过“我们的设计很出色，只是客户不认可”这样的话。我不想讲设计者艰难创业的故事，有些 故事里还伴随着和某些神经质客户打交道的冒险经历，我要讲的是有一些常常发生的普遍情况，在这些情况中，有时客户的反馈和协作可能让工程严重脱轨。 越改越糟迭 代设计(iterative design)的目的是让设计方案越来越清晰,项目中的每次开会的决定为下一个会议提高解决方案的宽度、深度或精度。设计行业中我最经常感受到的痛苦是 “越改越糟”，设计被反复地修改，但对解决问题却没有任何帮助。以下是几种常见的情况: 在外观设计评论会上，客户表态说他们不喜欢所提的任何一个设计方案；在接下来的会上，客户又突然决定考虑先前被放弃了的方案中一部分。如果每次会议都在怀 疑先前的决定，或者又要重新考虑已经放弃了的方案,那么项目根本无法继续下去了。 含糊不清的反馈信息我在和 客户协作中经常遇到的第二个问题是，用户给出的意见和反馈含糊不清，让人很难采取正确的行动。客户通常对交互和视觉设计的了解相对较少，这样他们就很难阐 述清楚他们的意见和反馈。还有，我曾经协作过的许多客户，他们对问题细节的关注，不是过细就是过粗。比如，在项目刚开始时，设计组希望得到的是关于交互的 整体框架时的反馈，而客户却跟你讨论一个细枝末节的问题。 偏见和成见有时，偏见和成见隐藏在“期望” 中,但由于它们的外表看似合理，但却华而不实，因此还是能很容易地被辨认出来。举例来说，有个客户主观认为,他们的商务分析应用软件应该有一个“高层领导 控制面板”，未经调查研究就认为这个功能使用者肯定会感到满意的，这可能就是一个有害的成见；它可能妨碍了满足使用者需求的功能设计前进的步伐。 还 有一些偏见和成见出现在技术选择上，或来源于其他的成功 (但是无关的) 产品。举例来说，有一种偏见认为，如果某应用是通过web浏览器进行操作的，那么该应用就必须要像网站一样。我以前碰到过一个客户的三级主管，他认为企业 应用平台软件应该是如同视窗浏览器一样，他根本就不想想有多少人会相信这样的树型结构浏览应用能够真正解决问题。 妥协不一定是最好的解决方法在世界上的各个企业里都有政治关系，针对一些问题，大家通过协商并达成共识，然而这并不总能取得预期的结果。优良的设计之所以优良，其基础在于该设计的完整性，但为了达成共识而进行的妥协则可能会破坏这种完整性，从而破坏设计的优良品质。 当一个委员会讨论并做决策的时候, 委员中的各群体利益的不同，常常使得设计的妥协成为必然。做决策的人越少，命令就越集中，对设计完整性的危害也就越少。 个人喜好最后要谈的是在我们的实践中也经常遇到的问题，客户的反馈往往是基于个人喜好的,其对设计方案的评价并没有考虑该设计是否满足了使用者和商务目标。 我 们 在 实 践 中 总 结 的 经 验那么, 面对这些问题和困难，一个设计团队如何能有效地和它的客户协作，并最终作出符合用者需要和商业目标的解决方案？在过去的几年里，为了达到这些目标，我们在某些方面已经形成了我们的方法和程序，提高了我们达成这些目标的能力。我们在实践中总结出如下经验。 沟通在Cooper 公司的早期，设计者们在开会讨论时，积极地提出各种好的建议和想法，可是有的时候，他们最后讨论地筋疲力尽或不可开交进行不下去了，而且他们最后一走了 事，把这些有价值的主意和想法都留在了白板上。后来我们想，虽然设计者们提出了很多很好的主意，但是主意都留在白板上了，没有人将这些信息传递给客户，那 么这些主意又有什么用呢？ 自那时起，我们便有了专门负责跟客户沟通的职位。我们很多的设计团队中至少要包含两个重要角色：交互设计者和设计沟通者。交互设计者主要负责产生完整的概念设计并将设计方案视觉化；设计沟通者则主要负责把设计方案在设计团队和客户之间沟通清楚。 由于设计内容没有向客户表达清楚,而导致优秀设计被拒绝，这样的情况我们见过很多。仅仅在客户面前展示一个作品，并且问“怎么样，你喜欢么？”，这是不够的。我们发现，在展示设计的时候，下面几个方面的事情必须解释清楚，这是极其重要的:
一 些读者可能认为我在这个列表中忽略了很重要的一项，即“其他可能的设计方案”。我的忽略是故意的：当然有时客户会让我们展示针对一个问题的多种解决方案， 这时我们一般给只给客户介绍其中一种我们认为是最有效的并且是最吸引眼球的方案。其他方案我们只在口头上讨论，在口头上向客户阐述为什么我们倾向于我们推 荐的那个方案，并告诉客户，如果我们已经知道了正确的答案，我们将不会把客户的钱浪费再去探究多种解决方案上。 最后，我要补充一点， 客户有时好像不太关心上面列出的几条事情，但我们发现无论如何也要告诉给客户，这是至关重要的。客户决定着设计组的工作方向，客户的决定是否坚定如一则取 决于设计组和客户的沟通。如果客户在作决定之前没有考虑上面这些关键信息，而当他们再次想到这些信息时，他们将有可能不得不重新考虑并修改他们的决定，而 最终导致设计者再多花几天或者几个星期来修改设计方案。 选择适当的人这一点很明显不用说么? 也许，但是客户方参与总体设计和协作会议的人选对产品是否具有决策权是很重要的。当然，有些公司是由委员会做决定，这种情况下，则让委员会中的一部分人参与到设计和协作会议中，这十分有帮助，或者考虑让整个委员会都参加进来。 关 于在具体的工作中与客户协作，我们尝试在小的设计团队和较大的功能齐全的团队之间取一个平衡。开始的构思和结构设计对于一个大的团体是困难的，在此阶段 中，概念统一十分重要。虽然有多种多样的想法对创造力是很重要的,但是较大团体的多样想法会导致分歧，很难控制，要统一方向几乎是不可能的。而和客户一起 进行最初的设计框架的制定，这种做法也要谨慎采用，因为我们遇到过一些情况。比如，客户的高层代表一开始参与了头脑风暴的过程，有了先入为主的想法，一旦 发现最后的方案和前面的不一致时，就可能给整个的设计管理工作带来不必要的摩擦。 所以，我们刚开始只用一个由较少人组成的很灵活的小组，如有必要可以只请一个客户代表参加。一旦我们的工作比较成形了，我们再战略性的邀请一少部分的客户代表来参与，优化我们的设计和想法；直到他们满意了之后，我们才将设计方案开放给更大的群体。 这个时候，你会发现，开始阶段参与进来的少数客户代表，可以很好的帮助我们一起同后来参与进来的更多的客户代表进行沟通，他们起到了具有决定意义的桥梁作用。 我 们会尽量在设计工作的早期就在战略层次上指定好所有的定义和全部交互框架, 然后再确定交互界面中一些具体的方面、更细节的内容(本文后面会详细讨论)。所以，我们发现，越多的战略层次上的客户代表能够越早的参与我们的会议(当我 们决定产品能做什么的时候)，是很有帮助的，这些战略层次上的客户代表可以是产品经理、软件设计师等。之后，当我们开始进行产品更详细的、外观和具体的内 容的设计时，再将更多的作具体工作的人员参与进来。。 最后, 我之前已经提到的, 让客户认同设计方案是设计者们的极其重要的工作。在Peter Block所著的《Flawless Consulting》一书中，他谈到，得到客户的认可是咨询服务要达到的目标。“我们可能心存幻想，认为如果我们思路清晰并符合逻辑、讲解很有说服力、 并且信念坚定, 就一定能说服我们的客户。尽管条理清晰的雄辩很有用，但是还不够。客户可能仍会怀疑并陷入难以抉择的困境。” Peter Block在书中也描述了如何采取最有效的措施在工程的各个阶段用消除客户的怀疑。[2] 计划和时间安排绝 大多数的大工程的费用和时间在合同中都固定下来，不可更改。作为销售环节的一部份，我们运用一些方法将我们的工作内容和时间计划安排到具体的每一天。这对 于管理客户的信息反馈和同客户协作具有重要意义，我们能够预测到和客户将在哪天讨论哪些主题,并且能保证我们对的上客户高层决策人的忙碌的时间表。然后， 我们能够围绕这个时间表来计划我们的工作。(当然，意外可能还会出现, 可能会迫使我们稍微做些改变。) 我们发现，按照事先制定好的 时间表工作，告诉客户延迟的影响，可以帮助客户履行承诺。如果客户不能够依照时间表行事,则他们或者必须按照我们推荐的行动路线来继续下去，或者延长工期 并增加费用。换句话说，我们告诉他们我们的进程，然后，依照时间表继续, 除非明确指明更改方式。关于工程结构和协作关键点介绍，参见文章末尾的图三。 尽早且经常接触以 往，在正式将设计方案呈现给客户之前，我们尽可能少的让客户参与进来，但这里存在一个问题，就是没有人喜欢意外事件。如今，项目中一旦有重大情况发生，我 们便尽可能快的通知客户并让他们参与进来。这样带来双重好处：我们有较多的时间考虑并处理客户的反馈，而客户则变得更忠于他们参与进展的方案，因此降低了 项目在重要环节处受挫的可能性。 我们也努力保持同客户中的每一个决策人频繁接触。我们发现，他们的参与可让他们更容易的了解关键问题，并且可以帮助他们更好的作出判断和决定。 围绕特定议题的框架会议在会议中，与其简单的向客户报告我们的工作进程，不如针对某个或某几个的特定议题进行讨论。这样做的好处很多，我们先讨论之前的工作，并从中探讨可能的方案，然后拿出适当的数据和材料，来支持我们的建议。 此外，由于会议有了确定的目标，我们能控制会议的长度而且减少离题和散乱的讨论。针对某一个决定进行的专题讨论，可以帮助客户做出更明确的反馈, 而且可以保证设计师在会议结束时都清楚下一步行动的方向。 尽早访谈关键的利益关系人(stakeholder)一些利益关系人只是简单地希望他们的观点被加入新产品。如果到了设计方案评估时才让他们参与进来的话，他们有可能仅仅因为自己没有被重视，而直接反对该设计方案。 为 了减少这种可能性，并且确保我们会考虑到每个利益关系人的有价值的观点，在每个项目的开始，我们都要通过和利益关系逐个面谈讨论他们的想法、目的和关注的 地方。这不只帮助我们更进一步了解大体需要, 而且也帮助我们从客户的目标出发，并用利益关系人的语言来表达我们设计的价值。 “优秀的设计”其本身极少能够打动客户。与之相反，正如Cameron Foote在《Design Management Journal》（设计管理杂志）上发表的一篇文章中指出, 客户普遍希望设计顾问“应该多考虑他们的企业和市场。不仅要知道如何才能完成设计工程，还要了解他们的业务、他们的行业、他们的运作模式、和他们所面临的 困难。”[3]用角色和情景来构成使用环境对交互设计师来说，角色(persona)和情景(scenario)是最强大的工具之 一，我们周围有大量各式各样的使用角色和情景的例子。在Cooper公司, 当我们说“角色”时，我们指那些非常明确具体的东西。角色是原型化了的使用者模型，他们虽然是虚构的人物，但却是经过人类学使用研究的观察，建立在真实行 为的基础上的，一个单独的角色可以代表着一大批实际使用者的目标、需要、态度和倾向。 在处理客户反馈以及和客户协作时，角色有助于塑 造恰当的使用环境，以评估解决方案是否合适。我们评价一项设计不是依靠个人的品位或美学判断，而是看它是否有助于使用者达到目标，是否有愉快的、吸引人的 使用体验。我们描述某个角色经历一个情景(scenario)，在情景中使用该产品来完成某项任务，通过这种方式来向客户介绍设计方案。我们发现，和用屏 幕展示产品界面并让客户提反馈意见的方式相比，角色和情景更具有说服力。 真实世界的情景是对角色强有力的补充。当我们的设计产品已经 可以满足角色们的时候（虽然他们可能会反映出一个或多个真实世界的情景），我们应该去了解产品是否可以让真实使用者满意。在和客户的专题协作过程中，真实 世界的情景也是很有效的工具。如果客户对设计的某一方面有疑虑，我们就会把它应用在人的真实需要之中，通过真实世界的情景进行验证，这样做可以确保我们知 道如何解决问题，也消除了客户的疑虑。 正如Hugh Beyer 和Karen Holtzblatt（还有很多其他人）所描述的，以研究为基础的模拟使用者的需求和工作的流程给了开发人员和市场人员所需的信息，使他们能定义并构建一种产品。[4] 当 然，角色并非万能。应用不恰当，他们就会引起同样多的麻烦和混乱。在使用角色时，我们曾发现的常见的错误有：不是以真正地使用者作为基础进行研究(在这种 情况下，他们只是未经测试的带有个人主观偏见的各种猜想的载体)，或没有选择好合适的原型（比如，选择电脑程序员作为客户音乐共享服务的原始角色）。 下 面举一个我们曾经遇到过的这样的经典例子。有位客户的高层管理者，认为该公司商业分析平台的主要交互部分是让使用者搜索并浏览其功能。为支持其观点，他开 发了一个名为佩尼罗普(Penelope)的角色，此角色缺乏实际的工作责任心，她整日四处寻找使用公司软件的新奇方法。佩尼罗普并不是建立在对使用者进 行研究的基础上，也并不能代表我们为期两个月四处调查所作研究中的使用者。满足佩尼罗普的需要去设计软件，对于我们满足真实客户的需要产生了极大的危害。 确定解决方案之前要先明确问题是什么就 一系列的角色进行定义并一致同意该定义后，下一步要做的工作，就是在呈交解决方案之前，系统地定义好产品需求。定义产品需求的目标，是在讨论解决方案之 前，就产品功能和如何完成功能取得一致意见。这样做，我们就能对产品设计中必须做出的各种决定进行归类划分，这样就可以避免让客户被迫同时回答“是什么” 和“如何做”的问题。如果不定义好、不归类划分，客户的反馈信息将变得模模糊糊、很不明确，我们也无从就客户的反馈信息做出响应；而且，当设计组出现了 “是什么”的错误时，客户就可能反对“如何做”，那么这样一定会陷于“越改越糟”的境地。 有一篇文章讨论了医学的研究方法学能如何有 效地作为设计研究基础, Andy Schecterman在该文章中指出，特别复杂的或者混乱的问题，很难被线性方法或者成熟方法解决。他主张“方法不能基于假设，这是极其重要的，太快做 出结论或太快做出的方案通常将被打回到草稿纸上。”[5] 我们还要将产品需求和产品功能区别开来，这会让我们的设计工作变得清晰。我 们时常交替的使用“需要”(need)和“需求”(requirement)作为产品功能的抽象描述。我们不能混淆需求和解决方案，否则会妨碍真正有创造 力的、突破性的解决方案的产生。 举例来说, 在一间食品杂货商店, 其中的一项需求是“记住要买的东西”；解决方案可能是一张清单纸、一个掌上电脑、或者是可以和智能电冰箱说话的购物车。 我们用分析的方式(不是综合的方式)定义需求, 以确定每个需求和下列来源之一有紧密相连:
再 次强调，我们必须要将使用者和真实世界的相关情况说明清楚，只有如此，我们才最终能够把用户界面的每个方面同角色和业务联系起来。这样，将设计工作中的个 人口味和偏好摒弃掉，从而帮助设计团队先合情合理的定义好“是什么”，之后再过渡到“如何做”上面。这样，有了大家都一致同意的、明确的“是什么”作为基 础，我们才能在“如何做”上面发挥自由的创造力。
设计图的细节要循序渐近当客户本来只想看设计整体的粗略图时，我们就不应该给他们展现具有丰富细节和精确图标的精细效果图。还有，我们设计过程也是始于大而粗略的框架，进而逐步过渡到精细的局部细节，所以，对待产品设计中的各种绘图，我们也应该如此—要从粗略的大框架循序渐进到精细的小细节。 在 设计过程中初稿阶段(我们叫做“结构定义”阶段)，我们制作了视图样式和模板，这些样式模板只是一些简单的勾勒，没有精细到像素层面，其实这些视图样式本 来就谈不上什么样式不样式的。看到这样的绘图，我们的客户便会明白，其实我们并不是在问他们关于产品的颜色是茶色还是棕色这样具体的问题。客户了解了这一 点，就会让我们更容易的专注的处理我们现阶段手头上最重要的问题：绘图中的框架结构所呈现的方案是否可以实现之前大家都认同的需求？ 简 言之，设计中的各种绘图必须找到细节的合适的平衡点，既要提供足够多的细节让人明白所描绘的方案如何解决了当前的问题，又不能有过多的细节让人陷入其中。 这个概念有点像我们所说的“线框(wireframe)”，但却有些不同。尽管这里明显有很多不同的效果， 线框通常是没有任何样式风格的，仅仅用来在整体上描述界面元素及其功能。虽然我们发现有时这样做确实有用，但我们需要的是没有过多细节的粗略图，而线框没 有满足这一点。
在 需求定义阶段，绘图中细节的循序渐进的原则，是在进入到下一阶段之前，把本阶段的决定彻底确定下来。诚然，在此阶段将各项决定分门别类并确定好可能有些困 难，但无论如何，设计组应该以本阶段确定下来的方案为基础，对于需要更多细节才能确定下来的东西，我们必须要在下一个阶段中来探讨，而非在本阶段。 敢于放弃从 多年和客户打交道的经验上看，如果设计师能够高屋建瓴的将自己的热情与精力同设计方案保持一定距离，那么整个项目过程就会容易的多。当然，设计师们对于自 己方案的热情和精力也是极其重要的，因此也为自认为是最优秀的方案而极力辩护，但是过于顽固毫不妥协对建立协作和达成一致没有太大的帮助。我就曾经遇到过 几次客户根据个人喜好，非常抵制有争议的方案，并完全弃之。 结 论每个客户和每个项目都是不同的，本文所述 的实践研究的目的，不是为各位开一剂保证成功的处方, 而只是一个药剂列表，所以每个设计公司的每个项目，应该采取不同处方，让设计项目可以更快更有效的前进，让设计方案更完善。其次，项目计划一定要能适应无 法预测的变化。还有，和客户的协作过程是需要时间的，所以整个的设计项目也要给协作让出必要的时间，不然协作就是零了。另外，在售前阶段和工程范围定义阶 段，设计公司要具备向客户清楚阐述项目情况的能力；向客户清晰的说明项目结构的设想，让客户清楚的明白投入在协同工作上的时间是有价值和意义的，还要告知 客户不按照一致同意的时间表开展协同工作的风险和危害；这样，我们才有信心让我们的客户做出最符合他们的商务需求的决定。
参 考 文 献[1]
Kelly, D., Hartfield, B. The Designer’s Stance. Bringing Design to
Software, Terry Winograd, ed. New York, NY: ACM Press, 1996. p. 159
|
|
|
