100% uploaded didn’t mean ready to publish.
“上传 100%”并不等于可以发布。
VOD Publishing Console
From 100% uploaded to actually live.
从“上传 100%”到真正上线。
Redesigning how content partners upload, check and fix every episode before it reaches viewers.
重新设计内容方上传、检查和修复每一集的方式，让问题在观众看到之前就解决。
Lead Product Designer · June 2025
With Product, Engineering and Customer Support
Videomart is a pseudonym. Content and data shown are anonymised.
Context
From studio to 30 million viewers across South America.
从片方到南美洲 3000 万观众。
A back-office VOD platform. Every movie and episode goes live through it.
一个 VOD 后台平台，每一部电影、每一集剧都要经过它上线。
30M
viewers across South America, half of them every day.
南美洲共 3000 万观众，一半每天都在看。
CP · studios
Supply the content
提供内容
VNO · operators
Sell it under their own brands
用自己的品牌售卖
~5,000
back-office users. Operators in Brazil, Argentina, Colombia and more run on the same system.
约 5,000 名后台用户。巴西、阿根廷、哥伦比亚等地的运营商都在同一套系统上运行。
Main VNO markets
Brazil · Argentina · Colombia
巴西 · 阿根廷 · 哥伦比亚
Other markets
Served on the same system
在同一套系统上服务
Context
Before anyone presses play, it has to be published.观众按下播放之前，内容必须先上线。
A VOD back office for the South American market. Every title viewers watch on TV and mobile goes live here first — about 5,000 back-office users keep it running.面向南美市场的 VOD 后台。观众在电视和手机上看到的每一部内容，都要先在这里上线，约 5,000 名后台用户维持它的运转。
Where every title comes from
Every title passes through one pipeline.每部内容都要经过同一条发布管线。
If publishing fails, operators have nothing to sell and viewers have nothing to watch.发布一旦失败，运营商没有内容可卖，观众也没有内容可看。
Core metric
First-pass publishing successThe share of episodes that go live on first submission, with no rework.一次发布成功率：剧集首次提交即上线、无需返工的比例。
Next The challenge
The challenge
The platform grew. Publishing success kept falling.
平台在增长，发布成功率却一直在下降。
Customers grew 34% in three months. More of their uploads failed or came back as tickets.
三个月里客户增长了 34%，但他们的上传有更多失败了，或者变成了工单。
~14%
Month 3, down from ~22%.
第 3 个月，从约 22% 降下来。
205
Month 3, up 71% from 120.
第 3 个月，从 120 张涨了 71%。
The goal
The business set two goals.
业务定了两个目标。
Lift first-pass success well past where it stood three months earlier, and cut monthly rework tickets.
把首次发布成功率提升到明显超过三个月前的水平，同时减少每月的返工工单。
~30%
First-pass publishing success. Up from ~14%, and past the ~22% of Month 1.
首次发布成功率。从约 14% 提升上去，而且要超过第 1 个月的约 22%。
≤120
Rework tickets per month. Back to the Month 1 level.
每月返工工单。回到第 1 个月的水平。
Rework tickets and customer growth from platform data. First-pass success is estimated; goals were working targets.
返工工单和客户增长来自平台数据。一次成功率是估算值；目标是当时的工作目标。
The question
In three months, customers grew by 34%. The obvious answer: new users didn’t know the system yet, and more training would fix it.三个月内客户增长了 34%。最直接的解释是：新用户还不熟悉系统，多培训就能解决。
Was the problem the users, or the product?问题出在用户，还是产品？
If it was the users
They didn’t yet know
how to use the system.如果是用户：他们还不会用这个系统。
If it was the product
It never showed them what
happened after each action.如果是产品：它从来没告诉用户，每次操作之后发生了什么。
Cognitive walkthrough
Confusion grew with every stage.
每往后一个阶段，困惑就多一分。
I walked through one full publishing task as a studio operator, asking the same four questions at every stage.
我以片方操作员的身份走完一次完整的发布任务，在每个阶段都问同样的四个问题。
所有 5 个严重问题都出现在转码之后
By Publish, the system knows exactly what went wrong: a missing field, a failed transcode, a DRM setting. The user sees only “Cannot publish” and has to check each module one by one.
到发布这一步，系统清楚地知道哪里出了错：缺一个字段、转码失败、DRM 设置不对。用户却只看到"无法发布"，只能一个模块一个模块地查。
Task
1
Publishing, upload to live
一次发布任务，从上传到上线
Stages
6
Reviewed
逐一走查
Questions
4
Asked at every stage
每个阶段都问
Cognitive walkthrough · Information gap
The system knew more. The user understood less.
系统知道得越多，用户懂得越少。
Control shifts to the system at Hierarchy, where files are matched automatically. From there, the screen shows less than the pipeline knows.
控制权在"层级"这一步交给了系统，文件在这里被自动匹配。从这里开始，界面显示的比流程实际知道的少。
系统掌握的信息与用户的把握程度
Illustrative curve based on the cognitive walkthrough, not measured data.
示意曲线，根据认知走查绘制，不是实测数据。
A walkthrough shows where problems might be. To confirm them, we tested with 15 users.
走查只能看出问题可能在哪里。为了确认，我们找了 15 位用户做测试。
Usability study
The walkthrough held up with real users.
走查的结论，在真实用户身上得到了验证。
15 operators each published a full episode from upload to live, thinking aloud, with a short interview after every step.
15 位操作员各自完整发布一集，从上传到上线，边做边说出想法，每一步后做简短访谈。
用户遇到的问题
87%
hit a forced wait: 13 of 15.
87% 的人遇到过被迫等待：15 人中 13 人。
他们接下来怎么做
73%
resubmitted without changing anything.
73% 的人什么都没改就重新提交。
Participants
15, all CP
15 位，均为片方用户
Roles
11 frontline · 4 decision makers
11 位一线操作员 · 4 位决策者
Experience
5 novice · 6 intermediate · 4 expert
5 位新手 · 6 位中级 · 4 位熟手
“The progress bar hit 100%, but nothing showed up in the list. I thought I’d clicked something wrong.”
进度条到了 100%，列表里却什么都没有。我还以为是自己点错了。
“It just says ‘Failed’. Is it the file name? The transcode? I have no idea, so I upload it again.”
它只写着"失败"。是文件名的问题？还是转码？我完全不知道，只好再传一遍。
“A one-gigabyte file takes half an hour. I can’t edit the episode info until it’s done, so I just sit and wait.”
一个 1GB 的文件要传半小时。传完之前不能编辑剧集信息，我只能坐着等。
Percentages show the share of participants who hit each problem at least once during the test. Names changed.
百分比表示测试中至少遇到过一次该问题的参与者比例。姓名均为化名。
Key finding · N=15
It’s not a knowledge problem. It’s a product problem.
这不是用户懂不懂的问题，而是产品的问题。
Two behaviors observed in the test made this clear.
测试中观察到的两种行为，说明了这一点。
11/15
resubmitted without changing anything
什么都没改就重新提交
After a failure, 11 of 15 users resubmitted the same file with the same settings. They knew where to click, but not why it failed.
失败后，15 人中有 11 人用同样的设置重新提交同一个文件。他们知道该点哪里，却不知道为什么失败。
Can operate the system会操作系统Don’t know why it failed不知道为什么失败
9/15
double-checked outside the platform
到平台之外再次确认
9 of 15 users checked the result on a TV, an app or another system, even after the task showed as done.
即使任务已显示完成，15 人中仍有 9 人到电视、App 或其他系统上检查结果。
Completed the task完成了任务Don’t trust the status不相信状态显示
Each dot is one participant.
每个点代表一位参与者。
Key finding
Five user problems, three product root causes.
五个用户问题，三个产品根因。
I traced every failed case back to where it started.
我把每一个失败的案例都追溯到了它的起点。
从用户问题到产品根因
Solved in this order. Phase 1 shipped cause 1. Phase 2 shipped causes 2 and 3.
按这个顺序解决：第一阶段上线了根因 1，第二阶段上线了根因 2 和 3。
Overview · three problems
Three problems to solve, in this order. See errors first, catch them early, then remove the wait.
按这个顺序解决三个问题：先让错误被看见，再提前拦住，最后去掉等待。
Our core metric was first-time publish success. Waiting cost time but didn’t cause failures, so it came last.
我们的核心指标是首次发布成功率。等待浪费时间，但不会导致失败，所以放在最后。
Auto-matching failed silently.
自动匹配悄无声息地失败了。
Users had to wait for the system.
用户只能等系统。
Problem 1 · Before · V3.2
Everything shows 100%. Nothing says done.
每一行都显示 100%，却没有一行告诉你"完成了"。
Every row showed the same green 100%, whether the title was live, still transcoding, or had already failed. To the system, 100% meant the file had transferred. To users, it meant the job was done.
无论这部片已经上线、还在转码，还是已经失败，每一行都显示同样的绿色 100%。对系统来说，100% 表示文件传完了；对用户来说，它意味着任务完成了。
First-time publish success
首次发布成功率
~14%
Est. · Before the redesign
估算 · 改版前
Transfer progress, not task result
What was actually happening
Same 100% on every row. Only 1 of 5 was live.
每一行都是 100%，5 部里只有 1 部真正上线。
Five titles from one batch, all showing the same green 100% in the list.
同一批里的五部片，在列表里都显示同样的绿色 100%。
Illustrative states.
示意状态。
TitleShownActual
Detective Chinatown 2E01100%Live
Operation Red SeaE04100%Transcoding42%
Detective Chinatown 2E07100%FailedDRM key missing
Operation Red SeaE02100%Matching to season15%
Detective Chinatown 2E09100%FailedWrong season
Problem 1 · Before · V3.3
Labels added. Success rate didn’t move.
加了状态标签，成功率却没有变化。
Users could now see that something went wrong, but not why. Every row that wasn’t a success had the same single action: delete it and upload again.
用户现在能看到出了问题，但不知道为什么。所有不是"成功"的行都只有同一个操作：删掉，重新上传。
First-pass publishing success
首次发布成功率
~14%
Est. · V3.2 → V3.3, barely moved
估算 · 从 V3.2 到 V3.3 几乎没变
New status labels
What each label let you do
A label, but no reason. Delete was the only way out.
有标签，没有原因。删除是唯一的出路。
11 of 15 users deleted and re-uploaded, then hit the same error again.
15 位用户里有 11 位删掉重传，结果又遇到同样的错误。
StatusActionsWhat the user could do
SuccessEdit, preview, delete
InoperableDelete only. No reason shown.
UploadingDelete only, until the upload ends.
Problem 1 · Benchmark
Three benchmarks, three scales.三个竞品，三种规模。
How do mature platforms tell users whether a publishing task is truly done, and help them recover when it fails?成熟的平台如何告诉用户发布任务是否真正完成，失败时又如何帮用户恢复？
Enterprise & telecom
~850
enterprise customers
Including Vodafone. Offers a dedicated TV content management system for telecom operators.约 850 家企业客户，包括 Vodafone，为电信运营商提供专门的电视内容管理系统。
Closest to our business
Mid-market OTT providers
500+
clients across 70+ countries
A no-code platform to launch and manage streaming services.70 多个国家的 500 多家客户，用无代码平台上线和管理流媒体服务。
Batch publishing, no engineers
Independent creators
4,000+
creators
An all-in-one video membership platform.4,000 多名创作者使用的一站式视频会员平台。
Automation-first
Problem 1 · Benchmark
Every platform shows status. None turns it into a task.
每个平台都显示状态，却没有一个把它变成"任务"。
All three show upload and processing status. None sums it up into one view of where the whole task stands and what’s still missing.
三家都会显示上传和处理状态，但没有一家把它汇总成一个视图，告诉用户整个任务进行到哪、还缺什么。
三个竞品的能力对照
5
of 8 capabilities are open opportunities. Most sit in recovery.
8 项能力中有 5 项是机会点，大多集中在"恢复"环节。
CapabilityKalturaMuviUscreenOpportunity
01Status
Upload & processing statusBaseline
Failed item / task visibilityBaseline
02Diagnosis
Error details & troubleshootingOpportunity
Failed item / task visibilityBaseline
03Recovery
Retry & recoveryOpportunity
Unified cross-stage issue viewOpportunity
Action-based issue groupingOpportunity
In-place resolutionOpportunity
ConfirmedPartialNot observed
Completing the progress bar would only match them. Users would still have to piece together whether a title can go live.
把进度条做完整，也只是和它们持平。用户仍要自己拼凑信息，判断一部片能不能上线。
Problem 1 · Benchmark
Recovery exists everywhere. Each one breaks the flow differently.
每家都有恢复机制，但每家都在不同的地方打断了流程。
Each platform solves one part of recovery. We kept what works from each.
每个平台都解决了恢复的一部分，我们从每家各借鉴了一点。
Kaltura · Module-based
3 module jumps
3 次模块跳转
We kept
Errors tracked in one place.
错误集中在一处查看。
Muvi · Report-based
Leaves the platform
离开平台
We kept
One report for every failure.
一份报告列出所有失败。
Uscreen · Automated retry
No user path
用户无路可走
We kept
Don’t bother users with what the system can fix.
系统能修的，不打扰用户。
Based on public help center docs and free trials.
基于公开帮助文档和免费试用整理。
Problem 1 · Directions
From “better status” to three design directions.
从"更好的状态显示"，到三个设计方向。
Each direction comes from a research finding and a gap no benchmark had filled.
每个方向都来自一条研究发现，以及一个竞品都没有填上的空白。
60% double-checked · Benchmark gap
60% 的人会二次确认 · 竞品空白
Users see each stage, but not the whole task
用户看得到每个阶段，看不到整个任务
None of the benchmarks sums up stage statuses into one task.
没有一个竞品把各阶段状态汇总成一个任务状态。
Kaltura + Uscreen
Kaltura + Uscreen
Errors are scattered across stages and pages
错误分散在不同阶段和页面里
Kaltura tracks them in one place, Muvi in one report. Neither groups them by what to do next.
Kaltura 集中在一处，Muvi 汇总成一份报告，但都没有按"下一步要做什么"来分组。
73% resubmitted · Uscreen
73% 原样重提 · Uscreen
Users know something failed, not what to do next
用户知道失败了，不知道下一步怎么办
With delete as the only option, users resubmitted blindly. Muvi sends fixes out of the platform.
删除是唯一的选项，用户只能盲目重提。Muvi 则要离开平台去修。
Task status, not stage status.
任务状态，而不是阶段状态。
Roll all stage statuses into one task status, so users see at a glance whether a title can go live and what’s still missing.
把所有阶段状态汇总成一个任务状态，让用户一眼看出片子能不能上线、还缺什么。
One entry for every issue, grouped by action.
所有问题一个入口，按操作分组。
Collect every issue in one place, grouped by what the user needs to do: decide, retry, or add info.
把所有问题集中到一处，按用户要做的事分组：做决定、重试、补信息。
Every issue links to its fix.
每个问题都直连修复操作。
Each issue opens the action that resolves it, right where the user is. What the system can fix, it fixes on its own.
每个问题都能直接打开对应的修复操作，就在用户当前的位置。系统能修的，自己修掉。
Problem 1 · Directions
Three concepts, each covering more.三个方案，覆盖范围逐个扩大。
A follows how most platforms work today and serves as the control. B covers two of the three directions. C covers all three.方案 A 沿用多数平台现在的做法，作为对照组；方案 B 覆盖三个方向中的两个；方案 C 覆盖全部三个。
Concept A
ControlGuide with fixed steps
Covers010203
Move users through publishing stage by
stage. Clear to follow, but keeps the
workflow linear and rigid.一步步带用户完成发布。容易跟随，但流程线性、僵硬。
Concept B
Monitor with a status dashboard
Covers010203
Sum up progress and issues across modules
in one view. Easier to monitor, but users
still jump elsewhere to fix problems.在一个视图里汇总各模块的进度和问题。便于监控，但修问题仍要跳到别处。
Concept C
Work in one batch workspace
Covers010203
Group issues by what users need to do, and
fix each one in a side panel without
leaving the page.按用户要做的事归类问题，在侧边面板里逐个修复，不用离开当前页面。
Problem 1 · Testing · N=8
The more directions covered, the better users did.
覆盖的方向越多，用户完成得越好。
With A, none of the 8 users finished the multi-issue task. With C, 7 did.
用方案 A，8 位用户都没能完成多问题任务；用方案 C，有 7 位完成了。
96%
Concept C: 23 of 24 attempts done unaided and correct.
方案 C：24 次尝试中有 23 次独立且正确完成。
−50%
time to resolve from A to C. Page jumps fell 78%.
从 A 到 C，解决时间减少一半，页面跳转减少 78%。
Participants
8 · rotated order
8 位 · 轮换顺序
Concepts
A, B, C
Covering 1, 2 and 3 directions
分别覆盖 1、2、3 个方向
Test set
30 videos, 8 issues
Missing info 3 · Upload fail 2 · Transcode fail 2 · Match fail 1
缺信息 3 · 上传失败 2 · 转码失败 2 · 匹配失败 1
Tasks
3 tasks
Find an issue · Fix a given issue · Handle a video with several issues
找到问题 · 修复指定问题 · 处理有多个问题的视频
Success = done without help, with the right result. Page jumps = cross-module navigations per user, median. Small sample: read as directional.
成功 = 无人协助且结果正确。页面跳转 = 每位用户跨模块跳转次数的中位数。样本较小，结果仅供参考方向。
Problem 1 · Final design · Direction C
Status, issues and fixes in one place.
状态、问题和修复，都在同一个地方。
One list for every title in the batch: where it is, what blocked it, and what to do next.
一张列表涵盖这一批里的每一部片：进行到哪、被什么卡住、下一步该做什么。
01
See the whole task, not just a stage.
看到整个任务，而不只是某一个阶段。
Each row shows where it’s stuck, why, and for how long. Silent failures rise to the top.
每一行都写清卡在哪、为什么、卡了多久。静默失败会排到最上面。
02
Grouped by what to do next.
按"下一步要做什么"分组。
Needs a decision, ready to retry, needs your input. The system flags which retries its rules will fix, then retries the rest in one click.
需要决定、可以重试、需要补充信息。系统会标出哪些重试能被规则修复，其余的一键重试。
03
Fix it where you find it.
在哪里发现，就在哪里修。
Open any issue and edit it in the side panel, without leaving the list.
打开任何一个问题，在侧边栏直接编辑，不用离开列表。
Problem 2 · What the data showed
Matching issues aren’t the most common. They’re the hardest to clear.
匹配问题不是最常见的，却是最难解决的。
We analyzed three months of rework tickets and error logs, split by issue type and time to resolve.
我们分析了三个月的返工工单和错误日志，按问题类型和解决耗时拆分。
46%
of issues stuck over 24 hours are matching, vs 28% of all issues.
卡住超过 24 小时的问题里，46% 是匹配问题；在全部问题里只占 28%。
2.6 days
for matching issues. Every other type is touched within a day.
匹配问题要等 2.6 天才有人处理，其他类型都在一天之内。
Long-stuck = unresolved for more than 24 hours. Time measured from the moment an issue appears to the first fix attempt. Bars drawn to scale in hours.
长期卡住 = 超过 24 小时未解决。时长从问题出现算到第一次尝试修复。横条按小时等比绘制。
So we traced them back to where they start.
所以，我们追溯到了它们的源头。
Problem 2 · Before
10 files imported. Only 6 showed up.
导入了 10 个文件，只显示出 6 个。
Four file names didn’t fit the format the system expected. No error, no alert. The files simply disappeared.
有四个文件名不符合系统要求的格式。没有报错，也没有提醒，这些文件就这样消失了。
Users in the study hit this
研究中遇到这个问题的用户
4/15
Names that break the format
Gone from the list
Why they vanished
Every missing file broke the naming format. None of them said so.
每个消失的文件都不符合命名格式，却没有任何提示。
The import counted them as complete, then left them out of the list.
导入把它们算作已完成，然后又把它们从列表里漏掉了。
File nameWhat broke the formatShown as
Silent Horizon*1Illegal character in the titleCompleted
( ? #City of ShadowsSymbols before the titleCompleted
1123Chasing TomorrowDigits run into the titleCompleted
11A Summer PromiseA code in front of the titleCompleted
Problem 2 · Root cause
Caused at upload. Discovered at publish.
错误在上传时产生，却在发布时才被发现。
The system matches each file to a series, season and episode by its name. When the name is wrong, nothing flags it.
系统按文件名把每个文件匹配到剧、季和集。名字一旦写错，没有任何提示。
One wrong file name
CityLights_2024_E01.movWhat it costs, per file
If flagged at upload~20 sec
Found at publish~65 min
Repeats for
Every episode in the batch
批量上传里的每一集
Before anyone acts
2.6 days, median
中位数 2.6 天
Errors shown to users
0
向用户显示的错误：0
A wrong file name can also land an episode in the wrong place, with no error either. Bars drawn to scale, estimated from a ~1.2 GB upload (~30 min each way).
写错的文件名还可能把一集放到错误的位置，同样没有任何报错。横条按比例绘制，按约 1.2 GB 的上传（单程约 30 分钟）估算。
Problem 2 · The principle
Catch it where it’s cheapest to fix.
在修复成本最低的地方拦住它。
The problem wasn’t automation. It was that the system decided for users without showing them.
问题不在于自动化，而在于系统替用户做了决定，却没有让他们看到。
修复一个错误文件名的成本
~20 sec
if it’s caught before upload, vs ~65 min if it’s found at publish.
在上传前发现只要约 20 秒；到发布时才发现要约 65 分钟。
Principle 1
Detect before upload
Check file names before anything is transferred or processed.
上传前就检查：在任何传输或处理之前先检查文件名。
Principle 2
Make automation inspectable
Show users what the system decided, and let them correct it.
让自动化可检查：把系统的决定展示给用户，并允许他们修改。
Estimated for a 1.2 GB file with a ~30 min upload. Curve between the two ends is illustrative.
按 1.2 GB 文件、约 30 分钟上传估算。两端之间的曲线为示意。
Problem 2 · First design
A full check before anything uploads.
上传之前，先全部检查一遍。
Every file is checked against the naming rule and the library first. Nothing disappears, and nothing changes until the user confirms.
每个文件都先对照命名规则和片库检查。没有文件会消失，用户确认之前也不会改动任何东西。
Three outcomes
48 files in, 48 accounted for. Sorted by how sure the system is.
48 个文件进来，48 个都有着落，按系统有多确定来分组。
36 ready · nothing to do12 need attention
6
Auto-fixed
自动修复
Sure fixes, like dots to underscores. Undo anytime.
有把握的修复，比如把点改成下划线，随时可以撤销。
4
Needs review
待确认
Unsure or risky, like “2024” in the season slot. Confirm just that part.
不确定或有风险的，比如季数位置写成了“2024”。只需确认这一处。
2
Unmatched
无法匹配
Can’t be placed yet. Held aside instead of vanishing.
暂时无法归位，先放在一边，而不会直接消失。
One sample batch of 48 files.
Upload assistant
Describe the fix once. It applies to every match, after you confirm.
描述一次修改，确认后应用到所有匹配项。
Sums up the batch and applies bulk renames from plain language, only after the user confirms.
汇总整批文件，用一句话描述就能批量重命名，且只在用户确认后执行。
48 checked2 renamed on confirm0 uploaded until then
Upload assistant
TheMakers files are all The Makers (US).
Assistant
This will rename 2 files. Nothing uploads until you confirm.
TheMakers_S01_E01.mov→The Makers (US)_S01_E01.mov+1
Apply 2 changesNot now
Ask a question…
Problem 2 · Trade-offs
Engineering raised three fair concerns. Each one changed the design.
工程团队提出了三个合理的顾虑，每一个都改变了设计。
01Cost
Is it worth the build?
值得做吗？
Library lookups and duplicate detection were new capabilities, and the platform team had no capacity that quarter. How many errors would all that effort actually stop?
片库查询和重复检测都是新能力，平台团队那个季度也没有排期。投入这么多，到底能拦住多少错误？
02AI accuracy
What if the guess is wrong?
猜错了怎么办？
On real Spanish and Portuguese file names, accuracy dropped sharply. One wrong guess would silently file an episode in the wrong place, the very problem we set out to fix.
在真实的西班牙语和葡萄牙语文件名上，准确率明显下降。猜错一次，就会悄无声息地把一集放错位置，而这正是我们要解决的问题。
03Friction
Why slow down clean files?
为什么要拖慢没问题的文件？
A check before upload adds a step for every user, even those whose files are fine.
上传前加一道检查，所有用户都多了一步，包括文件本来就没问题的人。
The real question
How should the check prevent the most errors, without slowing down users whose files are fine?
检查要怎样拦住最多的错误，又不拖慢文件没问题的用户？
Prevent the most errors ← 01 Cost · 02 AI accuracyWithout slowing clean files ← 03 Friction
Problem 2 · The trade-off
The smallest build catches the costliest errors.
投入最小的检查，拦住代价最高的错误。
We split 164 matching cases by type and compared how often each happens, how long it takes to resolve if missed, and how long it takes to build a check.
我们把 164 个匹配问题按类型拆开，比较每类出现的频率、漏掉后解决要多久，以及做一个检查要花多少开发时间。
每类检查的开发投入
3 days
to build the naming format check, the smallest of the four.
命名格式检查只需 3 人天，是四类里最小的。
命名格式
37%
of matching cases come from naming format.
37% 的匹配问题来自命名格式。
To resolve if missed
31 h
漏掉后要 31 小时才能解决
Ever found later
Only 38%
事后只有 38% 被发现
Catchable before upload
85%
85% 可以在上传前拦住
Person-days to build
3
开发只需 3 人天
Based on 164 matching-related cases. Episode errors and live-content conflicts already surface in the Phase 1 workspace.
基于 164 个匹配相关案例。剧集信息错误和线上内容冲突已经能在第一阶段的工作台里看到。
Problem 2 · The response
Three concerns. One narrow scope. Not a smaller solution, a sharper one.
三个顾虑，一个收窄的范围。不是更小的方案，而是更准的方案。
01Cost
Is it worth the build?
Check what’s common, not everything.
只查常见的，不查全部。
Format errors only. Naming rules, no library lookup, no new platform work.
只查格式错误：只看命名规则，不查片库，不需平台开发。
02AI accuracy
What if the guess is wrong?
Point it out. Don’t guess.
指出来，不去猜。
No AI, no auto-fix. The check marks the wrong part; the user fixes it.
不用 AI，不自动修复。检查只标出错的部分，由用户来改。
03Friction
Why slow down clean files?
Only flagged files wait.
只有被标记的文件需要等。
Valid files upload right away. The batch is never held up.
没问题的文件立即上传，整批不会被卡住。
The answer
Check names before upload. Flag only what’s wrong, and let every clean file go.
上传前先查文件名：只标出有问题的，没问题的文件全部放行。
Prevents the most errors → 01 Cost · 02 AI accuracyNever slows clean files → 03 Friction
Problem 2 · Shipped
Flag the name. Let the user fix it.
标出错的名字，让用户自己改。
No guessing, no auto-fix. The check highlights the part of each name that breaks the rule, and the user renames it inline before anything uploads.
不猜测，也不自动修复。检查会标出每个文件名里违反规则的部分，用户在上传前直接在行内改名。
01
The wrong part, highlighted.
只标出错的部分。
Only the characters that break the rule turn red, so the fix is obvious at a glance.
只有违反规则的字符会变红，一眼就知道该改哪里。
02
Rename inline, then confirm.
行内改名，再确认。
Edit the name right in the row. Nothing changes until the user confirms.
直接在行里修改文件名，用户确认之前不会改动任何东西。
03
Three issues, plainly named.
三类问题，直白命名。
Invalid name, unsupported format, empty file. Each says what to do.
文件名不合规、格式不支持、空文件，每一类都写明该怎么处理。
04
Valid files go right away.
合规的文件马上上传。
36 of 48 upload now. Only flagged files wait.
48 个里有 36 个立即上传，只有被标出的文件需要等待。
Problem 2 · One month after launch
Three days of work. 42% fewer matching tickets.
3 天的开发，匹配类工单减少 42%。
Most flagged files were fixed in seconds, before upload, so far fewer turned into rework later. Figures compare the first month after launch with the three months before.
大多数被标出的文件在上传前几秒内就改好了，后来变成返工的少了很多。数据对比的是上线后第一个月与之前三个月。
上线前后
−42%
matching-related rework tickets, 74 → 43 a month.
匹配相关的返工工单，从每月 74 张降到 43 张。
本次新增
84%
of flagged files were fixed before upload.
被标出的文件里，84% 在上传前就改好了。
Shipped
File name and format check
Inline fix before upload
文件名和格式检查 · 上传前行内修复
Next
Auto-fix · Library matching
Duplicate detection · AI assistant
自动修复 · 片库匹配 · 重复检测 · AI 助手
Errors no longer fail silently downstream. Users see them before upload, and fix them on the spot.
错误不再在下游悄悄失败。用户在上传前就能看到，当场改好。
Problem 3 · Before
The system’s processing time became the user’s waiting time.
系统的处理时间，变成了用户的等待时间。
Episode info stayed locked until upload and transcoding finished.
在上传和转码完成之前，剧集信息一直被锁定。
Users in the study were stuck here
研究中被卡在这里的用户
13/15
Locked while uploading or transcoding
What was locked, and why
Only encryption had to wait. Editing never needed the file at all.
只有加密需要等待，编辑根本不需要文件。
3 of every 4 minutes went to waiting, and a failed upload threw all of it away.
每 4 分钟里有 3 分钟在等待，而一次上传失败会让这些时间全部白费。
StatusActionsLocked for
Success—
Uploading~30 min
TranscodingUntil transcoding ends
One upload · ~40 min
Waiting for upload · ~30 minEditing · ~10 min
If the upload fails here, those 30 minutes are lost.
TaskNeeds the file?
Edit episode infoNo
Add poster & metadataNo
EncryptionYes, after transcoding
Times estimated from a ~1.2 GB upload (~30 min) and typical editing (~10 min). Transcoding not included, so real waiting may be longer.
时间按约 1.2 GB 的上传（约 30 分钟）和常规编辑（约 10 分钟）估算。未计入转码，实际等待可能更长。
Problem 3 · Shipped
Edit while it uploads. Only file-based fields wait.
上传的同时就能编辑，只有依赖文件的字段需要等待。
Title, synopsis and cast don’t depend on the file, so they unlock the moment upload starts. Only fields like runtime wait, and fill in after transcoding.
片名、简介和演员表都不依赖文件，所以上传一开始就可以编辑。只有时长这类字段需要等待，转码完成后自动补上。
01
Edit while it uploads.
边上传边编辑。
Info fields stay open during upload. Runtime and resolution show they’re waiting, then fill in.
上传过程中信息字段保持可编辑。时长和分辨率会显示"等待中"，之后自动填入。
02
Same actions in every status.
每种状态下操作都一样。
Upload and transcoding no longer lock the row. The only thing that waits is what truly needs the file.
上传和转码不再锁住整行，只有真正需要文件的部分才需要等待。
After launch
Users blocked by upload
被上传卡住的用户
13/15→0
Round 2 usability test · N=15
第二轮可用性测试 · 15 位用户
Passive waiting per upload
每次上传的被动等待时间
~30 min→0
Estimated · ~1.2 GB upload
估算 · 按约 1.2 GB 的上传
Problem 3 · Fix 2 & 3
No re-upload loop. No five-page dig.
不用再重新上传，也不用再翻五层页面。
Two more places where users lost time to the system: failed uploads that had to start over, and a navigation that buried every episode five pages deep.
用户还在两个地方把时间耗在系统上：上传失败要从头再来，每一集都藏在五层页面之下。
Fix 2 · Failed uploads
一批文件上线所需时间（含一个命名错误）
−35–40 min
The pre-check from Problem 2 flags bad names before upload, so one failure no longer means a second upload.
问题 2 的预检查在上传前就标出错误的文件名，一次失败不再意味着重新上传。
12 flagged files fixed on the spot
12 个被标记的文件当场修好
Fix 3 · Navigation
打开某一集所需时间
−30 s
Series list, details, season, episode list, then the episode. Now it’s one tree: click an episode and its details open beside it.
原来要依次经过剧集列表、详情、季、集列表才到某一集。现在是一棵树，点一下，详情就在旁边打开。
Find one in 300 episodes ~47 s → ≤5 s
在 300 集里找到某一集：约 47 秒 → 5 秒以内
Times estimated from measured page-jump time (~6.7 s per page) and a ~1.2 GB upload (~30 min).
时间根据实测的翻页耗时（每页约 6.7 秒）和约 1.2 GB 文件的上传时间（约 30 分钟）估算。
Validation · Round 2
Users stopped working around the product.
用户不再需要绕开产品做事。
Same 15 participants and the same success criteria as round 1, now on the release build. The workarounds from round 1 almost vanished.
同样的 15 位参与者、同样的成功标准，这次用的是正式版本。第一轮里的各种绕路行为几乎消失了。
绕路行为：第一轮 → 第二轮
0/15
blocked by upload, down from 13.
被上传卡住的人从 13 位降到 0。
Independent completion
13/15
Completed the full task independently.
13 位独立完成了全部任务。
Still open
3/15
Read “Upload ready files” as acting on the current series only, not the whole batch. Next: make the button’s scope explicit.
3 位把"上传已就绪文件"理解为只作用于当前剧集，而不是整批。下一步：把按钮的作用范围写清楚。
Same participants as round 1, so some learning effect is expected. We read behavior change, not completion rate alone. Each dot is one participant.
参与者和第一轮相同，可能有一定的学习效应。所以我们看的是行为变化，而不只是完成率。每个点代表一位参与者。
Retrospective
Most of the gains came from questioning the first answer.大部分收获，来自质疑最初的答案。
Three obvious fixes that were wrong
Three times, the obvious fix was wrong.三次，看似显然的修复都错了。
The obvious fixWhat the data saidSource
P1“Users need training.”
11 of 15 resubmitted the same file. They could operate; they couldn’t see why it failed.15 人里有 11 人重复提交同一个文件。他们会操作，只是看不到失败的原因。
Usability test · R1 · N=15 P1“Add status labels.”Shipped in V3.3. Success rate barely moved, staying around 14%.在 V3.3 上线后，成功率几乎没变，仍在 14% 左右。
Release data · V3.3 P2“Check everything before upload.”A 3-day file-name check cut matching tickets by 42%.一个只花 3 天开发的文件名检查，让匹配类工单减少了 42%。
Support tickets · Post-launchWhat I’d do differently
Three things I’d change next time.下次我会改变的三件事。
01
Validate key assumptions with real data, early.
AI renaming looked accurate on curated samples,
and only fell short on real files at sprint planning. A
small real-file trial at concept stage would have set
the scope sooner.AI 重命名在精选样本上看起来很准，直到迭代规划时才发现在真实文件上不够好。如果在方案阶段就用少量真实文件试一下，范围会更早确定。
Seen in · Problem 2 trade-offs
02
Measure, don’t estimate.
Navigation gains were estimated from measured
page-jump time, not timed end to end. Next time, I’d
track real task time from day one.导航上的收益是根据实测的页面跳转时间估算的，并不是端到端计时。下次我会从第一天起就记录真实的任务时间。
Seen in · Problem 3 fix 3
03
Widen test coverage.
Round 2 reused the same 15 participants, and 3
misread “Upload ready files” only in the final round.
Next time: fresh users, and risky batch actions
tested first.第二轮沿用了同样的 15 名参与者，直到最后一轮才发现有 3 人误解了「Upload ready files」。下次会换新用户，并优先测试有风险的批量操作。
Seen in · Validation round 2
What I took away
When users struggle, I now ask a different first question: what has the product left to them?现在，当用户遇到困难时，我先问的问题变了：产品把什么留给了用户自己去处理？