用 Boardmix 做产品设计，重点是让需求、方案、评审和交付之间的关系可见。先把用户问题讲清楚，再展开候选方案，用用户旅程、流程图与低保真原型检查体验，最后留下开发能够理解的规则、验收条件和决定理由。无限画布承担共同梳理与讨论，专业界面设计、开发实现和验证仍由相应人员与工具完成。
产品设计不是设计师单独完成几张界面，还需要产品经理、开发、运营等角色在不同阶段协作。方案分散在文档、图片和聊天记录里时，容易出现同一需求被不同人理解成不同版本的问题。可以先查看 Boardmix 产品需求文档模板，把当前用户问题、范围和待确认事项建立为共同起点。
1. Boardmix 适合承担产品设计中的哪些协作工作？
1.1 无限画布：把相关材料摆在同一处
产品设计初期往往同时涉及用户反馈、竞品截图、业务规则与初步方案。Boardmix 的无限画布允许团队按问题分区，把材料与解释相邻摆放，用连线说明它们之间的关系。它的价值不在于画布越大越好，而在于团队能从一个判断回到支持它的材料。
例如讨论注册流程时，左侧放用户反馈，中间画当前流程，右侧放两种改进方案。参与者指出“登录要求出现得太早”时，可以直接标记对应节点，不必靠口头描述让其他人寻找同一张截图。
1.2 模板：复用讨论结构，而不是复用结论
需求文档、团队头脑风暴、用户旅程和原型等模板，可以帮助团队组织材料。使用前先删掉不适用的提示项，补上本项目的约束。模板中的示例不等于真实用户需求，空白处也不意味着必须编造一条内容填满。
1.3 实时与异步协作：保留讨论对象和确认状态
多人实时编辑与评论适合共同补充材料，也方便未能到场的成员之后查看上下文。跨地区协作时，应写清楚反馈对象、截止时间和需要谁确认。新意见、已采纳修改和最终决定应分别标记，避免评论越来越多却无法判断当前版本。
1.4 工具分工：用链接交接，不默认自动集成
Boardmix 可以作为需求与方案讨论的工作区；高保真界面和复杂交互交给专业设计工具，研发任务放在团队约定的项目系统。把设计稿链接、需求编号与任务入口整理在白板上，有助于找到对应内容，但链接不等于双向同步。采用 Pixso、墨刀、Jira 等工具时，应分别核对实际接入方式，不能默认文件、评论和任务会自动流转。
2. 从用户洞察到交付，六个阶段分别做什么？
设计过程需要在发散与收敛之间切换。Design Council 的双钻模型将其表达为发现、定义、发展和交付：先理解真实问题，再探索不同答案并通过测试改进。下面六个工作阶段是便于团队协作的安排，不代表设计只能按直线推进；发现关键假设不成立时，应回到对应环节。
2.1 需求分析与用户洞察：将观察和解释分开
整理用户调研时，把访谈原话、观察行为、业务背景分别记录，再归纳问题。可以用思维导图建立主题，用文档保存访谈详情，用卡片记录待验证假设。不要把“用户说按钮难找”直接等同于“必须增大按钮”，前者是材料，后者只是一个可能方案。
访谈记录至少包含对象特征、情境、问题与回答。涉及个人信息时应按团队规定脱敏。下面的短视频软件访谈模板展示了提问与记录的组织方式，实际内容应来自真实访谈。
2.2 创意激发与方案探索：先发散，再说明取舍
围绕清楚的问题，让成员先各自写想法，再用便签在画布上汇集。主持人可以人工聚类相近观点，但不能仅因词语相同就合并不同需求。筛选时说明用户价值、实现成本与风险等标准，保留被放弃方案的主要理由；投票表达偏好，不替代关键约束的确认。
例如“缩短注册时间”可以产生游客浏览、简化字段、分步补充信息等不同方向。先比较它们对访问、合规与后续服务的影响，再决定优先验证哪个方案，避免最快说出的想法直接变成唯一方案。
2.3 用户体验与结构设计：旅程、信息架构各有用途
用户旅程关注人在不同触点的任务、疑问与体验；信息架构关注内容如何分类、命名与被找到。可以先画出目标用户从了解服务到完成任务的路径，标记关键障碍，再梳理导航与页面层级。不要用一张页面树代替用户旅程，也不要在缺少观察时随意填写情绪分值。
查看健身会员注册用户旅程图。使用时可重点检查：用户何时理解会员规则、何时提供个人信息、何时知道下一步，而不是只复制图中的阶段名称。
2.4 原型构建与流程验证：先检查任务能否走通
用基础形状和流程图说明页面结构、操作顺序与分支，或从APP 原型模板开始整理低保真方案。首轮先检查用户能否完成任务，再讨论视觉细节。登录失败、无数据、权限不足、网络错误等异常状态也应有位置。
白板上的原型用于表达和讨论；需要复杂交互、高保真界面或交付标注时，应使用相应专业工具。将设计稿入口、版本与待评审范围写回白板，有助于不同角色找到同一份方案，但不把静态流程当作已经验证的可用产品。
2.5 设计评审与持续迭代：从意见走向可验证问题
评审时给出任务、目标用户和限制，再邀请成员对具体对象评论。把“这个页面不好”改写成“用户在选择课程前看不到取消规则，可能在付款后才发现限制”，更容易讨论解决办法。记录谁确认了修改，以及哪些问题需要用户测试而非内部投票决定。
NN/g 的可用性测试介绍强调让具有代表性的参与者完成真实任务，并观察其行为。评审意见可以指导测试，但不能代替用户实际使用。设计一个不暗示操作路径的任务，例如“为周末安排一节适合你的课程”，比让用户“点击右上角预约按钮”更能检查界面是否易理解。
2.6 交付协同与项目整合：交接规则，不只交图片
开发交付至少需要需求范围、页面与状态、业务规则、异常处理、验收条件和未决问题。白板中可以将这些内容与设计稿链接、任务编号对应起来；由负责人员确认进入后续工作的版本。单纯导出一张长图，通常不足以解释所有交互细节。
如果设计变更影响已安排的工作，应更新对应需求与任务记录，并通知相关成员。不要只修改白板中的图，却让研发继续按照旧的验收条件实现。迭代范围如何选择，可以衔接Sprint 规划的目标与工作项安排。
3. 将六类 Boardmix 能力映射到具体设计产物
选择功能时，先问需要留下什么产物，而不是把每个功能都用一遍。以下安排让工具服务于设计判断，也保留后续交接的路径。
3.1 无限画布与多媒体：建立材料和结论的对应关系
将访谈片段、产品截图、竞品分析与设计草图按问题排列。每个区域有标题，关键结论旁附材料链接或注释。长文本用文档承载，画布上保留摘要与关系，避免为了追求“一张板”把所有细节缩到无法阅读。
3.2 模板库：按问题选择合适框架
战略判断可用SWOT 分析矩阵梳理内外因素，用户体验可用旅程图，工作跟进可用敏捷看板。它们回答不同问题，不应互相替代。团队可以整理常用模板索引，标记适用阶段、填写要求和负责人，避免每次从零搭建，也避免模板成为僵化流程。
3.3 实时编辑与评论：将反馈锚定到对象
多人同场讨论时，使用同一块白板表达问题；异步评审时，要求评论包含对象、出现条件与期望结果。主持人汇总冲突意见并安排确认，不将“评论已写下”视作问题已经处理。通话与屏幕分享可使用团队已配置的会议工具，产品是否支持某种具体集成应单独核对。
3.4 AI 辅助：生成草案，不生成用户事实
在已有问题范围之后，可用 AI 辅助列出候选方向或生成思维导图初稿，再在画布上编辑。比如提示：“面向第一次使用健身预约服务的用户，列出从浏览课程到确认预约可能遇到的问题，按信息、流程、异常状态分类；不要编造访谈数据，将所有推测标为待验证。”
生成后，团队应删除不适用项，补上已知业务规则，并用材料检验关键假设。AI 不能替代真实访谈、正确计算业务收益或证明某个方案可行；涉及敏感信息时先遵循团队的数据使用要求。功能入口和可用范围以当前账户为准。
3.5 工具链路：建立索引和版本约定
需求编号、设计稿地址、研发任务和测试记录可以组成一条可追踪链路。在白板相应区域记录这些入口，注明哪个系统维护最终状态。若采用插件或集成，需验证支持的对象、权限、更新方向与失败处理；没有验证时，使用明确的链接与人工交接，不承诺自动同步。
3.6 权限与版本：把可见范围和里程碑说清楚
根据参与角色设置实际支持的访问范围，分享前检查外部成员能看到什么。重要评审后，记录日期、版本标识、已确认决定和遗留问题，必要时保留阶段快照。版本历史的可用范围与保留时长需按实际账户核对，不能假设任何修改都能无限期恢复。
4. 建立可复用工作流：从角色分工到完整演示
4.1 明确角色分工，让确认责任可见
产品经理负责问题范围、业务规则与价值取舍；设计师负责用户路径、界面结构和方案表达；开发人员负责技术依赖、实现边界与相关风险。实际分工可按团队调整，但每个重要决定都应找到确认者。不要把“所有人共同负责”当作无人承担推进责任的理由。
查看软件项目开发管理流程模板，将参与角色与关键交接点对应起来，再按团队实际职责调整。
4.2 建立资源索引，复用材料和记录格式
整理需求调研表、用户画像模板、旅程图、线框图与看板入口，说明各自的适用任务。共用模板中的固定字段可以包括问题、材料链接、决定、负责人和日期，但项目结论必须重新填写。模板库的质量取决于是否有人维护，过期示例不应继续被当作有效业务规则。
4.3 将需求、设计与任务连接起来
给关键需求一个稳定编号，例如“REQ-续费-01”，在白板流程节点、需求说明和研发任务中共同使用。编号帮助定位，不意味着工具会自动同步。发生改动时，更新对应的规则和入口，并说明变化是否影响已排工作。这样新成员可以顺着编号找到背景与当前方案。
4.4 开展设计评审，区分讨论与决定
提前给出评审范围，在画布上将反馈按“需修改、需验证、暂不处理”分类；每项记录理由和负责人。争议涉及真实行为时，转化为测试问题；涉及资源取舍时，交由适合的决策者确认。会议结束前读一遍决定与行动项，避免不同角色带着不同理解离开。
4.5 归档里程碑，让后续迭代理解原因
阶段结束时保留当前方案、被放弃的重要选项和选择理由。不要只存一张“最终版”图片，让之后的团队无法判断某个限制为什么存在。执行过程中可用卡片看板记录工作状态，已完成仍需对照验收条件，而不是仅拖到“完成”列。
查看敏捷迭代任务看板，为后续任务保留负责人、验收说明和对应的设计入口。
4.6 演示案例：健身课程预约如何从问题走到交付？
假设团队要改进健身课程预约，初步问题是“用户在预约后才注意到会员与取消规则”。以下是教学演示，不代表真实客户调研或效果数据。画布首先分为用户材料、当前流程、候选方案、验证记录、交付五区，所有假设明确标记为待验证。
第一步，定义问题。访谈时追问用户何时决定预约、在哪里查看规则、遇到过什么困惑，不直接问“你是不是需要一个更大的规则按钮”。记录原话与观察，再判断问题是规则缺失、位置不明显，还是规则本身难理解。
第二步，比较两种方案。方案 A 在课程详情中展示关键规则，方案 B 在确认前集中提醒。A 能更早提供信息，但要控制详情页密度；B 更接近决策时刻，却可能让用户临时返回重新选择。两者可组合，也可先验证其中一种，不能仅按界面美观选择。
第三步，画出完整路径。浏览课程、检查登录与会员状态、确认名额、查看规则、提交预约、获得结果。标明会员已过期、课程已满、重复提交和请求失败的分支。每条分支要能说明用户看见什么、能做什么，以及如何返回。
第四步，安排任务测试。请符合目标用户特征的参与者完成“为本周末选择并预约一节课程”的任务，观察是否主动找到限制、如何判断能否参加、遇到名额不足时如何处理。记录行为与具体卡点，不能以“用户说喜欢”代替任务完成情况。
第五步，整理交付条件。例如“会员过期时显示状态说明与可用的下一步，不能显示预约成功”；“重复提交不能造成两笔有效预约，前后端处理规则需共同确认”；“课程已满时明确说明结果并允许返回选择”。这些是待团队确认的验收示例，不是任何项目都适用的默认规则。
最终，设计稿、规则、异常流程和任务入口通过编号对应。若测试发现用户仍误解取消限制，应回到信息表达与流程设计，而不是只给流程节点换颜色。记录这轮发现与下一步验证，才使白板成为设计判断的持续工作区。
5. 产品设计协作中常见的边界问题
5.1 Boardmix 能替代专业 UI/UX 设计工具吗？
它适合需求梳理、头脑风暴、用户旅程、流程图和低保真方案讨论。精细界面、复杂交互、开发标注等工作仍需按项目要求选择专业工具。可以配合使用，但应明确信息如何交接，不把“能展示设计稿”理解成拥有全部专业设计能力。
5.2 在线协作怎样处理敏感信息？
先确认谁需要查看、谁需要修改，再按实际支持的权限设置访问范围。外部分享前移除不必要的客户信息和内部材料，必要时建立单独的评审副本。企业身份管理、数据保留和安全要求应由团队逐项核对相应方案，不能因为使用某款工具就默认满足全部合规要求。
5.3 多人协作时，白板太乱怎么办？
先按问题或阶段分区，在入口放目录与当前状态；每一区保留简洁结论和材料入口，长说明放入文档。约定命名与归档负责人，旧版本保留标识。用户旅程不清楚时可从用户旅程图模板重新梳理触点，不必把所有内容删掉重画。
5.4 免费范围是否足够完成项目？
先用一个真实任务检查是否满足参与人数、分享、导出及所需功能，再根据当前账户显示的范围评估。不要只因为项目叫“产品设计”就推断必须升级，也不要把免费试用理解成所有团队功能不限使用。
5.5 跨工具合作怎样避免版本混乱？
给每类产物指定维护位置：白板记录讨论与关系，需求文档记录确认后的规则，专业设计工具维护设计稿，项目系统跟进研发任务。各处通过稳定编号与链接互相定位，变更时明确通知和确认。是否能自动同步，需要对所选集成另行验证。
查看产品开发流程图，检查从需求、设计到开发的交接是否有对应责任人与产物。
开始下一轮设计前，检查用户问题是否清楚、主要流程与异常状态是否齐全、关键假设是否经过验证、交付条件是否能够执行。需要先做好产品需求分析，就从问题与材料开始；准备组织共同评审，可参考高效会议的议程与决策记录。在Boardmix 创建产品设计画布时，先放好一个真实问题与对应材料，让协作从可讨论的内容出发。
粤公网安备44030502008643