收藏本站 关于我们

【译文】UI设计评审成就微创新(翻译理论)

发布时间:2017-02-06 15:48:15   来源:PS教程   人气:0

前言:【译者注】产品设计流程中,有必要对设计进行评审是大家的共识。在我每周的工作内容中,参加各类大大小小的设计评审是必不可少的一环。既有脑力激荡的

【译者注】产品设计流程中,有必要对设计进行评审是大家的共识。在我每周的工作内容中,参加各类大大小小的设计评审是必不可少的一环。既有脑力激荡的评审让设计方案脱胎换骨的,也有针锋相对的评审让设计方案摇摆不定的。怎样进行一场高质量的设计评审?设计师应该如何应对设计评审,更好的表达设计意图,并收集意见改进方案?怎样避免设计评审变成竞稿或PK?如何确保设计评审这样的流程能带来更大价值?带着这些问题,我们一起看看原文作者Jason的观点。


批评从来都是很容易的事情,似乎人人都能拥有自己的观点。但正如作者Harlan Ellison指出“你无法把控(他人)对你自身的意见,但你能把控(他人)对你观点的意见。” 观点的形成需要探索,而设计评审正是产品探索的重要环节。


创意者与团队或客户讨论并解释其创意时的设计评审,并非缠着设计师要求解释验证每一项设计决策,那仅仅是批评。优秀的设计评审是探索整个设计过程,找到亮点并发掘改进机会。理想状况下,设计评审让团队中每个人都有被倾听的感觉,允许客户给出有价值的反馈。

设计评审中提出建设性意见往往是个挑战,尤其在团队缺乏设计评审的经验时。在敏捷开发团队中,程序员、项目经理、产品经理及其他相关人员坐在一起反馈,你得明白如何应对他们,并且把事情迅速往你的期望方向引导。


UI设计评审的原则


根据我的经验,针对UI的设计评审应当在整个产品设计与研发过程中开展,或者至少以定期的方式,每周甚至每日开展。这么做可以让产品设计可控,尤其在设计需要进行多次迭代的敏捷或者精益产品流程中。开展UI设计评审是一项挑战,不仅需要解释决策,还得耐心听取其它建议。


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


这些期望中的重点是让每个人对你提及的点评细节达成共识。Jason Ulaszek推荐道:


在你点评的设计细节上开始询问背后的原因及意图。为什么我们需要这条信息?对于允许索取这条信息我们设置了哪些期望?我们会用它做什么?如果我们能回答它们,再进入讨论解释各种元素的优劣以及与之对应的不同意见会比较好。


\


为了更好的遵循这个方针,无论是否包含UI设计,我建议遵守适用于任何设计评审的标准原则:


1、表示尊重


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


2、指定角色


开始之前就澄清在设计评审中每个人的角色,最好在逐个点评时也把角色都重申,避免有人感到被遗忘。理想状况是以下三类角色是不同人(往往不大现实)。


-演示者

负责进行设计提案并解释背后思路的人,他需要回答所有的问题,或找出能够回答评审提问的人。


-主持人

最好由不是直接负责设计的人来担任,比如项目经理或产品经理。主持人确保每个人聚焦在主题上,并且每个人的意见都能被听到。


-记录者

此人侧重于记录讨论内容,尤其是确保会议相关结论(另外一条原则,后续会说明)在评审后能够清楚传递。会议记录者不应该被排除在讨论范围之外,尽管他们的职能倾向于让他人更清晰的表达观点。


3、针对当前评审描述项目目标


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


4、回顾目标用户


强调参加评审的人都不是产品目标用户,提醒谁才是目标用户。


5、避免给出答案


参与者将会带有强烈的解决问题欲望,而且会在评审中提出解决方案。然而,最佳方案往往不会在评审时产生。评审的关键是探索问题及讨论潜在的多个方案,帮助设计师拓宽思路并最终决策。


6、对结论形成共识


记录者需要回顾每个参与评审人员提到问题的结论,以便在下次评审中大家形成共识。


不幸的是,UI设计评审经常在视觉细节上死磕,而忽视交互层面的更影响设计的内容。因此,对UI设计评审,我们增加了几条原则:


7、澄清设计媒介


在跟听众讲解设计时,记得提及产品界面展示的平台及相关技术。这是个iPhone应用?一个网站?是否使用AngularJS技术或者C#开发?确保这些都充分考虑,否则你的设计方案可能完全无效。


8、勾勒流程


你得了解路线图。对于UI设计来说,应该是用户体验的流程。或许是故事板、用户旅程图或者其它描述流程的方式,每个参会者都应该在点评界面之前充分了解整个流程。


9、演示产品,而不只是描述


我得再次强调:伟大的用户体验应该更多的展示出来,而不是口头描述出来。用户在不必解释的情况下就应该明白产品如何工作。你的演示需要尽可能少的语言解释,就好比老话说的:好的UI就像笑话一样,如果需要解释,那么肯定很糟糕。


10、提出正确的问题


设计评审中的大量提问与评述跟协作精神有较大冲突。我推荐一些在探索设计时的开放对话中可以用到的问题,比起导致激烈PK更容易促成协作,你可以推荐给你们团队试试。


\


如同激光测量精度跟肉眼估算测量精度对比一样,可用性测试比设计评审更加精确,也更加费时费力。常规设计评审对于项目实现目标没有直接价值贡献,也无法取代真实用户现场测试。如果只进行评审而不去做可用性测试,得到的结论就是自high。


原文地址:

https://www.smashingmagazine.com/2016/08/running-a-ui-design-critique/


译者:

阿里巴巴_B2B_UED 舒舟

本文来自PS教程网www.46PS.com,转载请注明!关键词:GUIGUI教程原创自译教程


PS教程