初创公司设计系统构建：从页面到系统的渐进式重构实践

1. 从混乱到秩序一个初创公司产品设计的重构之路六个月前我打开VALK公司的Figma文件第一次感受到的不是兴奋而是扑面而来的困惑。这不是那种充满创造可能性的空白画布而是一片由代码思维主导、毫无章法的设计废墟。组件像被随意丢弃的积木散落在各处命名毫无逻辑可言。颜色是硬编码的十六进制值被复制粘贴到每一个元素上同一个蓝色在文件里出现了十几种不同的写法。更离谱的是有些界面竟然是用Sketch设计后导出成图片再直接丢进Figma里的。我能看出有人曾试图让这个产品看起来更专业但结果只是一堆互不沟通的决策拼凑起来的补丁。这就是我们的MVP——功能上能用但从设计角度看它只是“一切”的起点。在这之前我在Spacecode设计机构待了两年。那里的一切都是现成的成熟的设计系统、命名规范、栅格结构、组件层级。我是在一个已经建立好的系统里工作虽然偶尔会抱怨它限制了我的发挥但直到我来到一个完全没有系统的地方我才真正体会到拥有一个系统意味着什么。我接手的产品是一个面向机构投资者的交易管理平台充斥着复杂的表格、数据室、投资文档和财务报告。这不是一个只有五个页面的简单消费级应用而是拥有数十个流程、无数边缘案例的平台用户是投资经理和合规官——一群对精确性要求极高、绝不原谅错误的人。工程师构建的界面能“工作”按钮能点击、数据能加载、表单能提交。但这是一个从数据库视角、而非用户视角构建的界面。信息层级在代码逻辑里是通的在人的认知里却是堵的。字体大小不一致间距没有遵循任何栅格整个产品缺乏统一的视觉逻辑。2. 重构策略为什么“系统先行”是个陷阱2.1 我的第一个错误试图先造轮子再造车面对这片混乱我的第一反应是典型的“教科书式”做法停下所有功能开发先建立一个完美的设计系统。定义设计令牌、规范颜色命名、建立间距尺度、构建完整的组件库然后再去设计具体页面。我认为这是专业和正确的道路。我花了将近六周时间沉浸在构建这个“完美基础”的工作中。我在Figma里创建了精美的令牌文档撰写了详尽的命名规范建立了一套拥有语义化名称如color-primary,color-danger,color-surface的配色系统还构建了包含所有变体的按钮组件。然而六周后我几乎扔掉了大部分工作。问题在于为一个你尚未完全理解的产品预先构建系统就像在不知道要建什么房子之前就先订购了所有的门窗和砖瓦。每一个决策都是抽象的。你命名了一个“主色”但你并不知道这个颜色将在所有怎样的上下文和场景中被使用你构建了一个按钮组件但你还没遇到那些会迫使你增加第五种未曾计划的变体的边缘情况。我基于对产品的假设所构建的早期系统大部分都被证明是错误的。这个教训很深刻在没有足够真实用例支撑的情况下抽象的系统设计是脆弱且脱离实际的。2.2 真正有效的路径从页面中“生长”出系统在“系统先行”的方法失败后我彻底转变了思路。我不再考虑可复用性而是开始以近乎偏执的专注度去设计单个页面目标仅仅是让每一个屏幕都尽可能做到最好。我可能花了三天时间只打磨一个金融数据表格组件。在企业级产品中这种表格拥有无数状态空状态、加载中、已排序、已筛选、分页、错误状态、带操作的行、不带操作的行、可展开的行……我为每一个状态及其组合都做了详尽的记录和设计。就这样一个页面接一个页面地推进。两个月后模式开始自己浮现出来。我注意到我在不同页面中反复制作着仅有微小差异的相同表格组件所有页面的按钮样式逐渐趋同我在第一个页面上做出的间距决策不知不觉成了后续页面的隐形标准。设计系统不是被我“规划”出来的而是被我“发现”的。这种方法后来我知道被称为“提取而非规定”。你先设计真实的东西然后从中提取重复出现的模式将其系统化而不是在获得证据之前就预先规定模式应该是什么。对于从成熟机构出来的设计师来说这起初让人很不舒服——没有正式的组件库却要把一个组件从一个页面复制到另一个页面这感觉不专业。但对于我们当时所处的阶段从零到一需求快速演变这却是唯一正确的方法。注意这种方法的关键在于“记录”。在专注于单个页面时必须有意识地记录下每一次决策——为什么这个间距是16px而不是12px为什么这个警告色用了这个红这些记录将成为后续提取模式、形成规范时最宝贵的依据避免系统成为无源之水。3. 单人设计团队的Figma组织心法当你是一个初创公司的唯一设计师时Figma的文件组织比你想象的要重要得多。这不是为了与其他设计师协作因为根本没有而是为了与六个月后的自己高效协作。你需要能立刻理解当时的设计决策。我的Figma结构经历了三次迭代每一次都是血的教训。3.1 结构演进从混沌到清晰第一代一个巨大的文件包含所有内容。这是灾难性的千万不要这么做。文件会变得极其臃肿加载缓慢查找任何东西都像大海捞针。任何微小的修改都可能引发不可预见的连锁反应版本历史混乱不堪。第二代按产品模块划分的多个文件。这比单个大文件好但引入了新的问题组件共享。如果我在“用户管理”文件中更新了按钮组件我必须手动去“交易仪表盘”文件里进行同样的更新。这种重复劳动不仅低效而且极易导致不一致。第三代目前仍在使用的稳定结构主文件库页面文件。这是最终找到的平衡点我强烈推荐给所有单人作战或小团队的设计师。一个“主文件”这个文件是唯一真相源包含所有全局的设计令牌颜色、字体、间距、阴影等、基础组件和共享样式。N个“页面文件”每个主要的用户流程或产品页面拥有独立的Figma文件。这些文件中只使用从“主文件”链接过来的组件实例。工作流当需要更新按钮样式时我只需在“主文件”中修改一次所有“页面文件”中的按钮实例都会自动同步更新。这保证了绝对的统一性并极大提升了维护效率。3.2 命名规范为深夜赶工的未来自己铺路对于组件和样式命名我采用了一套如今我坚决捍卫的约定。这套约定初看繁琐但在组件数量膨胀后其价值无可估量。组件命名模式类别/子类别/变体/状态例如一个按钮不叫“button”而是Action/Button/Primary/DefaultAction/Button/Primary/HoverAction/Button/Secondary/Disabled一个表格行则是Data/Table/Row/Expandable这种结构化的命名结合Figma的搜索和筛选功能让你能在数十个组件中瞬间定位到所需的那一个尤其是在深夜赶工、头脑不再清醒的时候。颜色样式命名语义化与技术名分离我采用了两套命名体系语义化名称用于实际设计直接描述用途如Color/Surface/Background、Color/Text/Secondary、Color/Status/Error。设计师在使用时无需思考色值只需根据语义选择。技术名称仅存在于主令牌文档描述具体色值如Blue/500、Gray/700。这套名称主要用于与开发人员的沟通和底层维护。这种分离确保了设计稿的易读性和开发实现的准确性。设计师在界面上看到的都是“背景色”、“次要文字色”而开发在代码中引用的是--color-surface-bg和--color-text-secondary它们背后映射到同一个技术色值#1a1a1a和#666666。4. 让开发团队真正遵循设计规范说实话这比构建设计系统本身更困难。在Spacecode设计交接流程是成熟的。开发人员知道要看Figma理解标注线的含义。但在VALK的早期开发团队没有严格遵循设计规范的文化。他们构建速度很快产品迭代迅速有时会参考设计有时则会自行决定间距、颜色或交互行为。我理解这并非出于恶意而是早期初创公司的常态设计常常被视作上线前的最后一步装饰而非规划阶段的首要环节。改变这一现状的关键不是对抗而是让规范变得“无法忽视”让设计详细到“遵循设计比自己做决定更省事”。4.1 从“交付图纸”到“提供说明书”我不再只是交付一张漂亮的视觉稿。我开始为每一个组件编写极其详细的Figma注释精确的CSS值不只是“间距大一点”而是margin-top: 24px; padding: 12px 16px;。交互行为悬停、点击、禁用状态的具体表现包括颜色、尺寸、阴影的变化。动效参数对于复杂交互我不再口头描述而是用Figma的原型模式或Principle制作可交互的动效演示让开发人员能精确看到缓动函数、持续时间和轨迹。状态规则清晰定义组件在所有可能状态下的样式特别是容易忽略的“加载中”、“空数据”、“错误”等状态。4.2 前置沟通在代码编写之前融入讨论我改变了工作节奏主动提前加入技术讨论。当前端工程师即将开始构建一个新功能时我会带着相关的Figma文件参与最初的方案评审。这个时机至关重要设计在编码前展示开发者会一边看设计一边思考如何实现。设计成为了技术方案的输入之一。设计在编码后展示开发者会下意识地为已经完成的工作辩护修改成本高昂。我们的前端工程师Alex后来告诉我那些具体的Figma标注每周可能为他节省了一个小时因为他不需要猜测或来回询问细节。这是一件小事但却逐步建立了信任。当开发人员发现遵循详细的设计规范反而能减少他们的返工和沟通成本时他们就会从被动的“接收者”转变为主动的“遵循者”。5. 关于“规模”的认知误区与正确实践在构建组件库时我犯了一个经典错误试图立即创建所有可能的变体。我认为“准备万全”是高效的这样以后就不必回头更新组件了。结果是我创建了一个拥有十一个变体的按钮组件其中大部分我们从未使用过。未被使用的组件并非是中立的。它们需要维护成本。当你更新设计语言时你必须更新每一个变体包括那些无用的。当新成员查看你的系统时他们会困惑为什么有十一种按钮以及该用哪一种。复杂性即使隐藏在组件库中也会制造混乱。更好的方法是按需构建及时迭代。不要预先构建。我后来读到一位大公司设计师的话深以为然“设计系统不是一本收录所有可能词汇的字典。它是一套语法一套规则让你在需要时能正确地造出新词。” 这才是核心。你的系统应该提供组合的基础元素原子和组合规则而不是试图预制所有可能的分子。5.1 构建渐进式组件库的实操步骤从最高频组件开始按钮、输入框、下拉菜单、基础文本样式。确保它们覆盖80%的日常使用场景。采用“变体”属性充分利用Figma的变体功能。例如一个按钮组件可以拥有“类型”主按钮、次按钮、文字按钮、“状态”默认、悬停、按下、禁用、“尺寸”大、中、小等属性。通过属性组合来生成变体而不是创建无数个独立的组件。建立组件使用文档哪怕只是一个简单的Notion页面或Figma内的指引页说明每个组件的用途、何时使用、何时不使用。这对于未来团队扩张至关重要。定期回顾与重构每季度回顾一次组件库的使用情况。哪些组件从未被使用可以归档或删除。哪些新的模式出现了三次以上应该提取为新组件。哪些现有组件被滥用可能需要调整或拆分。6. 设计之外的必修课初创公司设计师的生存现实六个月后我坐在公寓里回顾这一切。设计系统现在可以运行了不完美但功能完备。字体、间距、颜色都有了统一的逻辑。组件库覆盖了我们日常使用的约70%的UI元素。但比系统本身更重要的是产品现在看起来像一个真正的产品了。视觉上有逻辑可循投资者在交易页面和资产组合仪表盘上看到的是同一种设计语言。这在功能优先的初创公司迭代中并非理所当然。如果我能给六个月前的自己一些建议那会是不要从系统开始从页面开始。让系统在重复中被你发现。文档不是官僚主义而是与未来自己以及开发伙伴的沟通。详尽的注释和规范是在为你自己节省未来的时间。一个四个月后交付的“完美”组件库远不如一个四周后交付的“足够好”的组件库。速度在早期阶段就是生命线。接受一个令人不适的事实作为初创公司的唯一设计师你将花费大量时间在非产品设计工作上——宣传PPT、营销物料、社交媒体图片。如果你深爱产品设计这会让你感觉不对。但抗拒它只会浪费本可以用于他处的精力。将这些视为塑造品牌一致性的机会利用你的设计系统来快速产出这些物料反而能提升整体品牌感知。组件库永远没有“完成”的那一刻。它应该是一个活的、不断进化的体系。但在现阶段它足够坚实能够支撑我们继续构建这才是最重要的。从一片由代码催生的混乱中我们建立起了秩序。这个过程教会我的远不止如何命名一个颜色变量而是如何在资源有限、变化恒定的环境中务实而优雅地解决问题。