政府业务 APP
政府各部门业务用户进入业务、接收任务、了解企业并开展现场工作。
看企业走访任务 ↓PRODUCT DESIGN CASE STUDY 2026
智慧经开 / 政府业务 APP · 人才专区
把复杂业务，
变成能理解、
能行动的产品。
我负责政府业务 APP 与人才专区前后台。
理清角色、任务和规则，借助 AI 推进方案与原型。
IDEA → INTERACTION
真实页面 · 可运行原型
同一套业务思考
移动办公 × 前后台服务
01 / SCOPE & PEOPLE
一个大项目，
我负责其中两条业务线。
智慧经开覆盖园区多项政务与企业服务。我负责政府业务 APP，以及人才专区的前台与后台。先分清谁在使用，才能定义产品要帮助谁完成什么。
人才专区前台
企业及其下属高端人才理解人才条件、准备材料；以 E 类申报为例，由企业发起办理。
看条件如何转成选择 ↓人才专区后台
政府人才业务部门核对信息与材料，给出审核意见，将申请转交下一环节。
看申报与审核如何衔接 ↓共同的设计任务：让当前角色知道要做什么、依据是什么、下一步交给谁。
02 / 政府业务 APP
从找到功能，
到开展一次企业走访。
APP 面向政府各部门业务用户。以企业走访为例：优先任务交代当前工作，企业清单呈现期限与进度，详情承接企业信息和现场记录。
从当前待办开始，而不是在应用里找任务。
点击放大 · 原型演示数据
期限、进度与待走访企业放在同一处。
点击放大 · 原型演示数据
企业信息连接位置、现场记录与提交动作。
点击放大 · 原型演示数据观看重点
从首页优先任务进入企业走访清单，打开单企业详情，再返回清单。观察任务如何连接现场执行信息。
录屏展示原型交互；AI 回答与业务数据为演示内容。
APP PROTOTYPE / 01单独打开录屏 ↗
03 / 人才专区前台
先理解自己符合什么，
再准备办理所需的材料。
面向企业及其下属高端人才。人才预判从一份业务文件开始：借助 AI 整理条件与类别的对应关系，再通过原型检查这些规则能否被用户理解和使用。
- 业务输入
人才条件文件
类别、条款与适用条件。
- AI 协助整理
结构化规则
拆解条件，建立类别对应。
- 我的设计判断
选择与说明
检查完整性、歧义与多条件关系。
- 原型表达
结果与依据
展示命中条件及后续入口。
设计选择 / 先帮助理解，再引导办理
用户需要的，不只是一个类别。
原型按职务、人才计划、项目、收入、专利、任职、技能、学历和奖项组织条件。部分选项提供解释，结果同时保留命中条件，让用户理解“为什么”。
不同类别的后续办理入口不一定相同。预判和正式申报分别承担判断与办理任务，不强行合并。
放大真实页面 ↗先说明匹配规则，再选择符合的条件。
放大真实页面 ↗实际勾选“高级技师”后生成：类别、命中条件与办理入口同时展示。
人才预判如何计算？
01 / 至少选择一项
未勾选条件时不生成结果，提示“请至少勾选一项符合条件”。
02 / 多项命中，取最高类别
按 A → B → C → D → E 的优先级判断，不累计积分，也不因多选而升级。例如同时选择“国家级技能大师”（C）与“高级技师”（D），预判结果为 C 类。
03 / 同级条件满足任意一项即可命中
例如“高级技师”或“省市级技能大师”均对应 D 类。单条条件内的限定则要一起满足：如“具有博士学位且符合长沙重点产业岗位条件”，不能只凭博士学位勾选。
04 / 只展示最终类别的命中依据
若同时命中 C、D 两类，结果展示 C 类及本次选中的 C 类条件；同级命中多项时一并列出，不将低等级条件作为高等级依据。
05 / 按类别引导后续办理
A—D 类引导至长沙市人才申报入口；E 类进入本专区 E 类申报。预判不替代正式审核。
以上为当前原型的判定与展示规则，用于说明产品设计，不作为现行政策认定依据。
人才前台 / 从理解条件到准备申报
企业需要知道，
交什么，以及如何继续办理。
预判帮助理解条件；正式申报由企业填写信息、上传材料。被退回时，在原申请中查看原因并修改。
04 / 人才专区后台
让审核人员有据可审，
让每个结论有明确去向。
面向政府人才业务部门。以 E 类人才初审为例，工作人员核对申请信息和证明材料，填写意见，再决定提交复审、退回企业修改或不予通过。
- 企业 · 前台填写与备齐材料人才信息 / 证明材料
- 企业 · 前台提交申请签字盖章材料
- 政府 · 后台初审信息 / 附件 / 意见
- 政府 · 后台复审接续核查与处理
- 结果反馈明确处理结果结论 / 流程记录
放大界面 ↗申请信息与审核意见并列，当前节点和处理结论共同说明下一步。
真实原型页面 · 演示数据初审之后，不只有“通过”。
展开不同结论，查看下一责任环节和设计要点。
通过 → 提交复审
转交下一审核环节，不把“初审通过”呈现为整份申请已经完成。流程记录说明当前走到哪里。
退回修改 → 企业补充
明确要补什么、为什么补，保留申请上下文；不能只给一个“退回”状态，让企业重新猜测。
不予通过 → 给出结论
与可补正的材料问题区分。处理意见应解释结论，而不只是一个按钮结果。
后台判断
材料与审核，放在同一个上下文。
已查看的初审详情同时呈现人才信息、证明附件、材料处理、审核意见和流程记录。审核人员不需要脱离这份申请理解当前任务。
风险控制思路
把容易误解的节点说清楚。
提交前明确材料要求；处理中区分退回与不予通过；流转后明确下一责任人。这些是减少遗漏和误解的设计手段，不等于已经测得错误率下降。
05 / REVIEW THE DECISIONS
看见页面之后，
还要回到最初的业务问题。
用原型检查设计判断：任务能否找到、规则能否理解、责任能否交接。后续迭代以具体反馈和版本材料为依据，不用未经验证的效果数字代替说明。
能否开始工作？
从优先任务进入企业清单，再查看单家企业和现场记录操作。检查信息是否随任务逐步展开。
能否解释结果？
结果是否保留命中条件？用户是否理解预判不等于正式认定？后续入口是否与类别匹配？
能否知道下一步？
处理结论是否对应下一环节？退回意见能否指导补充？当前节点通过是否与最终完成区分？
06 / DESIGN HANDOFF
交付的不是一个可点击页面，
而是一组明确的产品约定。
AI 辅助原型让方案更早被看见；交给开发时，还需要把页面背后的规则和边界讲清楚。以下是这份设计需要一起说明的内容。
谁能做，交什么
角色可见范围与操作权限；字段、附件与签字盖章要求；规则来源及待确认项。
何时能做，之后去哪
待处理、退回、通过与完成时的界面；不可操作的原因；审核意见及异常提示。
怎样算符合设计
以走访、条件预判和申报审核组织验收；逐项确认输入、处理结果与下一步。
正式规则、演示数据、待确认假设，必须在交付中区分。
AI 帮助推进方案。
产品判断，决定方案为何成立。