本文大概需要占用您600秒的时间,但能给您贡献60000秒的价值。
在如今的产品设计团队中,体验设计师需要做的事情已经跨越了职能边界。
为了寻求更好的设计方案,常常要承上启下地连接整个团队。
其中所涉及的工作,基于我们熟知的设计流程,同时隐藏了许多跨职能的思考和工作细节,需要体验设计师全方位理解设计工作对其他职能的影响,以及其他职能工作对设计的限制。
作者将定义问题、创意发散、原型 & 测试、复盘反思四大设计流程细化为 12 个步骤,每个象限有 3 个步骤详细讲述了每个步骤涉及的职能任务和思考。
就像开启一段英雄旅程,设计师需要充分理解并计划这场冒险之旅,遵循规则,从而更好地解决问题,应对挑战。
受到 英雄旅程的启发,给用户体验设计师的详细指南。
如果你喜欢写故事,可能听说过 “英雄旅程”。它描绘了大多数书籍讲故事常用的 12 个步骤。我认为一个项目的旅程,从现有的产品到发布新产品,再到分析优化,也可以像英雄旅程一样被分成 12 个步骤。这个旅程的英雄就是用户体验设计师。
用户体验设计师在日常生活中会了解很多产品的 重要细节、产品特性、功能和用户对产品的期望,甚至要考虑优化对产品和业务现状的影响 。工作室里的每个人、每一天都在他们固有的轨道上行驶,对于设计师而言,这是一个机会,让你专注于一个难以在规定时间之内完成的工作。在这个阶段我们可以做:
这一步破坏了现有产品的舒适性并提出了挑战或要求 。根据你所在团队的工作方式和管理方式,挑战会以不同的形式到来。挑战的规模也会随着团队的情况而变化,可以是很大、很小、适中、非常聚焦或者更具开放性。
用户体验设计师可能会很热切地想要接受挑战和要求,但在这个阶段需要回答和考虑一些问题,以确定前进的策略 。首先要确定遵循的设计方法:
根据选择的方法和挑战的规模,以下步骤可能独立或者以不同顺序开展。为了加深为对项目的理解,接下来开始提问或者进行一些小的练习:
用户体验设计师在这个阶段,要开始对 可访问性和包容性 设计打下基础,讨论和规划以下内容:
会议的导师
专家信息有助于解答用户体验设计师当前的问题 ,为他们提供理论基石和设计信心 。
一个好的产品需要不同职能共同参与,而用户体验设计师需要把这些职能结合起来 。每一种职能都是某一领域的专家,比如用户,科技,市场,商业等。最后,用户体验设计师将会拥有一个全局视角,而不仅仅是站在设计职能的角度来看问题。
没有人会了解一切。
设定一个 15 分钟的会议,并和职能负责人商谈,包括:
用 问句的形式来 获取有用的信息,比如:
为了更好地应对挑战,你可以通过 调研来洞察机会,发现当前产品的问题。比如,你面对的挑战是 “提升用户购买力“,那就需要:
优秀的用户体验设计师可以综合以上所有的信息,进而找到一个最佳解决方案。
跨越门槛
到了这一步,用户体验设计师可以真正开始着手应对挑战,寻求解决方法。这时候,无论是小组合作还是个人进行,都最好保持相对平衡的关系。如果在一个小组里,最好遵循 “在一起,但独立” 的准则。这意味着团队里职位更高的人不要控制整个团队的思考,要给团队更多的讨论和决策空间。所有的练习和活动都应该匿名参与。
从寻找灵感开始,它不一定来自产品领域 。用户有时也非常喜欢从其他领域,特别是他们经常使用的事物中学习交互模式。记得使用 闪电演示 的方法在小组里进行讨论。
闪电演示 Lightening Demo,即一种有组织结构的展示会议,参与者可以展示他们的灵感和喜欢的点子以激发所有人的讨论
一旦找到了灵感,回顾一下之前所有收集到的信息。这时候,用户体验设计师会有许许多多的想法,可以:
回顾整个过程,在小组内进行投票,选择最好的想法并且:
最后,为了确保整个设计方案没有遗漏 ,请使用步骤 3 进行查漏补缺 。举个例子,一个项目发现 “社交媒体广告和电子邮件对模板有需求”,基于这个描述开始提问和练习,并绘制出草图。请记得,很多时候,我们的重点应该完全放在产品以及核心流程上,而不是其他地方。
在这个时候,开展故事地图讨论会是有很有必要的,可以拆解想法并且确定 最小可行性产品(MVP:Minimal Viable Product),特别是在一个不断迭代、敏捷开发的环境下。作为一个用户体验设计师,请确保可用性不会受到严重影响,可以允许少量干扰因素存在。一旦通过原型验证了想法,根据团队的工作模式,可以使用故事地图来尝试搭建最小可用产品(MUP:Minimal Usable Product)。
测试、赞同、反对
用户体验设计师必须面对通往最终解决方案过程中的反馈和批评 。
在一个合作性的工作坊中,最好的想法和机会点会通过投票产生。举个例子,在一个设计冲刺中,用户体验设计师提出的解决方案需要得到其他利益相关者的反馈意见。他们可以是:
有时候,设计评审这个过程可能需要几次迭代才能完成,尤其是一些 复杂的技术问题。最终,由决策者决定最终的方案。一旦最终决策完成,就可以开始招募用户来验证设计方案,或者使用第三方招募服务和小组。
在进行最终的设计验证之前,还需要完成最后一步。
区分原型和可交付给软件开发者的设计规范是很重要的,在这个阶段,我们关注的是前者。这意味着要创建一个高保真的最小可行性原型来获得验证。首先,需要确定保真度和原型:
绿野仙踪 Wizard of oz:在开发聊天机器人之前,可以利用“绿野仙踪”作为最小化可行产品(MVP)测试。“绿野仙踪”测试的名称来源于《绿野仙踪》这部电影。测试时,有一个真人(“魔法师”)会替代机器与用户进行对话。
接下来,确定构建原型所需要的工作。有时候,用户体验设计师承担了所有的任务,但是在理想情况下,这项工作需要混合其他职能:
原型工具:
如果原型是需要编码或高保真输出 ,请遵循设计规范:
与客户一起测试设计方案的性能,可以获得更深入的洞察和见解,更好地推动项目落地。
建立好原型后,就可以开始验证了。理想情况下,我们会和参与者进行一个 30 分钟的对话 。首先,收集项目所有的假定、问题、原型,接着建立测试计划和脚本,思考以下几个方面:
在进行测试之前,可以和同学进行模拟练习,这会帮助你发现脚本隐藏的问题,确保整个流程的时间是合适的 。
当参与者、原型和脚本都已准备好,就可以进行测试了,确保以下几个方面:
允许参与者表达其他想法,并通过介绍接下来的步骤来结束每一个测试环节。也可以要求参与者填写问卷,来获得:
调研产生的结果会通过不同形式回馈给设计师,比如问题、更多的知识和洞见,或者是设计上的验证。
把调研过程中的发现记录下来,以指导之后项目的发展,在未来遇到相似问题时不断回顾这些经验 。最好将调研计划和调研记录放在一个文档里,当你回顾时就不需要重新去理解项目是什么,所有的东西都在一个地方可供查阅,也可以避免其他浏览者多次跳转 。记录以下内容:
当记录这些调研结果的时候,确保:
如果可能,让整个团队参与到调研中。通过实时(匿名)观看或者参与录制,让团队成员成为记录者。这样你的团队就可以更多地获得一手资料,而不是通过报告来了解信息,并且会更加激励团队,提升工作效率。
这场旅程还没有结束,设计方案可能还需要根据其性能进行优化 。根据测试结果,这里有一些不同的方向可以选择。最好的情况是,设计方案有效,只需要一些小的细节修改;最坏的情况是,设计方案失败了。
设计是允许失败的
—— 精益 UX
根据调研结果,可以:
发起一个会议,向团队成员展示调研、测试结果,以及更新后的原型,并提出下一阶段的建议。回到之前的步骤是一个很艰难的决定,也很难得到支持。更不幸的是,在设计冲刺阶段,没有足够的时间支持后退。因此,需要通过调研结果来解释后退的价值,从业务和用户层面来说服决策者。
设计方案会对现有产品以及开发工作产生重大影响 。设计方案确定后,还需要补充一些其他状态,比如开发团队需要从设计师这里了解到的信息:
现在,可以开始思考如何衡量新的设计方案,以验证新产品是否成功或者需要改进。建立一个设计量化方案以确保开发团队可以进行正确有效的数据埋点。思考以下几点:
为了方便开发团队制定工作计划,设计师需要确保原型和其他设计资产易于理解 ,并支持随时访问。保持与开发团队的沟通,减少信息差,做好支持性工作,有时候仍需要修改一些设计细节。
定期查看开发团队的工作进程,以确保项目顺利推进,且符合设计规范。对开发交付的内容进行最后的设计审查,包含:
不要过分依赖质量检测团队去发现设计以及可访问性方面的问题。
接下来要讲的,是一个解决问题的方法,又或者是一个整理思路,请大家自行感受。
当产品通过质量检查并成功发布 ,就会来到一个新的阶段。接下来就要开始收集数据了,时间跨度取决于产品的使用频率和用户群大小,可能需要数周甚至数月。数据收集完成后,请创建报告或演示文稿,内容包含:
如果结果是糟糕的,复盘就变得更有价值 —— 找到出错点和优化点 。如果结果让整个团队离 KPI 更近一步,或者有任何可以提升的地方,那么就值得花时间强化这些部分,帮助项目顺利进行。接下来,就可以在归档文件中加入这些结论,或者进入下一个设计挑战,继续向业务目标迈进。
这是一个动态的过程,以上提及的步骤会随着时间的发展有所改变。UX 设计师需要具备多样化的技能,来参与整个项目旅程。毫无疑问的是,我一定遗漏了一些细节。我所描述的步骤和你的项目经历有相似之处吗?你会因此改变哪些步骤?或者增加哪些内容?我漏掉了什么?欢迎交流!
编辑声明
本文由小编收集于网络,版权归原作者所有,仅代表作者观点。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。如发现有侵犯您知识产权的作品,请联系我们及时修改或删除。
联系方式:qq或邮箱:20816662@qq.com