Base Architecture
Upgrade

这不是一次普通改版，也不是局部体验优化。

这是一次产品骨架重构。

在这个项目里，我解决的不是「某几个页面不好用」，而是一个更根本的问题：多维表格原有的信息框架，已经开始同时拖累业务扩展效率和用户理解效率。

产品还在增长，功能还在增加，业务也在往更复杂、更开放的方向走，但旧框架已经越来越难支撑这些变化。继续在原结构上打补丁，只会让问题越来越重。所以这次项目的本质，不是优化界面，而是重构信息架构，让产品重新获得继续演进的能力。这个专项在内部也被定义为：为产品扩容做准备，并在 H1 明确方案、H2 推动落地。

这次重构到底改变了什么——下面按四个维度展开。

1. 01
   从「能承载当前功能」到「能承载未来扩展」

   BEFORE 旧框架可以勉强支撑当前使用，但一旦功能继续增加，结构就会迅速变得拥挤、混乱。团队讨论周期长，很多方案只能满足眼前需求，无法形成长期稳定的产品骨架。当时多维表格正处于快速迭代阶段，下一阶段预计会引入更多开放生态能力，而现有信息框架的扩展性不足以支撑扩展。

   AFTER 我主导重构了 Web 端的信息架构，核心目标是建立一个高扩展性、高稳定性的框架：它不只是把现有信息排得更整齐，而是为未来的数据表扩展、视图扩展、工具栏扩展以及生态能力预留稳定结构。
2. 02
   从「用户会用，但不理解」到「用户第一次真正理解结构」

   BEFORE 原有框架里最典型的问题，是用户对「数据表」和「视图」的关系理解不到位。树状结构让用户容易把它们误认为是同一种事物的上下级分类，因此用户在寻找「新建视图」时会浪费很长时间。这不是一个命名问题，而是结构表达和用户心智模型之间已经发生了偏差。

   AFTER 这次重构的一个核心成果，就是重新组织了表与视图的关系表达，让用户不需要先理解复杂产品概念，也能直觉地区分它们的角色与关系。上线后用户明确反馈：「理解了表和视图的关系。」问题不是被遮住了，而是真的被解决了。
3. 03
   从「功能存在但难发现」到「能力在对的场景被看见」

   BEFORE 旧框架下，部分能力虽然已经存在，但因为架构表达问题，用户很难发现；尤其是高阶能力，触达门槛更高。体验问题不只是操作效率低，也包括功能易发现性弱。

   AFTER 我在这次重构里同步梳理了工具栏和高阶功能入口，把入口层级、触发路径和扩展规则一起纳入设计范围，而不是只调整左侧结构。最终不仅完成了信息框架重构，也推进了高级功能入口优化和多场景兼容。
4. 04
   从「单点成立」到「系统成立」

   BEFORE 如果新框架只在主场景成立，却无法兼容 doc、sheet、wiki、feed 等平台内场景，那它仍然是一个局部最优方案，后面还会引入新的冲突和返工。所以从立项起我就把它定义为平台级结构问题，而不只是单点页面优化。

   AFTER 这次设计没有停留在主界面，而是把主框架优化和多场景兼容一起纳入判断范围：一边保证主链路更清楚，一边尽量为后续跨产品一致性预留空间。这也是为什么我会把这个项目定义为「产品骨架重构」，而不是「Web 端框架优化」。

业务背景

多维表格处于快速迭代期，接下来预计引入更多开放生态，进行各模块扩展。现有信息框架，包括移动端在内，扩展性还不足以支撑后续增长。同时业务希望通过这次专项明确后续 UX 框架方向，去支撑更高的渗透率目标。

产品背景

从实际使用规模来看，数据表和视图的平均数分别达到 7 个和 5 个，左侧面板已经承载接近 35 条内容。也就是说，这不是未来才会发生的问题，而是当前结构已经在真实使用规模下接近极限。

市场背景

竞品如 Monday、Airtable、Coda 等都已经通过更清晰的信息层级、分类管理能力、扩展位和开放能力，承接更复杂的企业场景。核心亮点包括：文件分类管理、收藏夹、表名称突出、视图切换清晰、block 或面板扩展新场景等。多维表格要在同一竞争维度上站得住，底层信息结构必须先升级。

体验背景

用户已经在实际使用中暴露出对架构理解的问题，尤其是「表」和「视图」的关系误解，以及因结构导致的操作效率低、功能可发现性弱。这些问题已经不适合再通过零散优化来修补。

这个项目里，我最重要的价值不是「参与做方案」，而是先做出了几次关键判断。

判断 1：这次不能做局部优化，必须做结构级重构

如果只围绕某些入口、某个导航、某个新功能点去优化，问题只会被延后，不会被解决。因为旧框架的问题不是局部缺陷，而是整体结构已经无法同时满足业务扩展和用户认知。

判断 2：要先解决用户认知问题，而不是先追求功能堆叠

如果用户连「表」和「视图」的关系都理解不清楚，那么未来加再多能力，都会继续建立在错误的认知上。这个项目必须先把结构讲清楚，让用户知道自己在使用什么。

判断 3：新框架要同时服务「现在」和「未来」

