IGNITE / AI PRACTICE
我如何将 AI 融入设计工作
在 Ignite 的设计工作中，我通常在三个节点引入 AI：方向形成前检验假设，复杂流程定稿前检查状态和角色，上线前审视衡量方式。AI 提出的问题不会直接成为设计结论；我会对照产品规则、实际界面和待确认事项，判断哪些需要进入方案。
How I Work with AI
In my design work at Ignite, I bring AI into three recurring moments: testing assumptions before a direction settles, checking states and roles before a complex flow is final, and examining what success measures actually mean. I review its findings against product rules, interfaces, and open questions before they enter the design.
01 / CHALLENGE
What am I assuming?
在确定设计方向之前，我会用 AI challenge 已经形成的思路，而不是让它直接生成更多方案。
Multi-insured purchase flow
为了避免不同 insured persons 的信息堆叠成一个超长表单，我最初采用 One insured person = one card 的结构。
我让 Product Brainstorming skill 以 Assumption Testing 的方式检查这个方向，重点是它隐含的规则边界，而不是重新生成界面。检查发现，按人分卡减轻了填写负担，却没有回答整体申请何时可以提交：每个人的信息都可能有效，但组合仍不满足产品要求；卡片已保存，也不等于整份申请已准备好。
我保留了 card structure，但重新定义了它的边界：Card 负责 person-level information；cross-person rules 和 overall readiness 由 application 层处理。
Before committing to a design direction, I use AI to challenge the idea already taking shape, rather than asking it for more screens.
Multi-insured purchase flow
To keep information for different insured people from becoming one long form, I began with a one insured person = one card structure.
I used a Product Brainstorming skill in Assumption Testing mode to examine the rules implied by that structure. Cards reduced form length, but did not explain when the whole application was ready: each person could be valid while the group failed a product requirement, and a saved card did not mean a ready application.
I kept the card structure and clarified its boundary. The card owns person-level information; the application owns cross-person rules and overall readiness.
02 / CHECK
What might break?
当一个功能同时存在管理端与使用端时，单独看每条流程都可能成立；问题往往出现在状态和角色的组合里。我把流程整理成结构化输入，让 AI 检查状态变化之后，另一个角色实际会看到什么、还能做什么。
When a feature spans an admin view and a user view, each flow can look sound on its own while combinations of states and roles still create conflicts. I structure the flow so AI can check what the other role will actually see and be able to do after a state changes.
- Admin action
- Publication state
- Contest phase
- Agent participation
- Visible content / available action
- Source
每条规则标记为 Confirmed rule / Candidate rule / Unknown。AI 可以组合已知条件、指出缺口，但不能把未确认的业务行为当成既定规则。
Contest — one activity, two views
Contest 在 Admin 端有 Unpublished / Published，活动本身又会经历 To Start / Ongoing / Ended；Agent 端还涉及查看、手动或自动报名，以及后续进度和结果。
我让 AI 对照 Admin 的报名名单、统计与 Agent 的活动入口，检查两种报名方式是否会产生相同的参与状态。它推演出一个需要避免的冲突：Agent 已通过名单自动报名，Admin 端将其计入参与人数，但 Agent 打开活动时仍看到 Sign up。若页面只根据“是否点击过报名按钮”判断状态，自动报名者会看到重复操作，统计也可能重复计算。
I label each rule as Confirmed, Candidate, or Unknown. AI can combine known conditions and surface gaps, but it cannot turn an unconfirmed business behaviour into a rule.
Contest — one activity, two views
Admin manages Unpublished / Published, while the contest moves through To Start / Ongoing / Ended. Agents can view, join manually or be enrolled automatically, and later see progress and results.
I asked AI to compare the Admin participant list and statistics with the Agent entry point. It surfaced a conflict to avoid: an automatically enrolled Agent is counted by Admin but still sees Sign up. If the interface checks only whether the Agent clicked the button, it can offer a duplicate action and count participation twice.
我把报名方式作为来源信息，是否已参与作为统一状态：手动报名与自动报名都进入 Joined；Admin 统计按 Agent 计数，Agent 端的报名入口、进度和结果按参与状态与活动阶段呈现。发布状态单独控制活动是否可见。
检查也留下一个不能自行补齐的边界：活动已经开始、Agent 已报名，Admin 随后执行 Unpublish。现有流程不足以回答已报名 Agent 能否继续查看进度或最终结果；我将它标为 NEEDS_CONFIRMATION，交由 PM / domain owner 确认。
I treated the join method as a source attribute and participation as one state: manual and automatic enrolment both become Joined. Admin counts Agents rather than join events; the Agent's entry point, progress, and results respond to participation and contest phase. Publication controls visibility separately.
One boundary remained unresolved: if Admin unpublishes an ongoing contest after Agents have joined, the flow does not define whether they can still see progress or results. I marked that behaviour NEEDS_CONFIRMATION for the PM or domain owner.
03 / MEASURE
How will I know if it works?
Third-party login / account binding
Google / Apple authentication 不只有一个成功结果。完成第三方授权后，Agent 可能通过已有手机号绑定原 Ignite 账号，也可能使用新手机号注册；流程还包含验证、密码设置和解绑等后续行为。
我让 AI 按两条账号路径检查 event 能证明什么。如果 login success 只对应 Google / Apple 的授权回调，就会把“第三方验证通过”和“进入 Ignite 账号”混为一谈；只看 binding success，也无法看出 Agent 是否回到了原账号，或新账号是否真正可用。
What does each event actually prove?
Third-party login / account binding
Google / Apple authentication has more than one successful outcome. After provider authorisation, an Agent may bind an existing Ignite account through a known phone number or register a new account; the flow also includes verification, optional password setup, and unlinking.
I asked AI to examine what events along both paths could actually prove. If login success fires at the provider callback, it conflates third-party authorisation with entry into Ignite. Binding success alone cannot show whether the Agent returned to the intended account or reached a usable new one.
What does each event actually prove?
我将衡量收敛为三层：Setup 要完成第三方授权及 Ignite 账号关联或创建；Value 要分别确认已有账号路径返回原账号、新账号路径成功进入新账号；Adoption 则只在再次到达登录页的用户中，观察有多少人重新选择 Google / Apple 并成功进入 Ignite。
这样，若连接完成但进入账号的人少，团队可以回看手机号验证与账号关联；若成功进入账号却很少再次使用，则需要检查再次登录时的入口和体验。指标指向不同的设计问题，而不只是汇报一次授权成功。
I organised measurement into three levels. Setup requires provider authorisation and account binding or creation. Value checks separately whether the existing-account path returns to the original account and the new-account path enters the new one. Adoption looks only at Agents who reach a later login opportunity, then checks whether they choose Google / Apple again and enter Ignite successfully.
If connection succeeds but account access drops, the team can examine phone verification and binding. If access works but repeat use is low, it can examine the entry point and return experience. The measures point to different design questions.
REFLECTION
把 AI 变成可复用的设计检查机制
我为每次 AI 介入定义三个边界：它需要理解哪些事实、要检验哪一种不确定性，以及什么样的输出可以影响设计。任务会变化——质疑假设、推演状态、审视指标——但审核原则保持一致：依据可追溯，未知项明确保留，建议必须能转化为具体的设计判断。
这使 AI 成为设计工作中持续可用的检查机制。它扩大我能够检验的情境，也帮助我更早发现隐含假设与信息缺口。我的职责是决定何时引入 AI、如何评价它的输出，以及哪些结论足以进入产品。
I set three boundaries for every AI task: what facts it needs, which uncertainty it should examine, and what kind of output may influence the design. The task can change—from challenging an assumption to exploring state combinations or examining a metric—but the review principles stay consistent: trace the basis, keep unknowns visible, and turn sound suggestions into design judgments.
That makes AI a dependable review layer in my design work. It broadens the situations I can examine and exposes hidden assumptions earlier. I remain responsible for deciding when AI should participate, how its output is assessed, and which conclusions are ready to enter the product.