这部分内容真是说到心坎里去了。工作了一年，发现专业的能力是有所提升，但是管理项目的能力还非常欠火候。很多次没能让pm把需求梳理和确定清楚 ，或者是没有和各个角色建立起一套良好的信息对话方式，导致一些事情没有传递到位，一些问题没有能及时发现，最后导致整个项目改动变多，原型更改多次。另外，在多个项目之间切换的时候，不能很好的进行时间管理，这样很容易导致，投入精力不足，最后导致设计效果欠佳。
项目中的问题
- 留给设计师的时间很少
- 一个设计师负责多个项目，无法一一跟进
- 和项目成员座位太远，不利于沟通
- pm不能清晰的阐述需求
- 开发人员偷工减料，不按照设计稿去做
……
和pm或者项目负责人达成一些共识
- 预留设计中思考，沟通，修改的时间，而不是只有设计原型图的时间
遵守设计流程真的这么重要吗？
作者以自己早期的项目经验来看，可能会遇这些问题
- 需求不明确，反复修改
- 方向不明导致设计方案被反复推翻，设计效果欠佳
- 原型粗糙，开发人员理解起来有困难，开发效率降低
- 上线的效果和设计方案相差甚远
……
和产品经理一起做需求分析
产品定位：目标，范围，特征等约束条件
- 定义产品：使用人群，产品功能，产品特色
- 用户定义：目标用户，使用场景，用户的目标
需求从哪里来
- 用户调研，用户反馈
- 竞品分析
- 产品数据
筛选需求
- 技术不可实现，价值不大，无使用场景的
- 用户的真实目标
- 匹配产品定位
- 考虑项目资源，定义优先级
需求文档
- 不可一概而论
- 一般包括：产品定位，产品需求，需求优先级
- 修改和审核记录，目录，背景描述，用户类型和特征，项目时间安排，信息结构，业务流程说明
拥抱用户
- 把自己当做用户去揣摩用户的心理和目标，是远远不够的
- 用户说的不一定是心中所想
- 用户的想法没有被正确表达出来
- 用户没有意识到自己想要说明
- 该用户可能不是目标用户
- 用户的想法说出了问题，但方案不切实际
设计师的逆袭
识别不靠谱的pm
- 需求变动多，没有想清楚，总是该来改去
- 过于主观
- 过于关注细节
- 不能合理安排时间
拒绝不靠谱的需求文档
- 判断项目的大小，来判断是否需要需求文档
一个大型项目团队，pm没有撰写需求文档，而是直接给出线框图，深入细节，对整个项目团队就是一场灾难
需求文档的作用：
- 帮助pm理清思路：功能，数据限制，业务逻辑
- 方便整个团队沟通
- 帮助项目成员有针对性的提出问题，而不是直接从pm的画的原型图里找隐藏的问题
遇到不写需求文档的pm？
- 首先充分理解，然后督促ta解决这个问题
- 小的功能点则可以灵活处理
- 拿到90%的需求文档中，只是与设计相关的信息结构，任务流程，功能状态和界面说明等，仅作为参考
- 如果只是拿到pm线框图，那么就是和pm多多沟通，然后忘掉这个线框图
如果抄竞品
- 抄不是完全复制对方的界面
- 抄不是懒惰的借口，你需要分析竞品，超越竞品