好的信息架构不是只适配当前页面，而是今天能跑、明天还能加。未来的生态能力——插件市场、模版生成、插件组合等——都需要底层框架从第一天就具备延展性。

判断 4：这是一个平台问题，不只是 Web 页面问题

所以除了主框架本身，我也把 doc、sheet、wiki、feed 等兼容场景纳入判断范围。哪怕这些场景当时优先级没有那么高，也要至少先评估风险和边界，否则未来一定会返工。

1. 先把问题从「体验优化」提升为「框架升级」

这是项目能成立的第一步。如果团队仍把它理解为「优化左侧结构」，那么后续讨论一定会陷入局部方案争论。我先把这件事定义为一个信息架构专项，目标是重建产品骨架，而不是修某个点。

2. 用「业务需求 + 用户问题 + 竞品原则」建立推导逻辑

我把设计推导拆成两大部分：一是「高扩展性与稳定性」，二是「框架清晰度与明确分类」。

也就是说，我不是先出方案，再去找理由，而是先明确：

• 未来业务会怎么扩
• 当前结构为什么撑不住
• 用户到底在哪些地方理解错了
• 竞品里哪些原则是可迁移的

这样团队后续的收敛会快很多。

3. 把方案设计拆成几个关键结构层

前期探索主要包括：信息框架、数据表与视图、工具栏、字段扩展。我把这几个部分放在一个系统里看，而不是分别优化。因为它们表面上是不同模块，本质上都在回答同一个问题：

4. 推动方案细化与跨团队收敛

这类项目的难点不是设计师自己想清楚，而是能不能让产品、研发和业务方都接受这不是「重做一遍」，而是「为未来节省持续成本」。所以在推进过程中，我会更重视：

• 让讨论围绕原则，而不是围绕个人偏好
• 让团队看到新框架为什么能更好承载未来扩展
• 让大家理解，这次投入换来的不是短期页面变化，而是中长期的结构稳定性

5. 通过 Demo 和测试设计，把方案从纸面推进到验证阶段

我设计了 Demo 测试计划，包括外部 10 位、内部 4 位，共 14 位用户，覆盖新能源汽车、电商、游戏、企业服务等行业，并有意识地区分小白和 maker两类用户。

这一步很关键，因为信息架构项目如果没有真实用户测试，很容易停留在「设计师觉得更合理」。我希望的是，用真实用户行为去验证：

• 操作效率有没有提升
• 任务完成时长有没有缩短
• 新功能发现率有没有提升

这次交付不是只做了一个主界面，而是覆盖了整个框架系统。

信息架构本身

重构整体层级，明确主结构与扩展位的关系。

数据表扩展

兼容未来表分类、置顶、数据源关联等场景。

视图扩展

不仅梳理视图与表的关系，也考虑未来更多视图能力，包括地图视图、Figma 视图、飞书云文档视图等。

工具栏扩展

同步考虑工具栏扩展与自适应规则，而不是让工具栏继续被动堆积。

字段扩展

与信息架构、表/视图、工具栏一并纳入同一套骨架思考。

未来生态能力

包括插件市场、插件详情、模版生成、模版使用等未来能力，也被纳入长期探索范围。

这次项目最后拿到了比较明确的正向信号：

• 各反馈群整体反馈正向，用户集中评价为「设计优雅」「布局直觉」「操作体验优于旧版」
• 用户反馈「理解了表和视图的关系」
• A/B 实验综合收益 +68%
• 外部用户明确反馈「点赞，比之前好多了」「新版很清晰」
• 高级功能入口完成优化，并推进了多场景兼容
• 冲刺阶段 4 天完成 26 个页面方案，支撑高效对齐与推进
• 核心干系人高度认可，并帮助业务在后续开放生态建设上形成共识

这些结果对我来说很重要，因为它证明了两件事：

第一，这次重构不是设计层面的自我感动，而是真的改善了用户理解和业务效果。
第二，信息架构这种「看起来不如新功能显性」的项目，只要做对了，反而会对整个产品后续增长产生更深的影响。

如果从作品集表达的角度总结，我在这个项目里的价值，主要不在「做了哪些页面」，而在以下四点：

1. 识别真正的问题

我识别出真正的问题不是界面细节，而是产品骨架失衡。这决定了项目能不能从局部修补升级为结构级重构。

2. 把复杂问题组织成可推进的命题

我把业务扩展、用户认知、功能发现性和平台兼容性，收敛成一个清晰的信息架构专项，而不是让团队在零散问题里打转。

3. 用设计 Owner 的方式推动共识

这种项目不是靠一个好方案就能落地，而是要持续推动产品、研发、业务理解为什么必须重构，以及重构到底解决什么。

4. 在开放生态前把底层框架搭对

这次项目的真正价值，不只是改善了当下体验，而是让多维表格在未来扩展中少走很多弯路。

这个项目最终证明的，不是我能把页面做得更清楚。

多维表格这次信息框架重构，本质上是在做一件更长期的事：把一个已经长出来、但开始失衡的产品，重新拉回可持续演进的轨道。

这也是我理解的设计 Owner 价值：不是只在需求明确后把界面做出来，而是在产品复杂度开始上升时，先识别骨架问题，并推动组织在还来得及的时候，把基础重新搭对。