2023年ToB产品设计：关于产品重构任务的思考重构

ToB产品设计：关于产品重构任务的思考重构最近接到一个任务，需要重构后台某管理模块。重构，开发听了头痛，测试听了难受，产品听了流泪。但先不要难受，先刨析需求。

一、重构是对旧产物的一次重要改革升级

（1）不是任凭一个任务，都能叫重构

之所以要重构，必定是落后的产品设计已经不满意当前日益增长的产品需求，同时可能影响到当前的使用稳定。重构也是对败絮其中的一次反思，在不影响当前产品力量的状况下，对产品进行重新思索并优化设计。重构同样也可对原先设计缺陷进行完善补充，让功能体验更加完整。

（2）重构需要依据实际状况打算其程度

开发常见的重构基本是代码重构，比如优化代码性能，提高代码健壮性等，而产品的重构则等同于重做。最惨烈的无非是从产品底层由下至上开头重构，不过这种尤为罕见。一般状况下主要针对产品的信息结构层和功能模块层进行重构，可能是由于产品早期规划不够长远，随着产品不断迭代升级，导致产品使用起来信息过载或者功能混乱。

（3）重构的时机同样需要天时地利人和

对曾经走过的路再走一遍，现实中叫浪漫，研发中叫成本。许多时候需要先解决从0到1的问题，再考虑其他天长地久日久生情，用最小成本尝试，然后再依据业务进展状况进行产品周期迭代，灵敏开发精义首先就是要快。用唯快不破的速度争取机会，用日益增长的趋势换取信任，才能赢得一点点重构的时间。

二、针对产品重构任务的预备工作

所以推断任务目的，分析利害程度，评估可用时间，是拆解重构需求的基本反应。

果不其然，打开产品管理模块的信息详情页，各种信息五花八门，一头雾水。此次重构应当是由于页面的信息组织和展现出了问题，即针对产品信息结构层的优化。

页面是信息的载体，目前我面临的问题如下：

信息较为繁杂，不利于猎取目标信息存在部分高风险配置，会直接影响线上用户存在多个易混淆的权限开关各种不明所以的参数这可能就是古老传奇的一种产品设计，叫做专为功能服务的设计。目的就是只满意功能和当事者的需求，不考虑其他使用者的感受。

追溯其历史缘由，可以总结如下：

汇合多个产品模块信息，当时没有做好模块划分因部分需求需要新增参数信息，直接随便插入，且没有任何提示说明灵敏开发太灵敏，没有留下产品文档遇事不乱，先谈几段，无非破案。重构的需求不行能平白无故产生，本次案件不抓嫌疑人，不追究罪证，只找核心受害者和关键证人，细探解决案件的蛛丝马迹。

通过紧密的取证，该任务需要解决的难点如下：

涉及到后端接口特殊多且简单，需要平安平移迭代。部分业务权限管理没有形成闭环，需要收集整理并且补充前端设计。高风险操作易如反掌，需要针对信息权限以及操作进行规范部分知情人士已不在，需要协调各方查验水之呼吸，在问题与缘由的空隙间，找到致胜的那条紧绷的关键线：信息所属模块？信息作用？信息展现？

逐一击破即可。

三、信息重构的解析刀法

壹之型·信息整理：制作远航的蓝图

先整理出来当前版本的信息清单，每个信息对应着参数的设置或展现，但一开头先不用太注意表现层的展现（由于有可能之前设计的展现是错误的），把每个信息记录下来，为接下来的信息处理做好预备。

在这里主要使用表格或者思维导图，前者便利文档存档，后者便利归类分支，可依据实际状况选择，本次我选择后者，由于思维导图更满意本次信息整理的需求，无论是加解释、改分类还是添关联，都可以一目了然：

这时候，一份基础的信息结构图就完成了，作为最初底版，哪怕后续改动频繁，也可以快速回顾原始版本。

贰之型·信息初步分类：调整方向的罗盘

有了基本的信息清单，依据个人对平台产品的理解以及负责的相关业务，其实可以对当前信息进行初轮分类。

此步骤可以避开信息从头开头遍历梳理的成本，每个人对信息的掌控程度不同，所以需要产品本身输出一份标准定义的文档，以便统一用户对产品的信息认知。

通过该轮也是关心自己回顾产品细节，带着问题再去询问别人，可以高效率解决问题，同时降低沟通成本，而非直接把信息清单甩给别人补充完善。

