这套系统里的工作如何运转？
设计需求以卡片进入「需求」列，可来自产品经理或内部团队——描述问题，而不是描述想要的样子。设计经理把它移入「调研」列，让设计师吃透背景：同类界面、用户反馈、技术约束。然后「设计」列：从线框草图到可交互原型逐步成型，各版本按顺序挂在卡片上。就绪的进入「测试」列，做快速可用性测试或专家评审；通过后进入「交付开发」列，以前端工程师签收的终版规格文件交接。开发完成后卡片进入「走查」列，把实现与设计做视觉比对；结论归入「沉淀」列，反哺设计系统。
聊天用于开发期间设计师与工程师的快速对齐：技术约束要求调整、边界状态的疑问立即解决，绝不让实现靠猜。论坛保存超越当下的事项：设计系统决策、可用性测试结果、设计评审会——视觉语言由此逐渐统一，而不是各设计师各凭品味。
设计经理接收需求、排序，主持「测试」评审、批准「交付开发」。设计师从「调研」到「走查」拥有自己的卡片并按序上传版本。前端工程师从「交付开发」接棒，与设计师在「走查」列对完才关闭。底线是：未测试不交付，未走查实现不关闭——设计与代码之间的落差在这里弥合，而不是等用户投诉。
谁负责什么？
这套系统中的运营角色，以及每个角色在日常工作中的职责——可以原样指派给你的团队，也可以按你们的实际情况调整。
设计经理
接收并排定需求优先级，主持测试与交付评审，经论坛守护设计系统的一致性。
体验与界面设计师
执行调研、设计与测试，按序把版本挂上卡片，关闭前对实现做视觉走查。
前端工程师
从「交付开发」连同规格接收设计，经聊天对齐技术约束，在「走查」列比对实现。
从第一天起就为你准备好什么？
系统单元
- 任务 — 带有工作流列和执行卡片的看板
- 聊天 — 团队快速日常协调频道
- 论坛 — 在有序版块中留痕的讨论——决策与知识永不丢失
论坛版块 (4)
- 设计系统已定组件与视觉规范的决策：色彩、按钮、表单——每位设计师与工程师的官方参照。
- 设计评审测试前接受集体评议的稿件，附设计师据此修改的留痕意见。
- 可用性测试结果测试结论摘要：用户卡在哪、我们因此改了什么。
- 灵感与参考团队收集的优秀案例与应用，附值得借鉴之处的分析。
«本系统工作规则» — 已在论坛置顶
1. 每个设计需求都要描述问题与目标——不接受没有背景的“给我画个某界面”。 2. 设计版本按序挂在卡片上，最新版是唯一参照。 3. 未通过「测试」并记录结果，不得交付开发。 4. 设计系统决策在论坛审定——不允许只靠聊天做重大视觉变更。 5. 每张卡片关闭前必过「走查」，比对实现与设计。