磨刀不误砍柴工！打开软件前应该执行的四个方面

　　初入行(算上实习)时的我，在接到一个来自产品经理的口头需求后，经常犯、现在也会偶尔复发的一个错误就是粗略了解思索一下，就立刻打开软件投入到对解决方案的探索中去;在需求比较小/项目时间紧急的时候，这样做的概率会变得更高。初衷是希望能节省时间、加快交付速度，但实际却会出现一开始就跑偏了方向，解决方案需要完全推倒重来的情况，结果反而耗费了比预期更多的时间来完成项目。在学校接受设计教育时，我们都知道，在打开软件进行正式的设计工作之前，需要花上很多时间来进行前期调研、分析、头脑风暴、草图等;而在实际工作中前期准备也非常重要，现在我正在培养一种意识，在打开软件前先告诫自己一句：「该做的事都做好了吗?」

　　沟通了解项目背景

　　其实这点在之前的文章里已经提到过很多次了，当产品经理本身足够靠谱的时候，这部分并不太需要设计师花很多时间去主动沟通了解，他们会通过文档或口述的方式把设计师应该关注的项目背景信息都说明得一清二楚。但毕竟你也不能指望一直遇到足够靠谱的产品经理，如果他只是简单粗暴地说一句「XX你做一下这个功能/图标的设计」，就需要设计师自己有意识地主动去询问、确认清楚相关信息了。

　　在做新的产品设计之前，需要了解清楚产品的目标用户定位与具体的用户画像描述，本次设计的页面/功能/图标具体是为了解决什么问题，要改变怎样的业务现状，改进怎样的体验痛点，判断这个需求是否真的能解决业务与用户的问题，还是只是隔靴搔痒(当然，对设计新人来说这点可能比较难，有时明明直觉不靠谱却又难以说服产品经理，这时请教/求助组里资深的设计前辈会比较有用)。否则的话，如果遇到的是靠谱的产品经理(嗯我现在遇到的都很不错)还能蒙蒙过去，遇到拍脑袋提需求的就有方向南辕北辙、需求中途被砍、辛苦设计出来的方案最后完全用不上的风险了。

　　明确数据和相关衡量指标

　　一个设计方案是否取得了预期效果，上线后的数据会是一个非常有力的评判工具;而后续的迭代优化，也往往需要围绕某一数据指标的提升展开。过去我对产品的数据这块漠不关心，设计之前完全不清楚产品的各种数据指标现状，只知道要提升一个整体的XX率;设计做完了上线了就和没事一样，并不关注设计方案的实际市场反馈如何，知道那个整体的XX率提升了就满足了，而不关注是否真的是设计的贡献，是否具体在交互流程某一个或几个环节还存在问题。

　　现在刚刚开始尝试在一次产品设计改版中做出一点改变，在设计之前，先和产品经理了解清楚本次设计需要达到的目标是什么，这个目标是通过什么数据指标(UV?PV?流失率?转化率?满意度?)的提升来衡量，迭代前的产品数据如何，在交互流程各步骤的分布情况如何，有哪些是可以通过设计上的改进来达成的，等……将其作为设计过程中的思考方向引导和设计上线后的跟踪验证标准之一。

　　竞品资料搜集分析

　　竞品分析环节并不是说要像做专业、规范的竞品分析报告那样，实际上紧张的项目排期也往往容不得我们花大量的时间精力在这一环节。但平时可以有意识地多玩多搜集应用网站(我算万年iOS+Android双机折腾党，虽然现在做移动端的机会不多应用玩得也少了些，但习惯仍然保留)，在脑中构建起一个知识索引库，真开始设计的时候能迅速举一反三出多个案例，而不是茫然地想：「看上去好像没有什么竞品可以参考啊?」

　　对于在BAT等大公司实习工作的同学，公司内网各业务线各部门UED的资料也是一个不小的宝库，只要善于主动去发现与挖掘，我就会去找一些公司里相似产品业务的设计文档来看，看看工作经验多很多年的前辈们是怎么考虑问题、找到解决方案的。

　　当然这一环节有一点是一定要注意的，要知道竞品本身存在产品定位、目标用户、使用场景上的差异，不能被表象迷惑无脑抄袭，做出完全不适用于当前产品的设计方案。

　　善用纸笔来思考、表达与沟通

　　使用软件做前期的设计草案探索有一个坏处，就是有时会不自觉地陷入到对一些当前无关紧要的细节的追求中去，如果有过视觉设计背景的话这种情况可能更多。我自己有时就会在整体布局方案都还没确定的时候先去纠结对齐、字号、多状态处理、特殊场景一类的问题，结果后来整个方案被推翻，这些细节也就失去了价值。

　　最近在做草案阶段的时候，我开始尝试回归用纸笔思考表达，让自己的注意力保持在全局框架上，避免中途被某个细节勾走分心，纸笔想得差不多了再打开软件勾勒线框图。同时纸笔也是一个很快捷方便的前期沟通工具，有时精心画出一个线框图/视觉稿给需求方看，结果被说完全不是他想要的，造成较大的返工成本;如果前期就能通过便签、草图一类方式和需求方沟通甚至协同创作，看上去时间增多了，但长远看来却能减少更大的无意义返工成本。