上周跟某团队聊原型评审对方把三个页面的设计稿拍在我面前主色蓝就出现了五种没有两个颜色值相同。评审会开了一个小时快一半时间在争论“这个蓝到底是不是我们品牌那个蓝”。原型阶段最让人心累的从来不是画得快不快而是画出来的东西和产品风格是不是同源。后来我跟他们推了一套很轻的做法在项目仓库里放一份Design.md把产品风格拆解成可执行的设计决策和设计令牌然后用这份文档反推原型。效果比预想中好原本三周才定下来的视觉方向一周内就收敛了。如果你也有“原型看着精致但一放进产品就格格不入”的困扰这篇内容应该能帮到你。用Design.md构建符合产品风格的原型设计不是什么高深理论本质上就是把“设计规范”从PPT式宣讲稿变成可以在原型里被直接引用的数据源。适合两类人看一类是单打独斗的独立开发者画原型全凭手感今天圆明天方另一类是正在搭建设计流程、但暂时没有专职设计系统维护者的中小团队。读完你至少能带走一份可以直接套用的Design.md模板以及一套让原型自动对齐品牌风格的操作方法。1. 先把问题说清楚原型为什么总是和产品风格对不上1.1 产品风格不是一句抽象描述而是可量化的决策很多团队对“产品风格”的定义是这样的高级、简约、大气。这句话放在需求文档里没问题放到原型里等于什么都没说。我做过一个类比装修房子时你不会跟施工队说“装得高级一点”而是会指定墙面乳胶漆的色号、地板的材质和规格、踢脚线的高度。产品风格同理它必须具体到某一种颜色用在哪一层、文字在什么场景用几号字、两个相邻模块之间留多少空。用Design.md思考产品风格第一件事就是把这个模糊概念转译成可量化、可复用的决策集合。比如“品牌的信任感”转译为“主色使用特定色阶的深蓝按钮圆角控制在4px卡片阴影不超过两个层级”“内容密度高”转译为“列表行高压缩到32px页面左右留白收窄到16px”。这些不再是风格形容词而是原型里每一处细节的裁决依据。1.2 传统做法为什么行不通三个断层回顾一下大部分团队的原型产出流程问题几乎都出在三个地方。第一个断层在设计稿和代码之间。设计师在工具里用颜色八位数色值开发在样式表里凭肉眼近似一个“差不多”的颜色肉眼近似在蓝色系上尤其容易跑偏某品牌蓝稍微偏青一点就不再是那个味道。第二个断层是规范文档做完即弃。很多团队不是没有设计规范而是规范以PDF或在线文档形式躺在共享盘里没有和项目迭代挂钩。规范是规范原型是原型两条平行线。过两个迭代规范版本跟不上实际设计就再也没人愿意打开。第三个断层是原型工具和真实界面脱节。工具里做出来的高保真原型组件状态、字体渲染、间距表现和真实浏览器环境总有差异评审时说“这里再鲜艳一点”实现出来又是另一回事。原型如果从一开始就不生长在真实渲染环境下后续所有验证都是带偏差的。1.3 我的解法把Design.md当成设计系统的READMEDesign.md是什么你可以把它想成一份以Markdown为载体的设计系统接口文档它同时承担三个职能写清产品风格的来源和理由记录所有设计令牌的设计值与使用边界在评审和开发联调时充当对照基准。为什么用Markdown而不是在线协作文档或专业设计工具因为我希望你把它放进代码仓库和代码一起走版本管理、一起被评审、一起更新迭代。它像工程代码里的README读得懂、改得动、有历史记录任何人都可以用编辑器打开然后提一个变更请求。这个思路的精髓是把设计规范从“装饰性文档”变成“接口约定”。设计团队改了一版按钮圆角不再需要在群里喊话全团队同步只需要修改Design.md里对应的令牌值然后由下游文件统一引用。风格由此从“某个人脑子的理解”变成“代码库里一份可追溯的配置”。2. Design.md到底该写什么从原则到令牌再到组件2.1 第一层先写清楚“为什么”再写“是什么”Design.md开头不是直接上色板而是先写设计原则。这是很多人跳过的步骤但它恰恰是后期避免争论的关键。设计原则解决的是“为什么这样设计”比如“优先保证信息可读性而不是视觉冲击力”有了这条原则后续关于“标题要不要加大加粗加阴影”的争论就自动结束——不符合原则的提案不需要讨论。实操时可以列三到五条原则每条配上一段解释和反例。反例尤其重要比如某条原则规定“交互反馈优先用状态变化而非弹窗打断”反例就是“删除操作立即弹二次确认没有给用户反悔时间”。这会约束原型阶段的表现形式让页面行为具备产品气质而不仅仅是长得好看。2.2 第二层设计令牌一个把所有风格数据化的关键步骤设计令牌是整个Design.md的引擎。它解决的问题很直接让颜色、字号、间距、圆角这些视觉变量具备身份和层级而不是散落在原型各个角落里的魔法数字。为了后续扩展和换肤方便我建议把设计令牌拆成三层。基础令牌最原始的数值比如“蓝色500#2563EB”“字号424px”“间距432px”它们只描述“有什么”。语义令牌描述“用在什么场景”比如“主按钮背景色品牌蓝600”“页面背景色灰阶50”它们建立“值”和“场景”的对应关系。组件令牌更具体的组件场景比如“卡片圆角圆角2”“导航栏高度间距5”它们描述“哪一块长什么样”。这个分层看起来多一道工序实际上值回票价。后期换主题色、加暗色模式只需要改基础令牌或语义令牌组件层自动跟着变。我见过很多团队在盘点“改版对色值影响范围”时因为只有一个扁平色板而翻遍了所有原型页面有了分层之后改动范围是一目了然的。Markdown里写令牌时我建议不要再把它当作文档表格而是当作原型文件的“配置源”。我习惯用一个代码块保存YAML格式的令牌表方便后续复制到任何构建工具里# 基础令牌 color: brand-blue-500: #2563EB brand-blue-600: #1D4ED8 brand-blue-700: #1E40AF gray-0: #FFFFFF gray-50: #F8FAFC gray-100: #F1F5F9 gray-500: #64748B gray-900: #0F172A semantic-error: #DC2626 typography: font-family-base: -apple-system, Segoe UI, Roboto, PingFang SC, Microsoft YaHei, sans-serif font-size-xs: 12px font-size-sm: 14px font-size-md: 16px font-size-lg: 20px font-size-xl: 24px line-height-base: 1.5 spacing: spacing-xs: 4px spacing-sm: 8px spacing-md: 16px spacing-lg: 24px spacing-xl: 32px radius: radius-sm: 4px radius-md: 8px radius-lg: 12px有些人会觉得用YAML写设计规范很另类但你在实际操作中会发现它比一句一句的散文描述更接近“可执行”。原型工具做不到自动读取中文描述却能直接识别这种结构化数据。2.3 第三层组件规范与页面骨架设计令牌解决了风格数据问题但要让原型稳定还需要定义组件的组合规则。组件规范在Design.md里是一张表或一段代码块描述每个组件在什么场景下使用哪一组令牌以及存在哪些状态。以按钮为例最小必要信息包括默认背景色、悬停态背景色、按下态背景色、禁用态透明度或灰度值、圆角、内边距、字体令牌。如果加上不同尺寸的按钮还要给出高度、水平内边距、字号的一组优选值。写到这里你可能会觉得太细了但这是让“产品风格”落到原型上的关键一步。原型里如果每个按钮都是临时调的尺寸和颜色风格就不可能统一。表单、卡片、数据表格、导航菜单同理。组件规范的精髓是保证相同功能的交互元素在产品的每一个角落看起来和用起来都一致。页面骨架则是组件在具体布局里的摆放规则比如内容区最大宽度、栅格列数、左右留白这些在Design.md里用一小节带图注的文本说明即可不需要画像素级线框图。2.4 一份可以直接复制的Design.md目录模板下面这个目录结构我实际用过已经跑过多个项目你可以按团队情况增删。# 项目名 Design System ## 1. 设计原则 3-5条原则解释反例 ## 2. 设计令牌 ## 2.1 基础令牌颜色 / 字体 / 间距 / 圆角 / 阴影 / 层级 ## 2.2 语义令牌主题用色 / 文本用色 / 功能用色 / 背景层级 ## 2.3 组件令牌按钮 / 表单 / 卡片 / 表格 / 导航 ## 3. 组件规范 ## 3.1 按钮体系尺寸 / 状态 / 图标搭配 ## 3.2 表单控件输入框 / 选择器 / 校验态 ## 3.3 数据展示表格 / 卡片 / 空状态 / 加载态 ## 3.4 反馈组件Toast / 弹窗 / 空操作反馈 ## 4. 页面布局 ## 4.1 栅格与断点 ## 4.2 页头 / 导航 / 内容区规则 ## 4.3 通用间距规则 ## 5. 变更记录 表格日期 / 版本 / 变更内容 / 影响范围特别注意Design.md不应当变成流水账日记也不用把每个设计细节都写进去。它是一份给原型和研发共同遵守的接口文档只记录会跨页面复用、会影响视觉一致性的决策。临时为单个页面做的特殊处理留在页面备注里就可以。3. 从Design.md到可用原型一套可复制的实操流程3.1 为什么我推荐直接在浏览器里做原型主流原型工具有很多我并不是说它们不好只是当你的目标是“让原型符合产品风格”时浏览器直接产出原型有不可替代的优势原型里的每一个颜色、字距、间距都真实地运行在CSS环境中所见即所得且和最终开发实现几乎零偏差。另外浏览器环境下你可以直接引用Design.md里的设计令牌变量从根本上杜绝手误改错色值。当然这需要你会一点HTML和CSS基础不需要精通能看懂变量、会用Flexbox布局、会写静态页面即可。如果你是完全零代码背景的设计师也不要有压力这一步可以由团队里一位开发同事配合完成而你要负责的是Design.md里的决策部分。实操项目建议选一个团队里大家都熟悉的页面比如“某企业数据看板”这种常见后台界面。用Design.md驱动这个页面的原型搭建比从头设计“未来产品”更容易暴露问题。3.2 第一步把Design.md里的令牌变成CSS变量从Design.md到原型最关键的一步是让令牌在原型里“活起来”。方法是在全局样式表里添加CSS自定义属性让每个变量名与Design.md中的语义令牌一一对应。以颜色和间距为例:root { /* 语义令牌颜色 */ --color-primary: #1D4ED8; --color-primary-hover: #1E40AF; --color-bg-page: #F8FAFC; --color-bg-card: #FFFFFF; --color-text-primary: #0F172A; --color-text-secondary: #64748B; --color-border-light: #F1F5F9; --color-error: #DC2626; /* 间距令牌 */ --space-xs: 4px; --space-sm: 8px; --space-md: 16px; --space-lg: 24px; --space-xl: 32px; /* 圆角与阴影 */ --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px; --shadow-card: 0 1px 2px rgba(15, 23, 42, 0.06), 0 1px 3px rgba(15, 23, 42, 0.1); }建立映射时有个小原则CSS变量名必须跟Design.md中的语义令牌名一致而不是跟基础令牌一致。比如Design.md里“品牌蓝600”是基础令牌而“主按钮背景色品牌蓝600”是语义令牌CSS变量应命名为--color-primary而不是--color-brand-blue-600。原因前面说过语义层在换肤和暗色模式下能起到稳定的接口作用。3.3 第二步根据Design.md的页面布局规则搭框架接下来搭页面框架。你不需要每个像素都对齐最终成品但要符合Design.md里栅格与留白的约定。以前面提到的数据看板为例我通常是这样划分的左侧导航固定宽度240px顶部栏高度64px右侧内容区采用12列栅格左右页边距24px卡片间距16px。这些数字不是随手拍的它们都能在Design.md的页面布局章节找到出处。如果Design.md还没定义那此刻就是补全文档的时机——从原型里提炼出经过验证的组合值回写到规范里。原型和规范来回“喂”数据这个循环就是Design.md能持续进化的关键。骨架层的HTML结构可以简化为这样div classlayout aside classsidebar导航区/aside div classmain header classtopbar页头区/header main classcontent div classcard统计卡片 1/div div classcard统计卡片 2/div div classcard图表区域/div /main /div /div搭配的CSS里只使用步骤3.2中定义的变量坚持“不在样式表里写任何魔法数字”。你想临时加大某块留白优先去检查是设计规范本该如此还是原型自己跑偏了。这套约束力会让你少走很多回头路。3.4 第三步按组件规范组装高价值页面框架搭好后以组件规范为字典把各类页面组装出来。以三个页面为例页面一登录页。这是品牌感最集中的页面要求在主视觉区和表单区严格使用主色和品牌辅助元素。登录按钮的常规、悬停、加载和禁用四个状态都要做出来因为状态缺失正是原型评审时最容易出现的风格漏洞。页面二数据列表页。全屏页面最能暴露组件一致性的问题。同一行中有多个操作按钮时它们的尺寸和间距是否统一表格空状态是否使用了Design.md定义的插画风格和文案语气异常状态的用色是否来自功能令牌而不是随便一个“红色”。页面三数据详情页。该页面通常由多张卡片组成是检验卡片组件规范的好地方。卡片内部间距是否统一按4的倍数叠加标题与副标题的字号关系是否符合排版层级。组装页面时我强烈建议把常用的组件块拆成可复用的局部。你可以顺手把这几个页面做成原型模板后续新页面的产出会非常快因为只要套用骨架和组件页面上一个已经符合产品风格的雏形就出现了。3.5 第四步回写闭环原型里发现的新决策要反哺Design.md这一步是被大多数人忽略但价值极高的部分。原型阶段一定会有拍板的新决策——页头多了一个筛选区原本表格里的状态文案决定升级为标签组件这些决策如果在原型里定了却没有回写到Design.md再过两周原型就再次和规范脱节。我实际操作时给自己定了个流程每周五下午花半小时把本周原型里新产生的、可复用的设计决策追加到Design.md同时把已经过时的组件规范标记为废弃并记录原因。这半小时是在给下个月的自己省下几天的时间。Design.md的运行方式是“用完即改”而不是“写完就锁死”这恰是它能长期活下去的生命力所在。4. 搭建与维护中常踩的5个坑附排查思路4.1 问题一Design.md写完了但没人真去读这是最普遍的尴尬。文档躺在仓库里并不是价值被使用才是。排查思路很简单看团队在评审原型时是打开Design.md逐项对照还是凭感觉说“有点不对”。如果是后者说明项目流程没有给文档设计“使用时机”。解决办法是把Design.md直接变成一个流程节点原型评审开始前由发起人把本次评审涉及的设计原则和组件规范列出来评审结束前扔出最后一个问题——“这版原型有没有与Design.md冲突的地方”有了这个强制动作文档才可能被真正打开。另外把Design.md放在代码仓库根目录开发同学在联调时顺手就能打开查看这比放在共享盘里更容易被触及。4.2 问题二暗色模式一开颜色乱成一团很多团队做暗色模式时直接给所有背景换深色文字换白色结果红色品牌元素在暗底上刺眼、卡片阴影几乎不可见、边框色过淡页面层次全丢了。根因往往是把基础令牌当语义令牌用了页面组件直接引用了“白色背景”“黑色文字”这种基础值没有经过语义层。排查方式是检查CSS里是否大量出现直接引用基础色值的现象正确的做法是组件全部引用--color-bg-card、--color-text-primary这类语义变量暗色模式只需要覆盖顶层变量而不动组件代码。暗色模式下阴影通常需要加深而不是减弱、避免直接用纯黑、边框色可能需要比亮色模式稍微亮一点来保持边界可见这些细节都要在Design.md里明确写进语义令牌的说明中。4.3 问题三间距越来越大页面越改越散原型改几版之后经常出现卡片内边距24px、卡片之间又是24px、与页面留白还是24px如果内部子模块再叠加margin最终视觉密度完全跑偏。这是间距叠加效应在作怪。排查时直接在浏览器里审查元素看块级组件的margin和padding分别是什么有没有两个相邻组件“外间距相加”的情况。我推荐的解决方式是卡片内由padding控制内白布局层由margin控制模块间距各自只在一个方向使用并严格使用Design.md的间距令牌不额外用“微调数值”。如果某个细节真需要多出2px的调整也该先想着这是不是设计规范本身需要修正。4.4 问题四字号按规范设置后页面反而显得粗糙字号规范不是单看字号数值行高和字重缺一不可。有些团队只定了字号结果小字号加上过大的行高文字之间像插了空行大字标题又用了过细的字重视觉撑不住。排查流程是检查原型里主要文字是否成体系。我一般建议行高在小字号场景用1.5标题场景用1.2到1.3并同步定义字重正文常规字重数据数值用中等字重页面主标题用加粗。另外中文字号不建议做得过小12px是阅读舒适度的底线如果在暗色模式或低分辨率屏上还要再下探不如去重构信息层级而不是压缩字号。4.5 问题五有人不按Design.md来怎么推都推不动这种情况我见得最多。真正原因通常不是“大家不尊重规范”而是规范没有参与最终验收。如果原型评审只看视觉效果、代码评审只查功能逻辑那规范文档自然成了空气中无约束力的存在。排查思路比较直接在原型评审、视觉验收、开发联调三个节点里都加入“规范一致性检查”这一栏并让Design.md责任人拥有对风格相关问题的否决权。只要这个职位效能是真实的成员就会逐渐把Design.md当成刚需工具而不是约束锁链。同时要坦白讲不是每一次偏离都值得纠正偶尔视觉上更优的做法应该在更新Design.md后变成新规范而不是保留私下做法。5. 给我的最后一句话用Design.md构建符合产品风格的原型设计核心并不是Markdown也不是CSS变量而是“把风格转译为数据再让数据驱动界面”的思维模式。我见过太多团队花大力气去追热门协作平台、点选式设计系统工具实际上解决问题的关键不在于工具多豪华而在于决策是否有记录、是否有唯一来源、是否被后续流程强制消费。如果让我给刚接触这套流程的团队一个最务实的建议我会说别强求一步到位。第一版Design.md哪怕只有半页纸——写清主色、字体、间距、四五个组件的状态——都足够支撑第一次原型搭建。然后让它在一次真实迭代里自然生长你很快会发现自己再也不需要用“感觉”来做视觉判断了。这就是我踩过几次坑之后最深的一点体会。
