Budget is not just money.
预算不止是钱
It is a planning tool that defines boundaries, enables execution control, and supports later traceability.
它是一个计划工具，定义边界、支撑执行管控，并为后续追溯提供基础。
01 / Overview
Clarify budget definitions first
B端体验建立在业务语义上
Budget creation → approval → adjustment / split → usage follow-up预算创建 → 审批 → 调整 / 拆分 → 使用追踪
Model, formula, and terminology were not always clear enough模型、公式和业务口径没有被讲清楚
02 / Challenge
The hard part was not drawing screens
真正难的不是画页面
The hard part wasn't the screens — it was pulling planning, control and traceability back onto one shared budget model. The underlying structure and ownership had to align first; only then could the experience hold.
难的不是画页面，而是让规划、控制、追溯回到同一套预算模型上——底层结构和职责先对齐，体验才立得住。
The business target was always one closed loop
业务目标始终是一条完整闭环
Budget authoring had to start from the right fields and ownership.
预算编制必须从正确的字段和责任归属开始。
Separate which fields represent business objects from those that are only execution details, so a budget can actually be judged.
先分清哪些字段是业务对象、哪些只是执行信息，预算才有判断依据。
A budget line carries clear ownership from authoring, so approval and traceability have something to hold onto.
预算行从编制阶段就明确归属，后续审批与追溯才有抓手。
Budget control actions had to be clearly distinguished in semantics.
预算的管控动作必须在语义上真正区分开。
Used when the spending scenario becomes clearer gradually and the original coarse-grained budget needs to be broken into child budgets.
当业务场景逐步明确时，把原本粗颗粒度的预算继续拆细成多个子预算。
- One original budget can become multiple child budgets.
- 一个父预算可以一拆多。
- The goal is finer control at the child-budget level.
- 目标是把管控粒度下沉到子预算节点。
Used when the business changes and an existing budget line needs to be updated, such as changing amount or row information.
当业务事项本身发生变化时，修改已有预算行的信息，例如金额或字段更新。
- The row stays the same, but its information changes.
- 核心还是同一条预算行，只是信息发生变化。
- The goal is to reflect change, not create a new tree structure.
- 目标是体现变化，而不是生成新的树状结构。
Managers needed a top-down view of budget movement.
管理者需要一个自上而下看懂预算去向的视角。
The parent defines the structure and cap; child budgets carry execution. Because users still read how child budgets move under one parent, the system had to support parent-level aggregation and traceability.
父预算定义结构与额度边界，子预算承载执行。由于业务仍需要从父预算视角看懂子预算的去向，系统必须支持父级聚合与后续追踪。
- Supports top-down reading when reporting is still incomplete.
- 在报表体系还不完整时，支持自上而下查看动向。
- Prevents demand requests from becoming the place where budgets get “secretly refined”.
- 避免把预算细化的责任偷偷转移到需求单里。
03 / Design
Where I pushed the system forward
我把设计往前推进的几个关键点
Unify fields before talking about efficiency
先统一字段，再谈效率
miHoYo's spending controls include capabilities rarely seen in the industry, so the fields are costly to understand — and historical leftovers added fields with no business meaning. Whoever proposes, uses, or approves a budget struggled to read it.
米哈游对资金的管控有不少行业里没有的玩法，相关字段理解成本本就高，加上历史遗留的无业务含义字段——提预算、用预算、审批的人都不容易看懂。
- Aligned budget semantics between the authoring flow and the detail page.
- 统一创建流程与详情页之间的预算语义。
- Clarified which fields represent business objects versus execution details.
- 明确哪些字段是业务对象，哪些字段是执行信息。
- Anchored UX discussion in business terms instead of page layout.
- 把体验讨论从页面表现转向业务字段。
Align operation semantics and state machine
对齐操作语义与状态机
The same status words meant different things on different pages, and single-item vs batch actions were hard to distinguish. Users often could not tell what a budget could do, could not find the right action, or made mistakes because the operation model was unclear.
同一个状态词在不同页面里含义不一致，单条与批量操作也没有清楚区分。 用户经常看不懂一条预算当前能做什么，找不到操作按钮，或者因为用不明白而误操作。
- Unified cross-page status terms, so one label would not imply different business meanings.
- 统一跨页面状态词，避免同一个词指向不同业务含义。
- Rebuilt the state machine so each state matched a clear set of valid actions.
- 重梳状态机，让每个状态只对应明确的可执行操作。
- Separated single-item and batch actions, and made their entry points easier to find.
- 拆开单条与批量操作，并把入口做得更明确。
Business example
业务案例
父子预算结构
Parent-child structure
父预算定总额，子预算细分到 KOL / 搭建 / 物料执行级——把控颗粒度很细。
Parent sets the cap; children break it into execution lines — fine-grained control.
Parent budget
父预算
Gamescom brand campaign
科隆展品牌事项
Sets cap and traceability baseline.
定义总额边界与追溯基线。
200k
Total cap
总额上限
A
KOL
KOL
Creator cooperation
达人合作支出
B
Booth build
搭建
Build execution
现场搭建执行
C
Merchandise
物料 / 周边
Materials / merchandise
物料与周边支出
为什么"拆分"必须存在
Why "split" has to exist
同一笔 20W，有没有"拆分"，决定了钱是被分配还是被抢占。
For the same 20W, whether a "split" exists decides if money is allocated or grabbed.
有拆分 · 自上而下分配With split · top-down
20W
→
KOL 5W
搭建Booth 10W
物料Merch. 5W
额度先定、按需领取，加总不超总额，清晰可追溯。
Cap set first, drawn on demand; sum ≤ cap, clear and traceable.
没拆分 · 先到先得抢占No split · grabbing
20W
→
KOL 5W
搭建Booth 15W
物料Merch. 5W
谁先报谁先占——搭建抢走 15W、挤压其余，总额边界失效。
First-come wins — booth grabs 15W, squeezing the rest; the cap breaks.
结论：在这种细颗粒度的真实业务里，"拆分"是让预算自上而下分配、可追溯的前提，是现阶段必须存在的业务动作。
Takeaway: at this granularity, "split" is the precondition for top-down, traceable budgeting — a mandatory action at the current stage.
Where the old experience broke
旧体验具体卡在哪里
This was not a control issue; it was a budget semantics issue.
这不是操作问题，而是预算语义本身发生了混用。
Problem
现状问题
- Parent-child relations were unclear: summary and remaining rows shared similar IDs and visual treatment, so role and meaning blurred.
- 父子关系不清晰 汇总行与拆剩行编号与样式接近，角色与语义难以区分。
- Repeated fields had inconsistent meanings; some existed only because the interface displayed them, not because the business needed them.
- 重复字段语义不一致有些字段只是界面上存在，而非真正的业务口径。
Insight
关键洞察
- Parent budget must preserve cap and traceability.
- 父预算必须承担总额边界和追溯责任。
- Child budget must carry execution ownership and requestability.
- 子预算必须承担执行责任和可下单属性。
Mini project rollout in three steps
同一小项目的三步落地
Parent-child budget model optimization父子预算模型优化
Goal: make split logic visible, executable, and traceable.目标：让拆分逻辑可见、可执行、可追溯。
Semantic correction语义纠偏
Keep structure, clarify ownership, formulaize remaining amount.保留结构，明确责任，拆剩公式化。
Constraint solidification约束固化
Remaining row is display-only and non-requestable.拆剩行仅展示，不可直接下需求单。
Auto-generated clean structure自动生成干净结构
After approval, auto-generate executable child rows.审批后自动生成可执行子行，父行回归追溯。
Traceability only只做追溯
No execution; remaining shown by formula.不承载执行，拆剩按公式展示。
Auto-split on approval审批后自动拆出
Amount = parent; the starting point for further splits.金额 = 父行金额，作为继续拆分的起点。
Manual split from A从 A 手动拆出
Manual split from A从 A 手动拆出
Execution lives only in child rows while the parent falls back to pure traceability — budget reports stay clean and easy to reconcile.执行只发生在子行，父行回归纯追溯——预算报表天然干净，对账更省心。
Add summary and reporting views for follow-up
补上管理者视角下的汇总与追踪
A manager-facing summary table, better execution reports, and annual-budget version tracking with over-budget drill-down — so managers can read budget movement top-down.
面向管理者的汇总表、执行报表改进，以及年度预算版本与超包动态查看，让管理者自上而下看清预算流向。
- Made manager reporting useful both before and after annual budget rollout.
- 让管理者在年度预算生成前后都能更有效地看懂数据。
- Improved version awareness and follow-up visibility.
- 增强了版本意识和后续追踪可见性。
- Turned reporting from an afterthought into part of the product flow.
- 把报表从事后补充转为产品体验中的一部分。
工具 · 主动产出Tooling · self-initiated
财务报表生成器 · Figma 插件
Finance report generator · Figma plugin
为了让业务快速和 CFO 对齐报表里想看的内容，我做了一个 Figma 插件——业务自己配置数据结构与字段，一键生成符合线上设计规范的报表设计稿。
To help business teams align with the CFO fast, I built a Figma plugin: they configure the data structure and fields themselves, and it outputs an on-spec report design in one click.
- 业务自助产出，设计不再重复画一次性报表稿。
- Business self-serves; design stops redrawing one-off report mocks.
- 输出即符合线上设计规范，落地几乎零返工。
- Output already matches the live design spec — near-zero rework.
- 把和 CFO 的对齐从反复沟通，缩短为一次配置后的即时预览。
- Cuts CFO alignment from repeated back-and-forth into one setup with instant preview.
04 / Impact
What this work changed
这组优化带来的变化
Core semantics and the budget reading path are now aligned.
核心语义与预算阅读路径已完成对齐。
Fields match the detail page, so users author in the right business terms and approvers can read intent directly.字段与详情页统一，用户创建时就用对业务语义，审批人能直接看懂。
Data shows a clear drop in approval rejection rate.从数据上看审批驳回率明显降低。
Parent-child aggregation lets managers read where budget goes top-down.父子预算聚合，管理者自上而下看清预算流向。