Resume - 跨平台简历/CV 服务
这个项目要解决的是，如何把职业经历整理成既符合人的理解、也能被机器处理的数据。
Contribution
产品设计
Company
Recruit
Year
2022
项目概览
团队：产品负责人（Product owner）1 名、产品经理（PdM）2 名、产品设计师 2 名、工程师 10 名以上
为什么这个问题重要
Recruit Holdings 在日本运营着面向多元细分市场的多个求职服务：
• Rikunavi：新卒向求职网站
• Rikunavi Next：综合性求职网站
• Townwork：兼职与临时岗位求职网站
• Recruit Agent：人才中介/代理招聘服务
• Recruit Direct Scout：面向高端人才的 Scout 型跳槽网站
在这些差异很大的服务里，用户过去不得不重复填写同一份职业经历。
「One ID & One resume」不只是合并账号。更关键的是定义一层能够跨产品流动、也能支撑更好匹配的共享简历结构。
真正要改的是什么
在系统层面
• 做出一层能服务不同产品的共享简历能力
• 把职业经历组织成 AI 可以稳定理解的结构
• 同时提升求职者与招聘方两侧的检索与匹配效率
在交互层面
• 降低用户把职业经历翻译成“正式简历语言”的负担
Design Challenges
挑战 ❶：先把结构化输入的负担降下来
问题出在哪：
产品要求用户把复杂而具体的职业经历，转成覆盖 1,200 余种职种与 15,000+ 技能标签的 AI 可读结构。
系统是完整的，但认知负担太重。
我们改了什么：
原型 V1（线性问答）：
一屏一题让流程很规整，但也让填写变得漫长而单薄。用户能做完，却觉得这套方式装不下自己经验的层次。
最终版（分类标签 UI）：
我把交互从线性提问改成分类选择，让用户先“认出”自己的经验，再决定要不要进一步描述。
挑战 ❷：真正该改的是数据模型
问题出在哪：
测试显示，真正阻碍用户理解的是职种模型本身。用户根本无法在分类里找到自己。
我们改了什么：
我没有继续围着界面打磨，而是和产品经理一起，把职种结构本身重做了一遍。
IT > 工程师 > 后端 > 服务端 IT > 工程师 > 系统工程师 > Web/开放平台
IT > 服务端工程师 IT > 系统工程师 > Web/开放平台
先把层级变平：
我们把职种分类从四层调整成三层，让系统更接近用户对工作的真实理解方式。
再让搜索解释这套结构：
自动补全按更清楚的中层类别组织结果，让人更容易判断自己属于哪里。
验证：
SUS 从 73.8 提升到 83.0，其中“易懂性”达到 91.4。
挑战 ❸：让一层简历能力同时服务面向不同市场的产品
问题出在哪：
Direct Scout 需要更细的技能和经验标签，Townwork 只需要最基本的联系方式。固定的一套 onboarding 流程很难同时满足两边。
系统又不能因为产品差异而彻底拆开。
我们改了什么：
我把 onboarding 设计成一个可配置系统，而不是一条固定流程：
先模块化：
把收入、技能、学历等可能模块拆成一套可复用的输入能力。
/registration?option_items=previous_work_histories&career_summary
URL 参数定制：
不同宿主产品通过参数指定所需组合，但底层仍写回同一层简历结构。
最后改变了什么
这个项目同时改善了填写完成率，也改善了被写进去的数据质量：
- 效率：简历创建平均时间降幅超过 50%（957 秒 → 450 秒）。
- 数据丰富度：用户人均填入的技能标签数从 4 个增至 10 个。
- 匹配成效：候选人筛选通过率整体提升至 117%，在年轻群体与既往档案不完整用户中最高可达约 157%。
这页真正想说明的判断
- 简历填写能变轻，是因为它被重新定义成一层翻译结构。
- 最大的 UX 改善来自 taxonomy 的调整，不来自继续打磨一个建立在错误结构上的界面。
- 跨平台一致性成立，靠的是系统可配置，不是靠一条万能流程。
- 做平台型产品时，设计必须进入界面下面那一层。