离职后你能带走什么？4步打造属于你的「设计职场资产」

当我们总感觉：

1. 努力提升专业能力，做了很多事情，结果却没有被看见和认可？
2. 成长的变化明明有目共睹，但得到了展示机会却不知如何说起？
3. 走过破局之路，在公司拥有了更高的话语权，却担心离开了这个平台所剩无几？

那么，主要问题就不是我们做没做好、做没做对，而是有没有「可见可复用」。

在「设计在公司话语权较低，如何破局？」之前的文章，我们已经走过了这样一段过程：

放平心态 → 回归任务 → 盘点筛选 → 主动提高交付水准 → 基于定位，运用不同方式 → 看见变化，校准方向。

无论成败，走过一段路，总会留得一段经验。

但怎么才算更好的留得这段经验呢？

这一篇，我们一起聊聊：让这些“做好”“做对”沉淀下来，变成这家公司里看得见的结果，也变成离开后还能带走的底气。

一、记录过程：把当时脑子里在想什么留一份下来

当我们真正开始行动，在真实的职场里摸爬打滚。你做过的、思考的，一定远远不止我文章里写到的那些。

从这些东西里提炼和沉淀的，才是真正的、完全适配你现状的「具体标准」。

无标准，不专业。

但这里的“标准”，不再是你想的那个“行业标准”，而是“你的经验标准”：

1. 是你付诸行动、切实体会，确认它们是否对这个组织正确、是否对这个时刻有用的决策经验。
2. 是你反思结果，调整适配，在具体情境下思考的理由、决策的过程，沉淀提炼而来的使用经验。

不生搬硬套、不张冠李戴。这些过程，是我们能力之所以能提高的台阶。

它们具体都是些什么呢？

1. 回归任务：怎么才能看到新角度？又怎么从新角度看到新的、待解决的问题？
2. 盘点筛选：怎么盘点最合适？你基于什么原因筛选的破局的任务？
3. 主动提高交付水准：提高前和提高后有什么区别？为什么你能够/不能提高交付水准？
4. 基于定位，运用不同方式：你运用了什么方式？过程中如何澄清？如何协作？如何推进？
5. 看见变化，校准方向：结果如何？你接下来要怎么做，为什么要这么做？

……

你对这些问题的答案清晰吗？

二、留存结果：用看得见的事实支撑你的观点

如果说上面的结果还能靠我们的感觉来记录，那这里的结果，更接近于我们可以留存的证据。

一次任务的“结果”，至少可以留这几样：

1. 前后对比的画面：关键界面、流程图的 Before / After 截图。
2. 前后对比的数字：上线前后的使用量、转化率、投诉量、工单数等。
3. 前后对比的反馈：典型用户的评价片段（可以是调研记录、客服摘录）；协作同事的反馈，比如“现在开会更好对齐了”“这个流程上线后 bug 少了很多”。

这些都是我们可以在做事过程中收集到的内容，也是我们可以在例会、复盘、述职等会议上拿出来「秀」的结果。

“能力提升了”、“易用度变高了”、”用户更满意了“、“协作更顺了”……都是观点。

讲观点，一定要配事实。

这些留存的结果，就是最好的事实。

我之前这点就做得很不好，导致每次汇报复盘时才开始去翻以前的留言，设计稿里的图，以前的会议纪要……费时费力不说，还总是找不全。

为了不再在复盘前临时抱佛脚，我现在也在刻意培养自己做三件小事：

1. 项目中途和上线后，各截一次关键流程的界面对比图，丢进一个固定的“成果截图”文件夹。
2. 每次有重要数据更新（比如投诉下降、转化提升），在群里同步时顺手复制一份到自己的“结果记录”里。
3. 当协作同事给出正向反馈时，不要只回一句“谢谢”，而是把那段反馈截一小段，记在这次任务的下面。

留存结果，不是为了哪一次“精彩的汇报”，而是让自己在任何时候有机会时，都能拿出“说得明白、看得见”的证据。

三、回顾影响：找到那圈向外扩散的“涟漪”

回顾影响，是为了可复用。

可以从三个角度来思考

首先是对自己的影响

1. 你自己在下一个项目里，有没有自然地用上这次学会的一套判断方式或沟通方式？

其次对其他人的影响

1. 谁因为这次协作，开始更早拉你进场？
2. 有没有谁在后续项目里主动沿用了你这次提的某个做法？

最后是对整体流程的影响

1. 需求评审前必须先过一版用户路径。
2. 评审时必须有人专门盯跨端一致性。
3. 这次之后，团队有没有多了一项“老规矩”，项目里有没有多了一个”小标准“

回顾影响，实际是在帮这件事画出“外扩的波纹”，成为我们展示时的可说、可谈的价值体现。

四、形成一页式设计经验，让经验可以被带走

记录过程，是为了自己可见。

留存结果，是为了其他人可见。

回顾影响，是为了自己和其他人可复用。

当我们走过1个设计话语权提升的过程，就可以从「过程-结果-影响」三个方面，得到一套可见可复用、可以带走的具体经验。

举个我最近的例子：

前段时间我选择了一个突破性任务是做多平台的一致性体验。

这个任务不是单纯的组件、样式统一，更多的是解决用户使用流程上的“割裂感”。背后牵涉的许多问题也一直都有存在。

之前，是我们自己、测试、和研发人员在沟通中的吐槽；后来，是我们去了一趟现场，看到一名前线人员开了两台电脑使用我们这套「多个平台拼成的系统」。

为什么选择它作为这次的破局入口呢？

我知道，多个平台的后面是多个部门，这不仅是表面的协作问题，还涉及到已成型产品的功能设计、后台数据分布……虽然做好了别人能「高度感知」，但大多数时候，做好这个任务还伴随着「高投入、高风险」。

但当时，我们有了三个条件：

1. 各平台基础功能已经完善，上层领导提出了「统一性」要求
2. 现场一线人员反复在各种会议提及了相关问题
3. 我们自己是一个平台性质的小组，我作为负责人，下面的设计师本来就负责这几个平台的UX支持，也本来就属于各组研发流程一环。

所以，我们首先在自己现场调研后的同步会议中再次强调了这个问题，然后又主动与现场交付经理一起设定了初步方案，接着在具体环节也几次主动拉齐各方产品经理、技术负责人以及现场人员的领导参与了设计评审。

目前「多平台一致性」涉及的几个主要问题都已经进入了研发过程，我也借此更深入了解了每个团队的负责边界和可变化的范围，方便下次针对性“拉人”。其中当然有一些不太顺利的地方，比如我第一次拉评审就漏了一些关键人物，某些信息同步的方式也可以再优化等。

总的来说，我们经历过一次破局的过程，就可以提炼出1份属于自己的一页式的设计经验了：

1. 背景 / 问题
2. 我的判断 / 关键动作
3. 结果（数据 + 反馈）
4. 可复用的要点 / 下次还能怎么用

每一次过程，都是对这份经验的再次优化和验证，都是在帮你把这张“经验卡”写得更清楚一点，也是在让你的能力，从只存在于当下这一家公司，慢慢长成可以被带走的底气。

一起共勉、共进。