读《破茧成蝶》——用户体验设计师的成长之路；（五）

以前预估项目时间，有的 pm 总是说我，"很好，时间挺快的呀"。但是多数项目流程走下来，实际的出终稿的时间明显大于开始预期的时间。我总结了一下：原因1，我没有估算需求沟通，设计规划，问题讨论的时间，而只是给出了画稿子的时间。原因2，之前的项目出了一些问题，或者到了测试阶段，需要你投入时间参与。这部分任务会突然插入到你的当前工作时间中。回头想了想，实际工作时间的占比中，画设计图的时间只有30%不到，50%的时间是在沟通和构思。

本章讲的是，你的初稿出来了后，你要把工作时间用在哪

你需要进行项目跟进

• 如果产品没有以预期方案上线，出了体验的问题，吐槽的肯定是产品设计不好，而不是开发实现的问题
• 设计师如果不去跟进项目，自身的存在感和价值就会大大降低

做设计评审的主导者

• 评审的问题：

评审的时候，不同的角色会有不同的偏好和看问题的出发点，讨论和争执肯定是无法避免，因此，作为做出方案的设计师很容易成为"抨击"的焦点

• 回归评审的目的

1.检验设计方案是否到达了最初确定的需求目标
2.发现问题：相关角色能给出从他们的角度看到一些问题
3.达成共识

• 设计师要做什么？

1.考虑可能的方案
2.准备各种设计依据
3.做好会议邀请 工作：不是所有的问题都是要抛在评审会议上，而是要事先和一些项目相关人员和主要项目负责人达成共识
4.写好会议邮件

• 会议技巧

1.推导设计方案，而不只是给出方案
2.提高效率，控制话题：比如，与会人员会提出一个新的想法，将现有的设计方案完全推翻，灵光一现的点子听起来确实不错，但是可能缺乏深思熟虑。再比如，就是对设计细节的过多讨论
3.区分和收集有价值的意见
不要过于纠结于那些主观带有个人偏好的意见：比如，这个颜色不好看；通栏更加大气
小心那些比较模糊的意见：比如，这里很奇怪；我也说不好，有没有更好的方案；这里操作很诡异
所以要收集那些客观明确，可以反馈的意见
此外，保持一个开放的心态，不要过于捍卫自己的设计方案

• 评审之后

1.细化修改意见，形成最终的方案稿件，发给项目成员

• 评审的价值

1.建立自身口碑的过程
2.体现专业素养的展台
3.建立项目成员之间的信任，为后面的再次合作建立良好的基石

• 作者的吐槽：

很多设计师觉得自己不被重视，没有存在感，方案经常被推翻，没有主动权等。但事实上，很多情况下，是设计师的工作没有做到位！如果能多花一点精力在设计规划，设计评审，后续跟进和推动上，而不是仅仅画一个线框图，那么设计师的处境就会改善不少。

审核视觉稿

• 对交互稿理解是否正确?
• 拒绝毫无发挥的视觉稿
• 视觉层次是否清晰
• 关注交互细节和状态标注
• 审美方面不要过分干涉

开发阶段，设计师要做什么？

• 问题：测试的 DEMO 和心中的设计效果相差甚远
• 工程师关注的重点：简洁的代码，快速响应，可复用的控件
• 所以设计师需要和工程师沟通到位：
  1.一个交互效果在实现的时候需要较大开发成本，需要修改交互稿，如果这件事情能在项目开发前沟通并发现，当然是最好的。如果不可避免的出现在了项目的开发过程中，就需要设计师和 pm，工程师及时做好沟通 工作
  2.设计说明的文字，不会有人一个字一个字的去看。所以在设计方案完成后，一定要和工程师当面沟通方案

3. 规范自己的设计稿，尽量采用和前端同样的规范和标准进行标注

在开发完成之后进行设计走查

主要包括以下内容

• 交互动作，操作和反馈各种状态
• 默认
• 极端
• 极限
• 出错
• 第一屏高
• 悬停状态
• 文案
  这些小细节是开发阶段很容易被疏忽的