编辑导语：当你接盘别人的项目时，你要如何快速上手，做好应对策略？假设这个项目设计得并不完善，你又要如何对其进行拯救和完善？本篇文章里，作者结合一个G端后台审核模块设计案例，对其如何进行接盘以及实操设计进行了总结，一起来看。

年后全盘接手一个Government（简称G端）政府端业务系统的从0-1搭建过程。

该系统对外有个针对服务对象的业务应用（PC+App），对内有一套针对经办人员的后台管理系统。截止目前，按照产品路线图和产品规划，产品对外的功能开发完成度已经100%。

近期，恰逢让客户验收可交付成果，准备项目上线， 因为一个对内的参数管理的业务审核模块设计（早期其它团队完成的），存在客户和本人，单纯看页面已实现的效果，不清楚开发的功能对业务如何起到管理和控制。需要本人重新梳理需求和业务关系，并做必要改造。

截至发稿日期，本人已重新梳理完成，设计此模块原型，研发已开发完成并部署到演示环境。再次给客户演示时，此模块获得有决策权客户的听完讲解“一把过”认可。

借此分享出来，希望对产品人员（ 建议：0-3岁阅读，偏向产品设计实操类 ）做产品设计有帮助。借此文章，我来重新复盘梳理这个审核模块我是如何拯救的？

01

出于项目隐私保密，对审核页面做了适度脱敏处理。下图是接手后台审核模块的参数管理页面（之前其他人设计的页面的原型）。

该页面存在的主要问题 ：对需求理解不到位、设计的页面易读性较差，主要体现在：

• 新增按钮，事项内容太多。囊括人社部门的所有业务，筛选范围太多，导致审核业务与对外服务的事项存在孰是孰非难判定。
• 审核层级关系在该页面体现较差。
• 操作功能权限未根据层级做控制。
• 表格展示方式及部分字段可读性较差。

接下来谈谈，我是如何一步一步去拯救这个模块。

02

首先，掌握待改造模块的需求背景。因为该项目已积累的材料有限，于是找之前的熟悉此模块建设的负责人了解此模块的建设背景，借此知道该模块存在的价值、要解决什么问题。

经过一番多方沟通后，再加上自己的独立思考，确认此模块的用途是为业务经办人员可根据各地市实际情况灵活设置某事项业务进行人工审核还是自动审核通过。

其次，掌握功能的“藕断丝连。

针对前面提到的该页面存在的主要问题 ，第一，我重新梳理模块的事项作用域，即和服务对象使用的需要审核的业务进行事项的筛选，事项目前就三个需要做审核配置，故新增和编辑的下拉事项做了范围控制，开发也重新优化了接口。

第二，基于对该业务的需求的理解，梳理了默认事项约束逻辑和自定义约束逻辑，故重新调整了操作按钮的操作权限并做按钮的必要取舍。比如，经办区域为省的事项不支持删除，故操作不支持删除，事项下的各地市可自由操作（编辑、删除）。展示上，做了一级和二级从属关系的展开折叠效果。优化了页面事项阅读体验。

第三， 基于对该业务的需求的理解，对该业务的表格做了可读性的调整，表格上调整表头字段。把“是否审核”改成“是否人工审核”，并在旁边做了鼠标移入的提示效果（已选择为人工审核，未选择为自动审核通过）。

理由是：目前审核下拉菜单有不审核、都审核、A机构、B机构，如果按照之前的设计，选了A机构，是人工审核还是自动审核在页面体现上不容易区分，显得设计不够清晰、具体化，故做了这个调整 。

第四， 表格新增了字段，即“更新日期”，一方面用于排序，一方面也易于操作人员看到最新设置的最新日期，也算是优化了页面事项信息阅读体验。

第五，查询条件根据实际业务情况，删掉了事项名称。因为该审核模块对外服务的事项就三个，可加可不加，我就优化了这个条件。

最后，和客户确认更改是否满意。伴随着思考而重新绘制原型，如下图原型所示，并与客户进行再次核对交流，不能闭门造车（P.S.所有的改造调整后第一时间需要让客户有知情权，所有的改动要经过客户拍板才能进入研发，顺序不能乱，比较设计是服务于业务人员的）。

当然，实际这个结局是此改造让有决策权的客户听完调整讲解后认可并“一把过”。（如下图原型所示）

该后台审核模块已拯救完成，从这个功能使用来说，相比于昔日，已让它变得更契合客户业务需求，已让它变得更好用了，改造义务已尽到了，完美拯救了一回。

写在最后

我一直把自己接盘别人的项目比作项目的接盘侠、项目后妈，这个过程相比于自己一手获取需求、做设计而言，有沟通路径来的长、很多重要需求信息会被漏掉、信息传达不到位等局限性，所以万分建议做项目/产品需求的童鞋们，平常工作中必要的项目信息做好保存，让必要的组织过程资产做好传承，让项目的接盘侠们工作量减轻点，有更多时间投入生活的怀抱吧哈哈。

本文由 @Confirmsun 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议