很多项目收到的需求只有“做得高级、简洁、有科技感”，页面数量、角色、数据和交付却不清楚。设计师只能边做边猜，客户也难以判断方案是否正确。
Brief不需要写成几十页，但关键问题必须明确；暂时未知的内容也应被标记，而不是假装已经确定。
01 用一句话说明项目为什么现在要做
是新产品上线、旧系统改版、业务增长、品牌升级还是开发重构？写清触发原因和希望改变的结果。
避免只写“提升用户体验”。
02 描述用户、角色和核心场景
列出主要用户、熟练程度、设备、环境和高频任务。B端项目还需角色权限、审批和交接关系。
人物画像不必虚构细节，场景要接近真实。
03 提供现状与证据
现有产品、数据、客服反馈、用户研究、竞品、技术约束和已知问题应集中提供。
把内部意见与用户证据区分开。
04 用矩阵明确范围
列出流程、页面、平台、断点、状态、语言和是否包含原型、设计系统、测试与开发走查。
同时写明不包含内容，便于报价和排期。
05 定义品牌与内容边界
提供Logo、视觉规范、文案语气、真实内容和素材授权。参考案例说明喜欢的具体原因，而不是只贴链接。
避免要求直接复制竞品。
06 写清交付、时间与决策机制
包括文件格式、命名、组件、标注、会议节奏、修改轮次、里程碑、预算和最终决策人。
如果上线日期固定，说明外部依赖和可调整范围。
UI设计Brief必填项
模块 | 关键问题 |
|---|---|
背景与目标 | 为什么现在做、要改变什么 |
用户与任务 | 谁使用、在哪用、完成什么 |
现状证据 | 数据、反馈、旧版本与问题 |
范围 | 流程、页面、状态、平台、语言 |
品牌内容 | 规范、文案、素材与授权 |
技术约束 | 框架、组件、数据与设备 |
交付排期 | 产物、里程碑、修改与验收 |
决策协作 | 负责人、反馈与审批 |
常见问题
没有用户数据还能写Brief吗？
可以，明确假设和未知项，并安排研究或验证，不能把内部猜测写成事实。
Brief越详细越好吗？
关键是决策信息完整，过多无关公司历史会增加阅读负担。
参考网站应该提供几个？
少量即可，说明具体借鉴点和不喜欢的地方，比大量链接更有效。
谁负责写Brief？
通常由项目负责人组织，产品、业务、设计、技术和内容共同补充。
设计公司可以帮助梳理Brief吗？
可以，需求梳理本身可作为项目发现阶段的交付。
链接复制成功
