工作总结

发表时间：2026-04-09

（参考）产品设计员试用期工作总结。

说来有点不好意思，转岗做产品设计的这半年，我干的“闲事”比画图多。以前在另一家公司，我只管把原型画漂亮，交互逻辑差不多就行，剩下的交给开发去猜。结果呢？开发猜错了，回头骂设计没想清楚；产品怪设计不接地气。我夹在中间，心里委屈但嘴上不敢说。

这次试用期，我硬是把自己从一个“画图员”掰成了“搅局者”——需求评审前就拉着开发、测试、产品一起过草稿，连业务方的一线操作工都不放过。说句实在话，过程挺折腾的，但结果让我自己都意外。

从“闭门造车”到“蹲在工位旁边问”

入职第二周，接到“智能巡检系统”移动端的设计任务。按老习惯，我闷头三天画了一套高保真，图标精致，动效流畅，自我感觉良好。评审会上，前端一看就问：“这个设备状态字段，后台接口还没定，你怎么画上去了？”后端补得更狠：“按你这状态流转逻辑，得调三个接口，性能根本扛不住。”

会议室安静了五秒。我当时脸上发烫，心里想：以前不都这样吗？设计先出，后面再改呗。但这次不一样——项目经理出身的那股劲儿上来了，我当场没反驳，会后拉着产品、开发、测试，搬了把椅子坐在开发工位旁边，对着业务流程图一边手绘草图一边问：“这个字段从哪来？这个状态谁触发？断网了显示什么？”

就这么折腾了两天，最后出的设计稿，修改次数从之前的五次以上降到了两次以内。那次之后我就记住了：设计不是画完扔过去的东西，得让人家看得懂、接得住。说白了，就是把设计拆成一个个小问题，塞进每个人的日常里，别等到最后才亮出来吓人。

“完美主义”差点害了我

试用期第三个月，做“数据看板大屏”。按我以前的做法，会先把所有图表样式、筛选器、配色方案打磨到极致，再出全套文档，怎么也得两周。但这次业务方只给了三周就要上线演示，开发天天催。

我咬咬牙，做了一个冒险的决定：第一周只画核心的五个指标卡片和主趋势图，其他次要图表全部用灰色占位符代替。画完连原型都没转成正式文档，直接打印出来，揣着纸跑去运维部、销售部、仓库，找那些真正要用看板的人挨个问：“你最想看什么？如果只能留三个信息，是哪三个？”

结果让我哭笑不得——业务方提的需求文档写了二十多个指标，实际一线的人只关心其中七个，剩下的都是“有也行，没有也不影响”。有个老库管员指着纸上的一个库存预警色块说：“以前那个看板花花绿绿的，我看一眼就头晕；你就告诉我今天哪个货架快空了就行。”

最后上线的大屏只保留了九个核心指标，但每个都能直接指导行动。运维组长后来跟我说：“以前那个看板我们从来不看，现在每天早上第一件事就是打开它。”你猜怎么着？那些被砍掉的次要指标，到现在也没人抱怨过。反倒是如果按老方法全做出来，不仅开发要加班，看板也会变得臃肿难用。这事儿给我上了一课：完美主义在真实需求面前，有时候就是自我感动。

当了一回“翻译官”

试用期里最头疼的，是“工单流转模块”的权限设计。产品经理的逻辑很清晰：按角色区分查看、编辑、审批权限，细化到每个按钮。开发一看需求文档就炸了：“按你这写法，光判断条件就要几百个，维护成本谁扛？”

两边开了两次会，都在互相甩逻辑图，谁都不让。我夹在中间，急得嘴上起泡。后来冷静下来，想了个笨办法：把现有的十几种角色近三个月的操作日志导出来，用Excel统计每个角色最常用的操作类型。统计完我自己都愣了——百分之九十的操作只集中在三种模式上：只读、编辑、审批。

我把这个数据打印出来，第三次开会时往桌上一拍，说：“咱们别吵了，就看事实。能不能只做这三种通用权限模板，然后像搭积木一样给每个角色组合？”产品经理看了数据，沉默了半分钟，说：“可以，但审批流的节点配置得保留。”开发负责人算了算工作量，从原来的两百人天直接降到五十人天，当场点头。

那次之后，我跟开发的关系明显好了不少。有一次他请我喝可乐，说：“你要是早来半年，咱们少吵多少架。”我嘴上笑着说“应该的”，心里其实挺感慨——跨部门协作这事儿，说白了就是帮彼此找到一条既省力又能达标的路，不是谁压倒谁。

摔过的跟头才记得住

当然，试用期也不是光鲜亮丽。最丢人的一次是“消息通知中心”的设计。我花了很多精力优化界面细节，按钮圆角、阴影深度调了好几版，却忽略了最要命的东西——通知的优先级排序。结果上线第二天，车间主任打电话来投诉，说设备告警消息被一堆系统通知淹没了，差点没看到。

●读书笔记吧DsBJ1.CoM编辑部新电脑必装内容:

产品设计经理试用期总结 | 产品研发项目部设计员试用期总结 | 产品开发员试用期工作总结 | 产品试用期工作总结 | 产品设计员试用期总结 | 产品设计员试用期总结

我当时恨不得找个地缝钻进去。测试其实提醒过我，说“这个优先级逻辑好像不太对”，我没当回事，觉得是小事。后来连着两个周末加班补版本，重新梳理了十二种通知类型的紧急程度，做了分级推送，才把用户拉回来。那两周我心里一直堵得慌，也终于明白了一个道理：设计做得再漂亮，如果连基本的信息传递都搞砸了，就是零。

还有一件事，说出来有点丢人。有次为一个按钮的投影阴影参数纠结了两天，一会儿觉得太深，一会儿觉得太浅，反复改。后来开发忍不住说：“哥，这个按钮在页面上一共就出现三次，没人会盯着它看两秒以上。”我愣了一下，回头想想，那两天纯属浪费时间。从那以后我给自己定了个规矩：凡是一个细节琢磨超过半小时还拿不准，就停下来问一句“这真的影响用户决策吗？”

接下来怎么干

试用期结束了，但那些摔过的坑我得填上。接下来三件事，我已经写在工位旁边的白板上了：

第一，把这次试用的经验整理成一份“设计-开发协作检查清单”，不是什么高大上的文档，就一页纸，每次需求开始前对着打勾。比如“数据接口确认了吗？”“极端情况兜底方案有了吗？”——这些血泪教训，不能让后来的同事再踩一遍。

第二，主动申请跟着销售和运维去跑现场，每个月至少跟一次真实的巡检或者晨会。坐在工位上猜需求，永远猜不准。

第三，每周五下午留出两小时，什么都不画，就去听开发和测试骂娘——不是字面意义上的骂，而是听他们抱怨哪些设计让他们难受。说实话，他们吐槽的很多问题，改几处交互就能解决，只是以前没人愿意坐下来听。

这半年，我最大的收获不是学会了哪个新软件，而是学会了一件事：设计稿不是我的“作品”，是团队达成共识的“草稿纸”。真正好用的产品，从来不是一个人关在工位里画出来的。这个道理，我会一直记着。

推荐阅读:

产品研发项目部设计员试用期总结(汇集26篇)