Wireframing (Deep Workflow)
Wireframes are shared thinking tools—not decoration. The goal is alignment on structure, priority, and flows at low rework cost before pixels and code.
When to Offer This Workflow
Trigger conditions:
- - New feature with unclear information architecture or many UI states
- Stakeholders disagree on scope or number of screens
- Fast iteration needed before high-fidelity visual design
- Technical constraints (API shape, permissions) must shape the UI early
Initial offer:
Use six stages: (1) define intent and fidelity, (2) map users and scenarios, (3) structure and navigation, (4) key screens and states, (5) critique and test, (6) handoff. Ask which tool they use (FigJam, Figma, paper, Excalidraw) and the deadline.
Stage 1: Define Intent & Fidelity
Goal: Match fidelity to the question being answered.
Levels
- - Thumbnail flow: minutes only—steps and sequence
- Low-fi boxes: layout and rough component placement
- Mid-fi: realistic copy placeholders and density—still grayscale
Anti-patterns
- - Too polished too early—stakeholders anchor on color instead of structure
- Untitled flows—reviewers lose context
Exit condition: Reviewers know whether to judge flow, layout, or both in this round.
Stage 2: Map Users & Scenarios
Goal: One primary user and job-to-be-done per flow; edge cases listed explicitly.
Activities
- - Lightweight personas—only traits that change the UI (permissions, expertise)
- Scenarios as short stories: trigger → actions → success or failure
- Out-of-scope scenarios called out to prevent scope creep in wire review
Exit condition: Three to seven scenarios ranked; must-have vs later is clear.
Stage 3: Structure & Navigation
Goal: Information architecture before screen-level detail.
Practices
- - Sitemap or nav model: where the feature lives; deep-link expectations
- Naming: labels consistent with the user’s mental model; avoid internal jargon unless users know it
- Decide early if mobile and desktop diverge—don’t let it happen by accident
Exit condition: Nav entry points and breadcrumbs sketched.
Stage 4: Key Screens & States
Goal: Cover the happy path plus critical empty, loading, error, and permission-denied states.
Checklist per screen
- - One clear primary CTA; secondary actions de-emphasized
- Empty: educate and offer a next step; loading: skeleton vs spinner chosen deliberately
- Error: recovery path; permission denied: why and what to do next
Annotations
- - Numbered callouts for open questions—do not hide ambiguity
Exit condition: State matrix for the top three screens (rows = states).
Stage 5: Critique & Test
Goal: Structured feedback—not only subjective taste.
Review script
- - Five-minute silent read first
- Round-robin: confusion points and missing paths
- Capture decisions; assign owners for open questions
Lightweight usability
- - Click-through prototype or paper walkthrough with one or two users when risk is high
Exit condition: Prioritized change list; open questions tracked.
Stage 6: Handoff
Goal: Smooth handoff to visual design and engineering.
To design
- - Grid assumptions, responsive breakpoints, content priority order
To engineering
- - API dependencies; UI states that affect backend behavior (pagination, filters)
- Accessibility notes: focus order, live regions for dynamic updates
Artifacts
- - Link to a single source file; version snapshot or changelog entry when the handoff is formal
Final Review Checklist
- - [ ] Fidelity matches review goals
- [ ] Scenarios and edge states covered for critical flows
- [ ] IA and navigation coherent
- [ ] Empty, loading, error, and permission states considered
- [ ] Handoff notes for design and dev
Tips for Effective Guidance
- - Content-first where possible—placeholder lorem ipsum often mis-sizes real copy.
- Label screens and flows; reviewers often join mid-stream.
- Encourage disposable wires—speed beats beauty at this stage.
Handling Deviations
- - Existing design system: sketch with component skeletons even at low-fi—reduces surprise later.
- Tiny UI tweak: skip the full workflow—a single annotated screen may suffice.
线框图(深度工作流)
线框图是共享的思考工具,而非装饰品。其目标是在投入像素和代码之前,以较低的返工成本,在结构、优先级和流程上达成一致。
何时提供此工作流
触发条件:
- - 新功能的信息架构不清晰或包含大量UI状态
- 利益相关者对范围或屏幕数量存在分歧
- 在高保真视觉设计之前需要快速迭代
- 技术限制(API形态、权限)必须尽早影响UI设计
初始提议:
使用六个阶段:(1)定义意图与保真度,(2)映射用户与场景,(3)结构与导航,(4)关键屏幕与状态,(5)评审与测试,(6)交接。询问他们使用什么工具(FigJam、Figma、纸笔、Excalidraw)以及截止日期。
阶段1:定义意图与保真度
目标: 使保真度与待解答的问题相匹配。
级别
- - 缩略图流程:仅需几分钟——步骤和顺序
- 低保真方框:布局和粗略的组件放置
- 中保真:真实的文案占位符和密度——仍为灰度
反模式
- - 过早过于精细——利益相关者会关注颜色而非结构
- 未命名的流程——评审者失去上下文
退出条件: 评审者知道本轮应评判流程、布局,还是两者兼有。
阶段2:映射用户与场景
目标: 每个流程对应一个主要用户和待完成的任务;明确列出边缘情况。
活动
- - 轻量级用户画像——仅包含改变UI的特征(权限、专业度)
- 场景以短故事形式呈现:触发条件 → 操作 → 成功或失败
- 明确标出范围外的场景,防止线框图评审时范围蔓延
退出条件: 三到七个场景已排序;必须项与后续项明确区分。
阶段3:结构与导航
目标: 在屏幕级细节之前确定信息架构。
实践
- - 站点地图或导航模型:功能所在位置;深度链接预期
- 命名:标签与用户心智模型一致;除非用户熟悉,否则避免内部术语
- 尽早决定移动端和桌面端是否不同——不要让其意外发生
退出条件: 导航入口点和面包屑已草拟。
阶段4:关键屏幕与状态
目标: 覆盖正常路径以及关键的空状态、加载状态、错误状态和权限拒绝状态。
每屏检查清单
- - 一个清晰的主要行动号召;次要操作弱化处理
- 空状态:提供说明和下一步操作;加载状态:有意识地选择骨架屏或加载动画
- 错误状态:提供恢复路径;权限拒绝:说明原因及下一步操作
注释
退出条件: 前三屏的状态矩阵(行 = 状态)。
阶段5:评审与测试
目标: 结构化反馈——而非仅凭主观喜好。
评审流程
- - 先静默阅读五分钟
- 轮流发言:指出困惑点和缺失路径
- 记录决策;为未解决问题指定负责人
轻量级可用性测试
- - 当风险较高时,使用可点击原型或纸面走查,与一两名用户进行测试
退出条件: 优先级排序的变更列表;未解决问题已跟踪。
阶段6:交接
目标: 顺畅交接给视觉设计和工程团队。
对设计团队
对工程团队
- - API依赖关系;影响后端行为的UI状态(分页、筛选)
- 无障碍说明:焦点顺序、动态更新的实时区域
交付物
- - 指向单一源文件的链接;正式交接时的版本快照或变更日志条目
最终评审检查清单
- - [ ] 保真度与评审目标匹配
- [ ] 关键流程的场景和边缘状态已覆盖
- [ ] 信息架构和导航连贯一致
- [ ] 空状态、加载状态、错误状态和权限状态已考虑
- [ ] 为设计和开发团队准备的交接说明
有效指导的技巧
- - 尽可能内容优先——占位符的Lorem Ipsum文本常导致实际文案尺寸错误。
- 为屏幕和流程命名;评审者经常中途加入。
- 鼓励一次性线框图——在这个阶段,速度比美观更重要。
处理偏差情况
- - 现有设计系统:即使在低保真阶段,也使用组件骨架进行草图绘制——减少后续意外。
- 微小的UI调整:跳过完整工作流——一个带注释的屏幕可能就足够了。