当产品进入碎片迭代，设计师可以做些什么

鸿影：我在之前的用户体验设计实践经历中，所做的项目绝大部分都属于『从0到1』，以被动地接收分析产品经理提出的需求、然后不断设计全新的产品或功能为主，一个项目完成后就基本不再管，后续的运营数据也不关心，而是立马投入下一个新的项目中去。这种四处忙碌的感觉看起来很充实，但实际上却有些浮躁，作为设计师没有完整地参与进产品设计闭环，少了数据验证、迭代改进的步骤（这正是当初Mentor不建议我毕业后去设计咨询公司的核心理由，但IT互联网公司不停地出新APP，出完后就不再更新的案例也不少，不点名黑了），对产品也难有产品经理那种Owner的感觉，缺失主动推进产品不断优化改进的意识，发挥出的价值和赢得的话语权与信任感因此受限。但是当长期跟着一个项目时，在完成了『从0到1』的阶段后，就进入了『尴尬期』：整块的设计需求变得很少，更多是功能体验上的修修补补，工作成就感降低；有了一些用户反馈，但缺少系统地整理、甄别，而是盲目地依据反馈修改设计；项目组永远有他们认为更重要的事情（比如修BUG）需要先做，而设计师看起来有些『无所事事』……这种不充实的状况一度令我感到烦躁不安，于是寻求或等待新的项目/功能需求/改版的到来以期结束这一局面，但其实这便回到了本文第一段所说的状况。是我开始思考：在看起来好像『没什么事情做』，有也是各种琐碎修补的产品上线迭代期，我还应该一直被动地『等需求』做设计吗？我是否应该更主动一点去做些什么？用户都有了些什么反馈，这些反馈是普遍还是个别问题？我去实际验证了用户在真实使用场景下的感受了吗？现在体验不好造成流失的点我都知道吗？……然后发现大部分问题自己都回答不上来，『尴尬期』可以做的事情其实有很多，根本不该是『无所事事』的状态。


整合碎片需求，整体改进优化
迭代期的需求相对会很零碎，PD也不太会像之前一样对每个细碎的需求都写一个完整的Prd，作为设计师如果仍然只是被动地接收需求、一个一个修修补补过来，久而久之会缺少成就感与动力，变得有些偷懒：不再认认真真地把每个需求的场景目标都沟通梳理清楚，而是纯粹『画图的』，被各种界面细节上的纠结困住，磨灭了主动跳出来、从全局角度解决问题的意识。意识到这点后，我开始尝试去寻找一些碎片需求的内在规律与彼此间的联系，发现一些需求其实可以纳入同一个场景/流程体系下，于是利用体验地图一类的工具和PD讨论、梳理清楚关键行为节点上所有的碎片需求/待优化点，再统一出新的优化方案，这样设计的时候可以考虑得更加全面、整体。而如果是来一个小需求就改一次方案，就可能因为之前对扩展性的考虑不够而造成需要大幅改造或全盘推翻旧方案，或者将界面逻辑弄得越来越复杂化。


沉浸真实场景，观察发现机会
在产品『从0到1』的过程中，更关注先搭建起核心的功能、框架，而和实际目标用户的接触、观察、访谈的机会是比较少的，没有已经上线的成品，最多做几个Demo找旁边同事测试一下，离真实的用户使用场景还原仍有一定距离。但是产品上线后就不一样了，组里有的设计师会选择坐到真实目标用户旁边，观察记录其实际操作行为，再考虑如何进一步优化设计方案，这一点对于设计师本人非目标用户的ToB产品还是很有效的，也是我目前做得不好的地方，还是有些拍脑袋做设计，离真实用户太远了。所以接下来的工作计划中，会考虑和PD一起去邀约产品的目标用户进行场景模拟，观察他们使用产品的真实情境，发现潜在的优化机会。


关注反馈数据，思考产品改进
在以前实习做移动端ToC产品的时候，我有没事就去各大应用市场评论区、社交网站上搜索浏览用户反馈的习惯，现在做ToB产品后虽然反馈来源减少，但有渠道也会保持关注，偶尔能从中得到一些产品设计优化的灵感。对不愿意只是被动听命PD的设计师来说，关注反馈可以帮他们更好地了解用户、主动去思考如何改进，驱动产品完成创新。至于数据，我还停留在师姐教过的一点理论层面，实际使用得不多，在有真实成功应用案例之前就不多谈了。简单来说，设计师对数据的关注不应该只是一个最终的结果，比如单纯看一个整体的流失率之类意义并不大，而应该结合设计过程中的目标来拆解分析，比如关注每一个具体操作流程节点中的流失率，再结合一些相关的用户访谈结果等，分析思考具体的流失原因，是正常流失？功能内容缺陷？还是交互体验上不够好？进而发现需要在产品设计上进行优化的地方，再改进之。


本文来自鸿影的知乎专栏