Ginkgo SaaS

项目周期： 2024.07 – 2025.11 （持续迭代中）

我的角色： 主交互设计师

项目背景：Ginkgo 是为投资顾问打造的资产管理 SaaS 系统。随着功能不断扩展，系统出现了信息层级松散、组件行为不一致、导航结构不清晰等结构性问题，逐渐影响到阅读效率、操作流畅度与模块可维护性。本次重构分为三个阶段推进，分别处理组件体系、导航框架与布局结构三个核心层级。

Understanding the Users

Persona - 投资顾问

作为 Ginkgo 的核心用户，投资顾问负责管理高净值客户的多资产组合，日常需要在有限时间内完成资产监控、持仓分析、收益回溯以及交易复核等关键任务。他们通常具备较强的数据敏感度，对信息准确性和结构稳定性要求极高，希望系统以一致的方式呈现关键指标，并降低在分析链路中的心智切换成本。在使用过程中，他们更关注任务节奏是否顺畅、模块间逻辑是否一致，以及界面是否能够支持快速决策，而非界面视觉本身。

User Journey Map

对于投资顾问而言，Ginkgo 是他们每天分析客户组合的主要工具，因此整个使用过程的节奏感至关重要。系统的入口越清晰，他们越能在最短时间内建立当天的市场与组合概览；信息结构越稳定，他们越能在浏览关键指标时保持持续的判断效率；图表、筛选与透视行为越一致，他们在深入分析时就越少遇到思维被迫中断的情况。过去系统中的结构松散、组件行为差异和布局限制，会在这些关键节点上造成不必要的摩擦，情绪曲线随之出现波动。本次三期重构着力解决这些隐性阻力，使用户在定位、浏览、分析到输出的每个阶段都能保持连贯的专业节奏，减少界面对任务的干扰，让注意力聚焦在资产本身，而不是操作本身

Phase 1: 持仓（Position）组件体系化设计

遇到的问题

持仓页面承载了高密度的资产数据，却缺乏系统化的组件结构：SummaryCard 的信息层级在不同模块间不一致；图表的标题区、Legend 和 Tooltip 的行为不统一；表格设计中与筛选、透视、列设置相关的交互常常出现差异。

这些不一致逐渐累积，使用户在跨模块使用时不断面对额外的理解成本。

问题拆解

分析现有组件后，识别出三类核心交互对象：

问题不在视觉呈现，而在于 缺乏统一的信息结构与交互框架。

方案取舍

方向 1：维持现有结构，仅做视觉收敛

方向 2（最终采用）：建立统一的 Web Widget 体系

包含：

选择方向 2 的原因

在初步讨论中，我们曾考虑过通过视觉统一来减少界面噪音，例如重新调整间距、字号与色彩，但这种方式无法解决组件行为不一致的问题，依旧不能改善跨页面的学习成本。

最终采用了另一种方向：建立统一的Web Widget 体系。通过重新定义 SummaryCard 的信息层级、规范图表的标题区与 Legend 行为，并将四类表格相关弹窗整合为一致的交互结构，使整个系统在“卡片 → 组件 → 页面”这一层级关系上形成稳定结构。这一方式能够从根本解决组件之间的逻辑割裂问题，是更符合复杂系统长期维护需求的方案。

验证

体系上线后，内部投资顾问在数据浏览中明显感受到关键指标更易扫描，图表与表格的交互操作也更具一致性。同时，前端在开发流程中反馈组件复用率显著提升，减少了重复实现的成本，使后续模块的扩展更高效。

反思

这阶段让我更加明确：在复杂产品中，组件并非界面元素，而是系统逻辑的具体表现形式。只有统一组件结构，才能保证系统在快速迭代下仍保持一致性。从长远看，这种体系化工作远大于单一页面的视觉优化价值。

Phase 2: Dashboard 信息架构 & 顶部层级优化

遇到的问题

随着业务模块扩展，Dashboard 的头部承载了越来越多的信息：全局导航、Dashboard Picker、页面级 Tabs、甚至临时入口都堆叠在同一层级。

