阅读提示
建议先通读一遍，再回看题目、开头、过渡和结尾，更容易提炼出可借鉴的写作框架。
对我来说，产品设计就不是画画图、开开评审会那么简单，它更像是一场马拉松，你得有体力，有策略，还得有随时调整路线的准备。今天就跟大伙儿聊聊我这几年跑下来，觉得最实在的几个点。
第一点，别急着画原型，先把“为什么”聊透。以前我特容易一头扎进具体功能里，想着怎么把这个按钮做得更酷。后来吃了几次亏才明白，需求评审会上最重要的不是“要做什么功能”，而是“我们到底要解决谁的什么问题，以及为什么这个问题值得现在解决”。跟业务、技术、用研的同事开会，我开头就拉着大家对齐这三个问题。有一回，做企业内部工具，业务方提了一堆细化功能需求。我们先停下来，反复讨论用户的核心作业流程和痛点，最后发现真正需要的是一个流程自动化功能，而不是把原有界面修修补补。这个共识一达成，后面所有事情都顺了，省了至少一半的反复修改时间。
第二点，设计稿不是最终交付物，你和开发、测试的沟通才是。以前我觉得把高保真原型标注得清清楚楚，扔给开发就完事了。结果呢？实现出来的效果总差那么点意思。现在我的做法是，关键界面和交互，一定拉上前后端开发一起对着稿子过一遍。边讲边问：“这个地方的数据从哪里来？”“这个动效前端实现起来有困难吗？”在开发中期，我每天都去他们工位上转一圈，看看实现进度，有走样苗头当场就拉齐。这么干之后，返工率直线下降，关系也融洽多了，很多技术实现的创意就是这么聊出来的。
第三点，把自己当成第一个用户，使劲用，反复用。在测试环境，我自己会把核心路径跑上几十遍。不只是走主流程，还要想尽办法“搞破坏”，试试各种异常操作。有一次，我就发现一个表单提交成功后的提示一闪而过，用户很容易错过。这种细节，测试可能关注功能对不对，但作为设计师，我必须关注用户感受对不对。把这些问题提前揪出来，上线后的用户反馈才能好看。
第四点，数据会说话，但你要会问。上线后看数据面板是必须的，但别只看转化率涨跌。关键是结合用户行为流，去看“为什么”。比如有一次数据发现某个关键步骤流失率突然增高，光看数字不知道原因。我马上就去查同期做了哪些改动，又调了该步骤的用户操作录屏来看，发现是我们在前一步新加了一个误导性的提示信息。迅速优化后，数据就恢复了。数据是指路标，不是终点站。
最后说一点虚的，但我觉得很重要：别把自己框死在“设计”这个职能里。多了解一点业务目标，就能在设计中更好地权衡商业价值；多懂一点技术实现，你的方案落地性就更强；多听听用户原声，你的设计才会有“人味儿”。经验这东西，就是一边干活，一边琢磨，一边摔跤，再一边爬起来继续跑攒下来的。咱们都是在路上，共勉吧。