
图纸台账 2.0
从“信息坟墓”到“主动式协作中心”的设计重构

业务背景
图纸台账是图纸管理功能模块中,记录图纸从上传到废弃整个生命周期状态流转的空间。台账系统主要涉及上传人、确认人、下发人及多权限管理员 4 类用户角色。
图纸台账 1.0 版本在我加入团队前已经完成。因为当时的核心目标是快速搭建核心功能并上线,所以没有针对不同角色做差异化设计,导致理解成本高、操作路径冗长,严重影响了图纸流转效率。
图纸生命周期状态流转关系图
图纸台账中涉及的状态
问题定位
旧版台账是一个死的数据容器,主要存在以下 3 大问题:
- 所有用户看到相同的数据,所以也会看到与自己不相关的专业、版本的图纸,给自己带来视觉干扰
- 面对大量的图纸数据,各角色在查找关注的数据时,仿佛在一片数据海中捞针,效率低下


设计目标
此次设计的核心目标,是把台账系统从「以数据为中心」转变为「以角色和任务为中心」。
设计实践
在早期明确了图纸台账 2.0 改版要围绕细分用户角色和权限来重构体验之后,我在项目启动前就开始提前探索设计方案。
设计分析
根据 JTBD 理论,用户不是在购买产品本身,而是在“雇佣”产品帮他们完成某项任务。那图纸台账模块本质上是在帮助哪些用户完成哪些任务?
User Task Analysis
| 核心用户 | 主要场景 | 用户任务 |
|---|---|---|
| 上传人 | 上传图纸后 |
|
| 确认人 | 被推送确认待办 |
|
| 下发人 | 被推送下发待办 |
|
| 多权限管理员 | 随时查看操作 |
|
第一轮:激进重构与现实阻力
明确了用户想完成的功能任务后,我最开始尝试引入“任务管理”范式,想把问题拆成「未处理 / 已处理」两种状态来重塑台账体验。
- 未处理的任务:承接用户当前最关心的事项
- 已处理的任务:承接用户次一级关注的历史内容
下面以“上传人”角色为例,展示第一轮探索。


Option A
优点
- 待处理和已处理的内容非常清晰,一目了然。
- 支持不同状态图纸按时间排序。
缺点
- 待处理内容数量过多时展示不佳,已处理内容容易被挤出首屏,需要用户手动展开收起。
- 上下空间紧张,每张卡片只适合展示关键信息,不适合承载太多字段。


Option B
优点
- 模块分区更清晰,同时规避了方案 A 中页面数据展示不全的问题。
- 上下空间充足,适合展示详细信息,卡片高度可扩展。
缺点
- 待处理数据较少时,画面会显得比较空。
- 待处理和已处理分开后,上下文联系变弱,卡片在两个区域间跳变明显,理解成本变高。


内部评审反馈
这套方案在设计评审中遇到了阻力,核心问题集中在用户接受度与研发可行性两方面。
用户层面
- 处理海量工程图纸时,用户更看重高密度数据对比与表格式界面带来的全局掌控感
- B 端用户对熟悉界面存在依赖,大幅改版会提高学习成本,削弱接受度
研发层面
- 方案涉及较大范围的底层重构,研发成本高,落地推进难度较大
第二轮:务实的敏捷设计
基于第一轮反馈,我放弃“全盘推翻”,改成“渐进式增强”。通过“待办区 + 表格”的融合视图,在保留高密度表格的同时,把不同角色当前最重要的任务抬到顶部。
- 保留表格:保住了用户习惯和海量数据的检索效率。
- 增加待办区:实现“千人千面”的核心策略,把不同角色最需要关注的内容放在最显眼的位置。
- 研发友好:界面改动成本小,底层逻辑无需完全重写,ROI 更高。


设计打磨
第二轮方案与团队同步时非常顺利地通过了内部评审。在这个基础上,我继续对页面的视觉层级、字段展示与操作项进行精细化打磨。


细节展开
设计就是在细节里见真章。
代办区展示逻辑
基于用户角色的注意力管理:不同权限的角色只需要关注自己要处理的任务,从而减少决策成本,提高操作效率。

上传人:关注「解析中、待确认」的版本图纸

确认人:仅关注「待确认」的版本图纸

下发人:仅关注「待下发」的版本图纸

多权限角色:关注所有状态的版本图纸

代办区与表格的联动
支持动态布局:代办区的版本图纸被下发后,会自动从代办区流入下方表格,并展示在表格顶部,整体逻辑更接近 transfer 组件的心智模型。

响应式设计
为了营造更流畅的使用体验,我定义了代办区在不同屏幕宽度下的展示规则。
- 设 X = Viewport 宽度 - 侧边栏宽度 290px(64 + 226)。
- 当 X 在 [1024px, 1280px) 区间时,呈现 3 列。
- 当 X 在 [1280px, 1920px] 区间时,呈现 4 列。
- 当 X 在 (1920px, 2048px] 区间时,呈现 5 列。
- 当 X 宽度大于 2048px 时,以每张卡片 360px 计算,横向排列并自动换行。
- 卡片最小宽度 300px,高度固定 65px。
