这种混合呈现方式让用户在最基础的问题——“我在哪“和”我要去哪”上产生额外认知负担，也造成了明显的视觉噪音和层级混乱。

问题拆解

通过对用户任务路径的分析，头部区域实际上承担三类任务：系统范围的全局切换、业务模块内的视图切换，以及页面级任务入口。当前结构将所有信息放在同一层级，使得导航层无法与用户心智对齐，也使后续模块的加入持续增加复杂度。

方案取舍

方向 1：不改变结构，仅进行视觉调整

方向 2（最终采用）：重构为“三段式导航结构”

选择方向 2 的原因

我们最初评估过一种较轻的方案——保持原结构不变，仅调整视觉表现。虽然成本最低，但这种方式无法改善导航含混的问题。最终我们采用了三段式头部结构的方案，将全局入口、模块级切换与页面级 Tabs 分层组织，使导航映射任务结构本身，同时通过调整侧边栏密度减少视觉干扰。这一方案使导航从“入口堆叠“转变为”层级结构”，在保持用户原有心智的同时提供更清晰的定位路径。

验证

上线后，用户在导航中的定位判断更加明确，跨模块切换的路径也更稳定。产品团队在后续模块扩展中能够直接复用这套结构，不再需要为每个模块重新设计导航体系，显著提升整体可扩展性。

反思

导航体系是专业系统的核心结构，尤其在多模块、多任务系统中更是如此。第二阶段的工作使整个系统在未来的迭代中具备了更高的结构稳定性，也提升了页面之间的逻辑一致性。

Phase 3: AI × Cloud Code：顶部空间优化（Designer → Design Engineer）

遇到的问题

在 13-inch 设备上，使用者普遍会被头部近 60% 的高度占用所影响。

这一问题来自多年叠加的布局层级与样式污染，传统人工方式难以在多文件、多层级结构中快速定位，成本高且不易彻底解决。

问题拆解

代码层级拆解后可见，头部的高度问题来自样式层级叠加、margin 与 padding 逻辑不一致，以及缺乏整体布局约束。这类问题属于典型的布局技术债，依靠浏览器工具逐行排查不仅效率低，更难以确保覆盖所有影响范围。

方案取舍（AI 驱动）

方向 1：人工定位并逐层调整样式

方向 2（最终采用）：AI-assisted 结构重构——使用 Claude Code

具体做法包括：

选择方向 2 的原因

在这一阶段，我采用了 AI-assisted 的方式处理问题，通过 Claude Code理解代码结构，再通过“先定位问题，再执行修改”的流程逐步识别布局污染来源，并在上下文中注入 DesignGuide 确保输出符合设计规范。相比传统的人工方式，这种方式可以更快定位结构性问题，并生成可维护的修改方案，同时通过 Git 完整记录变更过程，使迭代透明且可回溯。

这一方式能够一次性解决结构性高度膨胀的根源问题，比在现有结构上做局部修补更可靠。

核心价值点

成功让“设计 → 代码 → 设计”形成闭环，使自己从 UX 扩展为具备工程能力的 Designer-Engineer Hybrid。

验证

头部高度在本次迭代中显著降低，使内容展示区域在中小屏设备上得到明显改善，同时页面结构更加轻量，减少了后续维护负担。AI-assisted 的工作方式也使设计端能够更直接参与结构层优化，减少了跨角色沟通成本。

反思

这一阶段的实践让我意识到，交互设计在复杂系统中不仅是描述结构，也可以直接影响结构本身。AI-assisted 的流程使设计能够深入到实现层，建立起更完整的“设计—实现”闭环，这对未来的系统演进具有高价值。

总结

Ginkgo 的三个阶段分别从组件体系、导航结构、实现层三个维度解决了系统在快速扩展中逐渐积累的问题。组件体系化确保了跨模块一致性；导航层级重构提供了稳定的定位与跳转路径；AI-assisted 的结构优化让实现层也融入一致的结构逻辑。

设计过程中的决策依据主要有三种：

项目整体从“改界面“逐渐转向”治理系统结构”，也让我在复杂产品中建立了更成熟的方法论与跨层级的设计视角。