叁之型·信息明确：清晰每一步的去处

这一步就需要费些功夫，因需求和业务负责人不同，需要找到蛛丝马迹顺藤摸瓜，追溯信息根源。在这里主要就是与相关知情者沟通沟通，不断完善信息。

信息明确在于要清晰该信息或参数的作用，比如某某调用次数是怎么回事，高风险操作为什么会有风险，配置信息配置后会有什么效果，开关打开或关闭会产生哪些影响。清晰了作用，才能依据不同的信息类型设计不同的样式展现，符合直观使用感受。

这步骤需要费些精力和时间，检验标准我觉得一句话就可以概括：假如连自己都无法表述清晰，说明自己并没有完全理解。信息的加工整理本身就属于独立思索的一部分。

肆之型·模块归类：整理成果的分箱

信息意义作用清晰，会发觉需要增删信息模块，同时也要优化原来不合理的信息分类。在这里作为一个总指挥，依据手中信息重新排兵布阵。

模块信息的划分带有其鲜亮性。一个是数据规范，有些是跟开发数据库表结构直接对应得上的，比如订单里就肯定会有商品名称、价格、交易时间等。一个是业务规范，比如鉴权业务涉及到的鉴权开关，调用次数设置等。

模块信息的作用类似用途分明的场所。进到不同的模块，接收并处理对应业务的信息。比如进到数据统计模块，看到的就是清楚明白的图像报表等，进到某某设置模块，就是整齐排列的开关等。

这时候一份全新的信息结构图就做成了，产品的信息框架可以使自己更好的理解产品全貌，尤其是后台产品，最关怀的是数据流、数据处理、数据交互。

伍之型·原型设计：简释用途的装饰

7分想，3分做。有了信息结构图，也就意味着产品的结构已经初步成型。需要依据信息的重要性选择对应的设计方式：

（1）信息展现形态

信息的类型有许多，而信息的编辑主要有以下几种形态：

开关掌握：基础参数输入：基础联动展现：打开某开关，才会消失。（界面简洁）全局展现：展现全部细节，与联动展现相反，对全部信息一目了然。（2）信息展现权限

对于不同用户，信息的可用性不同，为了避开造成信息干扰，需要依据用户权限合理化展现信息。

即使是内部工作人员，也需要进行权限分类。信息敏感程度由低到高如下：

基础信息：全部人都可以查看。信息设置：简洁的参数设置，可由商务、市场和运营直接使用；简单的参数设置，需要经过产品、测试和研发确认修改。高风险操作：部分操作会直接导致线上产品直接消失问题，需要更高权限的账户才可以查看和设置，且有明确的强警告提示和使用记录。高机密信息：一般不会直接对外暴露，且底层加密爱护。（3）信息操作提示

信息对应到数据，数据的操作基本为增删查改，增要直接明白，删要提示警告，查要权限掌握，改要延迟生效。在这里主要讲一下改。

后台改动参数，可能会导致特别严峻的后果，所以大部分状况下，最好不要马上生效！对数据的处理主要会思索以下几个环节：

数据校验：比如针对表单提交的数据进行正确性校验，比如非法输入等。数据风险：修改后是否会对线上产品造成影响，假如会，目前有两种做法，一种是强制要求必需达到前置条件才可以修改，一种是强警告提示后果自负。明确告知风险是每一个沉熟稳重的产品人必需尽到的责任，产品是给人用的，但总有人想负罪前行，假如背锅太多只会影响设计的手速。数据测试：某些参数设置后的确会对线上产品造成影响，不过影响也不肯定都是坏的，因线上产品本身权限推断过于简单，所以还需要进行数据测试，确保操作生效，符合用户目的。比如某小白组合配置了某选项，这时候跑通测试用例输出测试报告，明确告知哪些配置线上已经生效，避开出问题再反馈再验证再测试等一连串现象。最终的效果图如下（非真实原图，意会即可）：

旧：一目十行，行行迷茫新：模块清楚，层次分明，业务入口直观，操作理解全都四、重构经受的思索提炼

重构并非荣耀，也非形式大于内容。重构是一个无可奈何的选择，意味着要排雷填坑，一不当心就成“烈士”。我会很怀疑为什么产品早期就不能规划好，但我现在也理解，究竟某些决策也只是摸索性试验，只有业务起来了才有产品发挥的空间，成本和收益永久是在博弈状