高保真原型不需要默认包含整个产品，只应覆盖能支持本轮测试或交付的关键页面、真实内容、组件状态和异常路径。先用一句话写清要验证的任务，再反推需要哪些页面与状态。
如果要在Pixso 中制作可评审的交互原型，可以先整理一条任务的页面和状态，再连成交互路径。需要理解基本定义时，先看高保真原型的特征与用途。
1. 先定义测试任务，再确定范围
例如验证“新用户通过邀请完成手机号注册并加入团队”，需要邀请入口、手机号填写、验证码、受邀团队确认、加入结果，以及已有账号、验证码过期和邀请失效等分支；与任务无关的个人中心不必同步精修。
把测试问题写成“用户能否理解为什么需要手机号，并在验证码失败后继续完成注册”，比“做完注册模块”更容易控制范围。前者决定要观察的行为，后者往往让团队多画很多不影响结论的页面。
旅行 App 的登录、主页和目的地详情属于不同页面。评审若只覆盖一次目的地查找，就应围绕这条任务组织页面，不必把整套 UI 都制作成可交互原型。
2. 主路径页面：入口、操作与结果
至少包含任务入口、必要决策点、核心操作、成功结果和可用的返回路径。页面数量不是越多越好，路径要能独立走通。
这条任务可以用六个画板串起：邀请入口 → 手机号输入 → 验证码输入 → 确认受邀团队与身份 → 加入结果 → 团队工作台。返回手机号页时，要保留已输入的号码；确认团队时，让用户看见团队名称、邀请人和被分配的身份。加入成功后进入工作台，不再显示注册入口。无需连接的区域不要做成看起来可点却无反馈的按钮。
社区论坛也有帖子列表、详情和个人主页等页面类型。页面套件可以帮助盘点信息范围，真正制作原型时，仍要按“找到帖子并回复”等具体任务连接入口和结果。
3. 真实内容：优先替换会影响决策的占位符
标题、按钮、表单、错误提示和列表密度应使用真实或可靠样本。只有这样才能判断阅读成本、布局和操作是否成立。
至少准备一组短内容和一组长内容：两字姓名与较长英文姓名、短团队名与接近上限的团队名、单行错误与两行错误。这样才看得出按钮是否被挤出首屏、提示是否挡住输入框，以及表单恢复后焦点落在哪里。
4. 组件状态：不只画默认界面
| 对象 | 必要状态 |
|---|---|
| 按钮 | 默认、悬停、按下、禁用、加载 |
| 输入框 | 空白、焦点、已填写、错误、不可编辑 |
| 列表 | 正常、空数据、加载、加载失败 |
| 弹窗 | 打开、关闭、确认、取消、操作失败 |
组件状态还应有触发条件。例如验证码输入不完整时按钮禁用；提交后按钮显示处理中并防止重复提交；验证码错误时保留手机号，清空需要重输的验证码，并明确告诉用户下一步。若只有“默认/错误”两张图，却没有说明怎样触发和怎样恢复，开发仍要猜交互规则。
5. 异常分支与返回路径
核心操作需要说清网络异常、输入错误、权限不足、操作取消和返回上一步如何处理。若异常不影响本轮结论，可明确标记而非全部制作。
异常分支不必都做成完整模拟后台。可把“验证码已过期”“请求次数过多”分别连到对应提示画板，用注释说明触发条件。这样参与测试的人仍能经历关键反馈，团队也不会把原型里的演示数据误认为真实系统响应。
6. 范围取舍：哪些页面可以保持低保真
使用频率低、交互风险低、不影响当前测试结论的页面可以保持低保真。若仍不确定是否应升级，参考低保真升级高保真的判断标准。
范围可以分成三层：本轮必须能点击的核心路径；只需展示的相关页面；明确不测的模块。把后两层标注在原型首页，避免评审者把尚未制作的区域误当成交互故障。更改测试问题后，再调整原型范围，而不是为了整齐把每个模块都补到同样精细。
7. 用Pixso组织页面和状态清单
在 Pixso 中可按核心任务组织页面，用交互连接路径，并通过评论记录待确认状态。画板名称可使用“注册-手机号-默认”“注册-验证码-过期”，避免只有“页面1”“页面2”。
确定范围后，可进入Pixso建立高保真页面清单。
发给评审者之前，从分享入口重新打开一次原型：检查起始页面、点击热区、返回路径和最终结果；请未参与制作的同事按任务说明走一遍。记录他在哪个步骤停住、误解了哪句文案，再回到相应画板修改，而不是只问“这个页面好不好看”。
所有异常状态都必须做吗？
不必。优先制作会影响任务完成和本轮判断的异常，其余状态可列入后续范围。
