【译文】UI设计评审成就微创新.pdfVIP

【译文】U I设计评审成就微创新 产品设计流程中 ，有必要对设计进行评审是大家的共识 在我每周的工作内容中 ，参加各类 大大小小的设计评审是必不可少的一环 既有脑力激荡的评审让设计方案脱胎换骨的 ，也有 针锋相对的评审让设计方案摇摆不定的 怎样进行一场高质量的设计评审 ？设计师应该如何 应对设计评审 ，更好的表达设计意图 ，并收集意见改进方案 ？怎样避免设计评审变成竞稿 或PK ？如何确保设计评审这样的流程能带来更大价值 ？带着这些问题 ，我们一起看看原文作 者Jaso n的观点 * 批评从来都是很容易的事情 ，似乎人人都能拥有自己的观点 但正如作者Harlan Elliso n指出“你无法 把控 （他人 ）对你自身的意见 ，但你能把控 （他人 ）对你观点的意见 ” 观点的形成需要探索 ，而设 计评审正是产品探索的重要环节 创意者与团队或客户讨论并解释其创意时的设计评审 ，并非缠着设计师要求解释验证每一项设计 决策 ，那仅仅是批评 优秀的设计评审是探索整个设计过程 ，找到亮点并发掘改进机会 理想状 况下 ，设计评审让团队中每个人都有被倾听的感觉 ，允许客户给出有价值的反馈 设计评审中提出建设性意见往往是个挑战 ，尤其在团队缺乏设计评审的经验时 在敏捷开发团队中 ，程序员、项目经理、产品经理及其他相关人员坐在一起反馈 ，你得明白如何应对他们 ，并且把事 情迅速往你的期望方向引导 UI设计评审的原则 根据我的经验 ，针对UI的设计评审应当在整个产品设计与研发过程中开展 ，或者至少以定期的方式 ，每周甚至每日开展 这么做可以让产品设计可控 ，尤其在设计需要进行多次迭代的敏捷或者精益 产品流程中 开展UI设计评审是一项挑战 ，不仅需要解释决策 ，还得耐心听取其它建议 在每次设计评审前建立清晰的原则-而不是“规矩”-至关重要 与规矩不同 ，原则不是教条式和限制 式的 ，而是帮助每个人对焦期望 ，并允许进行自由形式的讨论 这些期望中的重点是让每个人对你提及的点评细节达成共识 Jaso n Ulaszek推荐道 ： 在你点评的设计细节上开始询问背后的原因及意图 为什么我们需要这条信息 ？对于允许索 取这条信息我们设置了哪些期望 ？我们会用它做什么 ？如果我们能回答它们 ，再进入讨论解 释各种元素的优劣以及与之对应的不同意见会比较好 图1. 准备好演示 为了更好的遵循这个方针 ，无论是否包含UI设计 ，我建议遵守适用于任何设计评审的标准原则 ： 1、表示尊重 听起来很老套 ，但如果每个人都是在批评而不是尊重台面上的意见和他人的技能 ，那评审会迅速形 成敌意 2、指定角色 开始之前就澄清在设计评审中每个人的角色 ，最好在逐个点评时也把角色都重申 ，避免有人感到被 遗忘 理想状况是以下三类角色是不同人 （往往不大现实 ） 演示者 负责进行设计提案并解释背后思路的人 ，他需要回答所有的问题 ，或找出能够回答评审提问的人 主持人 最好由不是直接负责设计的人来担任 ，比如项目经理或产品经理 主持人确保每个人聚焦在主题上 ，并且每个人的意见都能被听到 记录者 此人侧重于记录讨论内容 ，尤其是确保会议相关结论 （另外一条原则 ，后续会说明 ）在评审后能够 清楚传递 会议记录者不应该被排除在讨论范围之外 ，尽管他们的职能倾向于让他人更清晰的表达 观点 3、针对当前评审描述项目目标 快速提醒每个人项目目标以及评审涉及的范围 确保整个评审集中在手头任务上 ，而不是东扯西扯 ，偏离话题 4 、回顾目标用户 强调参加评审的人都不是产品目标用户 ，提醒谁才是目标用户 5、避免给出答案 参与者将会带有强烈的解决问题欲望 ，而且会在评审中提出解决方案 然而 ，最佳方案往往不会在 评审时产生 评审的关键是探索问题及讨论潜在的多个方案 ，帮助设计师拓宽思路并最终决策 6、对结论形成共识 记录者需要回顾每个参与评审人员提到问题的结论 ，以便在下次评审中大家形成共识 不幸的是 ，UI设计评审经常在视觉细节上死磕 ，而忽视交互层面的更影响设计的内容 因此 ，对UI 设计评审 ，我们增加了几条原则 ： 7、澄清设计媒介 在跟听众讲解设计时 ，记得提及产品界面展示的平台及相关技术 这是个iPho ne应用 ？一个网站 ？ 是否使用 ngularJS技术或者C# 开发 ？确保这些都充分考虑 ，否则你的设计方案可能完全无效 8、勾勒流程 你得了解路线图 对于UI设计来说 ，应该是用户体验的流程 或许是故事板、用户旅程图或者其