原型设计可以按七步推进：明确目标、梳理任务、列出页面、搭建低保真、补齐交互状态、评审测试、整理交付。关键是让每一步解决一个具体问题：为什么做、用户怎么走、页面放什么、操作后发生什么，以及团队准备实现哪一版。发现问题时返回对应步骤修改，不必把整套流程从头重做。
用墨刀原型开始时，先画一条能走通的核心任务，再复用组件、补充异常和分享评审。下面保留完整七步方法，并用“新用户开通会员”串起页面清单、状态说明和交付记录；不熟悉原型类型时，可先了解原型设计的定义与常见形式。
先看七步流程，每一步分别留下什么
不要用页面数量衡量进度。画了十个页面，但用户不知道提交后是否成功，仍然缺少关键设计；只做四个页面，却把正常、取消和失败路径讲清楚，已经能够支持一轮有价值的评审。
| 步骤 | 先回答的问题 | 可以交给下一步的产物 |
|---|---|---|
| 1. 明确目标 | 谁在什么情况下，要完成什么 | 核心任务、范围和待验证问题 |
| 2. 梳理任务 | 从入口到结果，用户与系统分别做什么 | 主流程、关键分支和返回路径 |
| 3. 列出页面 | 每一步需要哪些信息与操作 | 页面清单、字段与页面关系 |
| 4. 搭建低保真 | 不靠装饰，用户能否看懂顺序 | 真实文案下的布局与可点击路径 |
| 5. 补齐交互 | 提交、等待、失败、退出后怎样继续 | 交互说明、状态和恢复方式 |
| 6. 评审测试 | 规则是否正确，用户是否理解 | 问题、修改决定和负责人 |
| 7. 整理交付 | 本轮实现什么，依据哪一版 | 原型版本、规则、验收条件和未决项 |
第一步：明确目标、用户和本轮范围
原型开始之前，先写清楚为谁设计、在什么场景使用、用户要完成什么，以及这次最需要验证什么。“设计一个会员中心”太宽；可以收敛为“第一次购买会员的用户，能否理解权益和费用，完成开通，并知道会员是否生效”。
这句话会直接影响页面：费用与开通条件要在提交前看得到，结果页要说明生效状态，而不是只放一个“成功”图标。是否加入积分、邀请好友、等级升级，取决于它们是否帮助完成当前任务，不能因为竞品有就全部画进来。
- 本轮包含：查看权益、选择套餐、确认订单、查看开通结果。
- 本轮暂不包含：积分商城、家庭共享、会员等级体系。
- 先确认的业务规则：费用如何展示、是否续费、何时生效、取消与退款如何处理。
- 需要观察的问题：用户能否找到费用说明，是否理解购买内容，提交后能否判断结果。
规则还未确定时，给它标记负责人和待确认项，不要在界面里写成已经承诺的权益。若要设定完成时间等量化目标，应说明团队选择该目标的依据；不能把随手写的“两分钟完成”当成普遍合格标准。
第二步：先画用户任务，再决定页面跳转
任务流描述动作及其结果。会员开通可以写为“找到权益入口→比较套餐→确认费用与条件→提交开通→查看结果”。只写“首页→详情→成功页”，看不出用户在每一步需要判断什么。
把取消和失败一起画出来：从确认页返回，套餐选择是否保留；提交失败后重试，会不会再次生成订单；暂时无法确认结果时，用户去哪里查询。这里先确认业务上的去向，下一步再决定用页面、弹窗还是局部提示表达。
可以在墨刀白板用节点整理流程，把系统响应写在连线旁。例如“收到开通成功状态→显示会员有效期”，不要仅写“点击→成功”。如果结果依赖支付或服务响应，应让研发确认状态来源，而不是由原型连线代替真实规则。
第三步：把流程变成页面清单
每个页面都要有任务。会员案例中，“选择套餐”和“确认订单”可以分开，也可以在同一页分区；取舍取决于信息量和确认风险。先列清信息，再判断是否需要新增页面。
| 页面或状态 | 必须看见的信息 | 操作与去向 |
|---|---|---|
| 会员权益 | 权益内容、适用条件、套餐入口 | 选择套餐；返回原入口 |
| 套餐选择 | 周期、费用、选中状态、续费条件 | 选定套餐后进入确认；不选择时说明原因 |
| 订单确认 | 所选套餐、应付金额、关键条款 | 提交；返回修改并保留已选内容 |
| 开通结果 | 当前结果、生效时间或查询方式 | 查看会员；结果不明确时查询订单 |
| 失败反馈 | 可理解的原因、已保留的内容 | 重试或修改；不让用户无故从头填写 |
这张表也能帮助分工。设计师知道每页的信息优先级，研发能指出哪些状态来自接口，产品负责人能发现还没确认的条款。如果某一行只是为了让页面显得丰富，可以先移出本轮。
第四步：做低保真，把真实内容放进去
低保真阶段先处理布局、阅读顺序和关键操作，弱化装饰性视觉。不要所有标题都写“示例文本”，或把费用、权益和按钮都放在同样大小的方框里：这样很难判断哪条信息应该先被看到。
在墨刀里按页面清单建立页面，先放套餐名称、费用、权益条件和按钮，再连接选购路径。复制同一页做两种信息顺序：一版先讲权益，一版先展示套餐。比较时让同事完成“找到适合自己的套餐并说明费用”，不要只问哪版更美观。
用长短不同的套餐名、较多权益条目和未选择状态检查布局。若用户不断返回上一页找费用，先调整信息出现的位置；若条款看不懂，先修改表达。此时单纯换颜色或补插画，通常不能解决这些问题。
第五步：补齐交互规则、状态和恢复路径
可点击不等于规则完整。按钮按下后的等待、失败后的保留内容、返回后的选中状态，都应在原型或旁边的说明里能找到。复杂业务规则不一定全部做成动画，但需要和页面对应。
| 触发条件 | 界面应表达什么 | 用户怎样继续 |
|---|---|---|
| 尚未选择套餐 | 显示选择要求，提交不能无条件成功 | 选择套餐后继续 |
| 提交处理中 | 显示处理中，防止把重复点击当成多次购买 | 等待结果；按实际规则提供查询入口 |
| 已确认开通成功 | 显示对应套餐、生效状态和后续入口 | 查看会员信息或开始使用权益 |
| 明确失败 | 说明原因，保留仍有效的套餐选择 | 重试或返回修改 |
| 响应中断、结果未知 | 不能直接断言购买失败或成功 | 查询订单状态，再决定后续操作 |
“结果未知”和“明确失败”尤其要分开。用户看到网络错误，不代表服务端一定没有完成操作；这类场景应和研发共同确认查询、重复提交和状态更新的处理。原型用于展示约定后的体验，不能替接口实现做保证。
第六步：把业务评审与用户测试分开组织
内部评审先检查范围、费用条款、状态来源与技术依赖；用户测试观察目标用户能否理解信息并完成任务。让业务同事确认规则是必要的，但不能代替目标用户实际尝试。
给用户的任务可以是：“你准备使用某项会员权益，请选择合适套餐并完成开通。”不要提前告诉他点击哪一个按钮。观察他先看什么、在哪里犹豫、是否反复查费用；完成后请他说明买了什么、是否会续费、现在是否已生效。
记录时把现象与解释分开。例如“确认页返回套餐页两次”是行为；“费用说明出现太晚”是团队需要检验的解释。决定把费用提前后，再让用户完成相同任务，确认修改是否解决了问题。
问题应回到正确步骤处理：入口找不到，检查任务与导航；费用不理解，检查信息顺序和文案；不知道开通结果，检查状态与反馈；规则本身未定，先由业务负责人决策。更完整的会议准备可参考产品原型评审方法。
第七步：整理交付，让下一位协作者接得住
交付不是只发原型链接。研发需要知道实现哪一版、哪些页面在本轮范围内、数据与状态来自哪里，以及还有什么问题未确定。原型、规则说明与需求文档可以分别承载不同信息，但同一规则应有明确的维护位置。
| 交付项 | 会员开通项目中的写法 |
|---|---|
| 版本与范围 | 记录本轮确认版本；包含开通主流程，不包含积分商城 |
| 页面与规则 | 页面清单链接到原型；费用、续费、生效规则链接到对应说明 |
| 状态与验收 | 无选择、处理中、成功、失败、结果未知均有预期反馈 |
| 修改记录 | 记录“费用提前到套餐区”及对应问题，方便理解改动原因 |
| 未决事项 | 例如结果查询接口待研发确认，写明负责人和影响范围 |
评审后仍然发生改动时，在同一项目里维护当前方案，并说明变化影响哪些页面和条件。不要让一份旧截图、聊天里的口头说明和最新原型同时充当“最终版”。
原型设计应遵循哪些原则？
流程解决“先做什么、后做什么”，原则帮助团队在信息不完整、时间有限时做取舍。下面五条原则适用于大多数产品原型项目。
原则1：先定义要验证的问题
没有验证问题，原型很容易变成页面数量竞赛。每轮原型只聚焦最重要的不确定性，并明确什么证据会支持或否定当前方案。
原则2：先流程，后页面，再视觉
流程错误时，单个页面再精致也无法帮助用户完成任务。先确认任务链路，再决定页面分工，最后才进入视觉和动效细节。
原则3：保真度服务于沟通目的
低保真适合早期探索和流程讨论，高保真适合体验演示、可用性测试或研发沟通。选择保真度的标准是“能否回答当前问题”，不是越接近成品越专业。
原则4：正常流程和异常状态同样重要
真实产品不会永远有数据、权限和稳定网络。原型如果只展示理想路径，评审通过的往往只是演示，而不是可以落地的产品方案。
原则5：每次评审都要形成决策
评审结果应落到保留、修改、删除、待验证或暂不处理。没有负责人和下一步的意见，只会在下一次会议中重复出现。
低保真和高保真原型应该如何选择？
| 判断维度 | 优先低保真 | 考虑高保真 |
|---|---|---|
| 当前问题 | 流程、结构、功能范围尚未稳定 | 需要验证视觉理解、细节操作或演示体验 |
| 变化频率 | 方案仍会频繁调整 | 主要流程已经确认 |
| 参与者 | 产品、设计、研发进行内部讨论 | 目标用户、客户或决策者需要接近真实体验 |
| 投入成本 | 时间有限，需要快速比较多个方案 | 高风险环节值得投入更多制作成本 |
一个常见误区是把低保真和高保真看成必须依次完成的两个固定阶段。实际项目可以只对高风险页面提高保真度，其余页面保持足够表达流程的程度。
在墨刀中串联页面、交互和团队反馈
先建立页面清单，用组件搭建低保真结构，再设置页面跳转和控件交互。制作会员开通时，可以复用模板和组件搭建原型，例如套餐卡片、确认摘要和结果提示；修改费用表达后，检查所有复用位置，避免前后页面不一致。
分享给团队前，从同一个入口走完选择、确认、返回、失败与结果查询，把规则附在对应位置。评论应指向具体页面或问题；处理后留下修改决定，便于团队在下一轮复核。想开始练习，可以先完成上面五个页面或状态，再邀请一位没有参与搭建的同事按任务操作。
AI可以帮助起稿，但输入要带上已经确定的规则
用墨刀AI生成原型初稿时，可以把目标用户、页面清单和状态表一起输入。不要只写“做一个会员中心”，然后默认生成的积分、自动续费或套餐政策就是业务要求。第一轮先生成核心路径，第二轮再针对费用出现位置、返回保留和未知结果进行修改。
工具可以按阶段组合：用白板梳理目标和流程，用原型工具连接页面与状态，视觉方向确定后再处理设计规范与交付资源。Boardmix适合共同整理材料，Pixso可参与视觉与设计交付；是否使用额外工具取决于团队已有流程，不必为完成七步而分别购买七种工具。
关于原型设计流程的常见问题
原型设计流程必须完整走完7步吗？
不必机械执行。小改动可以合并步骤，但明确验证目标、表达关键流程、检查状态并形成交付结论这几件事不应省略。项目越复杂，越需要把输入、输出和决策记录清楚。
产品经理和设计师谁负责原型？
取决于团队分工。产品经理通常负责业务目标、需求范围和规则，交互或 UI 设计师负责信息结构、交互体验和视觉表达。无论谁操作工具，原型都应由产品、设计、研发共同评审，而不是某个岗位独立完成。
什么时候需要做用户测试？
当团队对用户是否理解入口、信息或操作方式缺少把握，或者错误决策的开发成本较高时，应该尽早测试。测试不一定要等高保真完成，低保真原型同样可以验证任务流程和信息结构。
原型做到什么程度可以交付研发？
当研发能够理解页面关系、关键行为、状态、权限、数据和范围，并且主要未决问题已经有负责人和处理计划时，就具备交付条件。是否高保真不是唯一标准，规则是否清楚更重要。
