北京快3平台【真.懒觉】

如何通过设计评审?来看这份深度总结!

时间:2020-11-15 13:24

  编辑导读:设计评审是产品设计流程中的重要一步,也是最需要设计团队达成共识的环节。本文将从六个方面,深度分析在设计评审的时候面临的问题和解决方案,希望对你有帮助。

  设计评审是产品设计流程中的重要一步,也是在众多设计团队里最有共识的一个环节。设计评审如果做得好,会让你从团队里每个人独特的优势受到启发、挑战、赋能。

  设计评审(Design review)为评价设计满足质量要求的能力,识别问题及提出解决办法。从可靠性的角度按事先确定的设计评审表进行,是一种可用性测查工具,目的是及时发现设计中潜在的缺陷,加速设计的成熟,降低决策风险。

  减少复用功的出现,另外在很多的工作中,还扮演,纠错,复盘,晋升等作用,后被推导到产品设计的多个工作领域中。

  设计评审涉及到数种可用性测查方法,且每一种的方法的运用因评审成员而异、因评审目的而异。

  因为启发式评估主要由几名交互专家以角色扮演的方式来完成设置的任务给出评估结果。优点是成本低、快捷,缺点也显而易见,一是交互专家团队中专家不一定有或者很少,二是可用性问题意见一致率很低,并不能很明确的指出为什么这是一个体验问题,有很多个人因素的主观见解。

  协作启发式评估不需要交互专家,可以是用户、测试、设计、产品、运营、商务等等,只要愿意参与测试,就可以。协作启发式评估以小组为单位,根据整理的一套可用性原则表单来排查问题,能够很好的整合出更多的问题,而且更准确。

  独立设计准则是(通常以群组对话的形式)对进行中的设计加以分析,以决策设计方案是否达成目标、体验友好的一种评估方法。

  专家评审主要是进行充分的启发式评估,验证设计方案是否遵循设计准则,是否违反常见的可用性原则,是否违背认知心理学及人机交互等与可用性有关的原则,是否与评审专家在该领域的专业知识、工作经验相悖等。正因为要强调以往工作经验和专业知识,所以这一评审方法才被称为“专家”评审。

  在很多非设计专业同事的眼中,设计评审的意义就是确认现有的设计是否为大家接受,给设计挑毛病。这其实是一个非常错误的观念。正确的设计评审可以帮助团队实现产品目标,帮助设计师发现更优的设计思路。

  总的来说,设计评审的价值可以有四方面:审核设计目标、挖掘设计亮点、共享资源信息、激发灵感潜力。

  设计评审可以帮助设计师确认当前设计思路是否能够实现产品目标,是否存在设计思路与产品目标偏离状况。是否达标设计原则提升设计的质量。

  设计评审可以帮助设计师确认当前设计中哪些部分是非常有效的,哪些部分是有问题的和导致问题的原因。

  设计评审中来自不同专业角度的反馈可以给设计师提供新的视野,在一个设计问题中遇见瓶颈时可以求助其他成员,然后帮助设计师冲破设计中遇到的障碍,不限形式,从视觉、交互效果到品牌形象。保证团队整体设计的一致性,而且可以提升与不同职能的成员的协作性。

  设计评审中的反馈还可以帮助设计师充分了解自己做的设计方案在后续的设计过还有那些潜力可以挖掘。 激发灵感,产生更多想法发现更多更优的设计思路。

  一般的产品研发大致可以分为五个流程:项目启动、需求分析、产品设计、开发上线、版本迭代。

  我们把流程分解后,我们今天主要说项目中期的设计评审,此环节在产品设计之后开发上线之前,属于一个很重要的环节,此环节是确定设计方案移交开发中间环节,一旦有设计或者需求疏漏,会产生严重bug和返工的情况。

  因此一个看上去细小的一个环节,其实经常会困扰着我们,如果刚开始没有将产品开发环节进行整体的梳理,那么在你的设计过程中,评审出问题会导致整体项目的延期,为了让大家能够对设计评审有更深的理解,我将评审进行系统的拆解,结合实际案例,能够让大家掌握高效通过评审的流程。

  在讲干货之前,想跟大家普及几个知识点。让评审经验少的同学可以更好消化后面的干货。

  针对UI的设计评审应当在整个产品设计与研发过程中开展,或者至少以定期的方式,每周甚至每日开展。这么做可以让产品设计可控,尤其在设计需要进行多次迭代的敏捷或者精益产品流程中。在介绍完周期后,先明确下评审的原则。

  在每次设计评审前建立清晰的原则-而不是“规矩”-至关重要。与规矩不同,原则不是教条式和限制式的,而是帮助每个人对焦期望,并允许进行自由形式的讨论。

  听起来很老套,但如果每个人都是在批评而不是尊重台面上的意见和他人的技能,那评审会迅速形成敌意。

  在跟听讲解设计时,记得提及项目背景,解决方案,设计媒介,用户体验的流程,演示产品。

  快速提醒每个人项目目标以及评审涉及的范围。确保整个评审集中在手头任务上,而不是东扯西扯,偏离线)得出方向

  每次会议的结尾要总结,本次达成共识。保证会议是有效率。UI设计评审经常在视觉细节上死磕,而忽视交互层面的更影响设计的内容。

  设计师演示:设计师简述设计需求,需求分析,用户画像,竞品分析,发现问题,解决思路,并开始展示设计方案。

  当方案未能通过评审,设计师需要做出修改时,需要在会后评估工作量。当工作量控制在半天之内时,设计师需要自行消化当天工作量,积极组织下一轮评审,确保设计计划不受影响。当修改工作量大于半天,或多轮内审不通过,设计师需要与合作方以及设计总监沟通评估是否需要变更设计计划,延期完成。在没有特殊情况下不建议设计师延期。

  外审给了整个项目团队从高保真原型的角度重新审视项目的机会,这个时候一些必要的调整能够大大降低产品投放市场后的风险。北京快3

  外审过程中,评审团(项目负责人,uec设计经理,设计总监)会根据高保真原型(设计方案)审视整个需求。评审团会对设计方案中不符合需求的部分给出反馈,会议结束后设计师收集反馈发送给参会人员并做出设计修改,发起第二轮外审。当评审团认为方案已符合产品设计预期时可结束外审,设计师着手准备设计文档和图像资源规范,交付研发/运营团队。

  项目情况:一般是指项目完成了战略层、范围层阶段的工作后,所到达的框架层、结构层、表现层。

  项目情况:一般是指项目到了开发阶段,在这个阶段已经有了确认的设计方案,要按照这个设计方案实施。

  项目情况:一般是指项目进入上线或者测试阶段,已完成了一个完整的项目排期工作。

  评审过程中为何他人会质问和反对?,主要矛盾在哪里?对评审期间会出现的疑问要有一个大概预期。可以按照流程先自己从脑子里过一遍。

  相当于把评审节奏控制在你的手中,一切根据你制定的顺序进行,一般情况下,可以这样编排:

  讲解「设计思路」,让大家先和你的思路对接起来,避免直接看到设计稿时每个人都从自己的角度出发。

  有了思路和编排,也尝试了自问自答,还可以和产品经理一起准备一些能够作为你背书的资料,能够帮助你在评审时,作为资料背书给大家展示,也可以供你快速查阅信息,方便回答问题。

  数据分析文档:用来展示当前版本数据上的表现和问题,以及可以帮助进行下一步改善

  在评审过程中,专家可能需要用到设计原则(例尼尔森十大可用性原则)、行业领域竞品产品案例、前瞻性设计方向等建设性评估。书面文档建议内容尽力做到够详细,可以作为后续设计方案修改的参考性依据,可根据可用性问题的严重程度(高/中/低)排序。

  评审的关键是探索问题及讨论潜在的多个方案,帮助设计师拓宽思路并最终决策。作用:评审中当发现大家的讨论范围跑偏了,主持人要及时把主题拉回来,而不是任由大家发散。

  在展示任何原型或设计稿之前,请从用户的角度讲一个简短的故事:在什么背景下,谁将使用这个的解决方案。

  你在(基于他们最喜欢的应用的建议)时提到自己喜欢它。你为什么喜欢他们的做法?

  是的,我知道你来自哪里。我同意(他们提到的问题)是个大问题。你认为为何可以通过(他们的建议)来解决这个问题?

  不幸的是,由于我们不能同时做到这两者,因此你认为(解决方案A)比执行(解决方案B)更重要吗?

  听完并提出问题后,看看谈话的进展方向,随时准备将大家拉回来并推动讨论继续。

  尝试多方案探索。当你拿出几个方案去说,经过多方探索,最后认为方案三是最优解时会比只拿一个方案三去评审更有说服力。或许真正评审时只需要提出你的最终方案,但敲定方案前的方案ABC还是必要的,它将让你进行设计阐述时更有底气。

  在你进行设计阐述时,不是依靠口才和随机应变来处理各种质疑和反对。而是用扎实的底层依据来让所有人闭嘴。何为底层依据,即你为产品中后期的设计而进行的前期调研,竞品分析,用户建模等一系列围绕产品目标产出的数据。言之有物,拿出证据让设计阐述有理有据。

  我们必须了解评审的意义所在,即求同存异取优,曝光问题,吸取意见,完善产品。

  求同是大方向,最终目的是选取一个对内符合团队成员预期和能力,对外能够解决用户实际问题的优秀设计方案。存异是了解各个部门成员对于设计方案的疑问,了解并耐心听完才能收获真正对产品有价值的提议。取优则是要求我们作为设计师有一个筛选合理的需求的能力。

  诸如,这里感觉怪怪的,那里有点不舒服等这种没有任何建设性的意见可以直接忽略。什么意见可以吸取呢?一种是考虑到自身资源不能完成的指标或者优先级较弱的需求——“这里的动效过于复杂,技术实现难度大,时间成本高。“另一种考虑到用户体验视觉效果但要求明确提出问题点——“这里字号过小,一眼看去很容易忽略掉。

  筛选后的需求进一步的确认和理解,以保证理解的需求和执行的优化结果不会因为歧义和误导而返工。可以对于提出需求者进行回访,通过邮件形式询问他的需求和你的理解是否一致。

  对最终列出的需求单进行优先级排序,用ergency(紧急性)importance(重要性)作为XY轴选取右上角的部分优先完成。

  因为每个团队都有自己产品侧重点,我就不过多的说了,想了解的可以最后留言!

  没有对设计主题准备充分的依据或来源,为什么要这么做?这么做可以解决什么问题?评审过程中很容易被反问而答不上来,导致意见被驳回,只能改了。

  每个设计师负责的具体业务不一样,别人对这些限制条件的具体了解程度也不会有你来得深入,所以在评审会议上,他们可能会从更理想化的角度出发思考,给出和限制条件矛盾的思路、建议与解决方案。所以讲解自己的设计方案之前,也应当提前和项目组沟通清楚细节,把这些业务/技术上的冲突点清晰、全面地描述给团队其他设计师。

  比如描述限制条件的根本原因,大家共同判断是否确实需要进行妥协,探讨是否有已经实现的现成案例来证明限制不存在,是否有能取得更好平衡的方案等。像技术限制,是组件改动困难(牵一发而动全身)?是实现成本过高(投入产出的性价比不够)?是影响速度等性能(实际用户体验不佳)?还是其他一些原因等;而如果只是简单说一句「前端/开发说这个做不了」的话,并不是那么令人信服。

  设计评审的会议时间最长也就几小时,在这么短的时间内得到的建议反馈,其实是有不少考虑不够周到全面之处的,而这些往往要到具体修改方案的环节才发现。所以除了发起评审之外,私下找其他熟悉业务的有经验设计师沟通探讨也很重要,这样得到的建议启发也更加成熟和思虑周全。

  其实归根结底,做设计评审的主导者并不是让你学一些所谓的小技巧,阴谋诡计来躲避一些批评和反对。而是通过提高本身设计能力,提高设计方案的价值、核心竞争力(视觉或者交互、用研),提高自身的设计阐述能力,用有理有据的设计提案获得认可,助力产品设计,衔接产品设计的上下游,最终上线并为企业赚得利润价值。

  要有一颗积极的、理性的心态来参与设计评审,否则很容易在评审过程中因为受到反驳而沉溺于消极状态!在大家对方案进行点评时也期待提出更好的建议和优化方案,大家的初衷还是最后能真的为用户解决掉一些问题,更多的还是有个更好的产品体验!

  本文由 @七酱设计笔记 原创发布于人人都是产品经理,未经作者许可,禁止转载

  听到很多言论说在中国程序员是吃青春饭的,那么产品经理呢,也吃青春饭吗?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。