如何给软件重新注入魔力？ Linear 定义了一种设计风格，也在不断重新定义自己。
Linear的上一次设计改版已经过去一年，
想写一些东西聊聊Linear
1.1 什么是 Linear？
如果你还不了解 Linear，可以先记住一句话：
它是一款为软件团队打造的项目管理工具，也是当下设计圈最具影响力的产品之一。
Linear 最大的特点藏在它的名字里——线性。这不只是个品牌名，
而是一套贯穿产品始终的设计哲学：
- 内容只往一个方向滚动
- 所有文字、图标必须严格对齐
- 按钮能少放则少，配色克制到近乎冷淡
- 一次只做一件事，一次只看一个维度
用他们自己的话说：One thing at a time, one dimension at a time.
这种「专注」的产品观，让 Linear 在一众项目管理工具中脱颖而出。但问题来了——当产品快速迭代，功能越堆越多，最初那套精致的设计还撑得住吗？
1.2 设计＆审美
Linear 的设计和审美在业内是出了名的优秀。
甚至成为了一种特定的风格——一种在大面积暗色背景下，使用渐变、模糊、动态流光、极细描边、微噪点、外发光以及庄重的无衬线字体，外加流畅克制的微动效来组织和修饰界面元素的网页设计风格。产品呈现出冷酷、专业、极简的调性，非常有质感。
1.3最初的 Linear：暗色美学的起点
2019 年，Linear 发布时就自带光环。
黑色背景、灰色 Inter 字体、一个淡紫色渐变圆形 logo——这套视觉语言一出来就让人眼前一亮。
Karri 在访谈中解释过设计初衷：
「我们的目标用户主要是软件开发工程师和设计师。他们大多喜欢暗色编程环境，所以我们基于这个习惯来设计，最大限度减少视觉疲劳。」
那个时期的 Linear 官网堪称教科书。Hero Image 上的应用图标下会出现类似电影开场的激光动效——他们一开始只想做一个点亮图标的简单动效，但考虑到是首次发布，要留下记忆点，就采用了更显著的效果。
查看官网 CSS 样式会发现：界面上的渐变背景、发光特效甚至噪点效果都是代码实现；位图用体积更小的 WebP 格式，矢量图形完全采用 SVG；大量应用了 mask-image 属性和 radial-gradient、linear-gradient 等渐变函数。
这套设计迅速在设计圈走红，「Linear 风格」开始成为一个专有名词。很多产品——包括 Arc 浏览器、Raycast、Craft——都或多或少受到了它的影响。
2.1为什么设计重构？
Linear 的产品团队几乎每天都在发小版本，每周都有重大功能更新。
从最初的 MVP 到后来，它几乎已经是一个全新的产品了。
这种增量式的构建方式，在产品层面是有益且必要的。
但它带来了一个副作用：设计开始失衡。
Linear 遇到了类似的情况。每个新功能都会给最初设计的界面增加压力，
功能不再以连贯的方式适应布局。
具体表现在几个方面：
视觉层面
| 问题 | 具体表现 |
|---|---|
| 对齐混乱 | 侧边栏的图标和文字本该对齐，结果有的歪了；标签页、顶部菜单、面板，横竖都对不齐 |
| 色彩系统失控 | 使用 HSL 色彩空间，换个主题同一个颜色看起来就不一样；蓝色强调色用太多，到处都是 |
| 可读性问题 | 浅色模式的字太淡，暗色模式的对比度又不够 |
布局层面
| 导航结构太平，所有功能平铺在一起，没有层级 |
|---|
| 顶部筛选组件堆得满满当当，操作路径长 |
| 收件箱列表间距太大，一屏显示不了几条内容 |
| 状态灯是固定位置，不管有没有标签页都在那 |
Linear团队认为虽然设计债务通常以小幅增量发生，但最好以大的规模进行重
置。因为技术上的修改并不真正可见。而产品体验是整体和视觉的。他们无法预测用户走哪条路。需要有一个重大的重置，让Linear可以向前迈进。
整体感觉就是：工具依然好用，但那种最初的精致感在慢慢流失。
2.2 全面的设计重置
起点：一个「闲下来」的 CEO
去年夏天，Karri 休完育儿假回到公司，
发现了一个意外的机会——公司大部分事情都不需要他参与了。
「公司大部分事情都不需要我参与了。这给了我一个时间窗口，可以自己开始做设计改版。
他打开 Figma，开始一个人做概念设计。
最紧迫的问题有三个：
- 产品在发展，界面得跟上
- 应用的框架和视图不够清晰
- 导航需要改进
一开始三个都研究了，但后来他把导航搁置了。原因很现实：导航问题太复杂，不只是设计问题，还要大改工程，会改变用户使用产品的方式。风险太大，范围也会扩大。
所以他决定专注改版本身，重点关注「倒 L 形」的全局框架——就是控制主视图内容的那部分。
「概念应该让人觉得是产品的自然演进，不能把产品拆得七零八落。目标可以大，但得现实，得控制风险。」
这种克制，贯穿了整个项目。
2.3色彩系统：从 HSL 到 LCH
这是整个改版中技术含量最高的部分。
HSL 的问题在于，它是按数学定义的，不是按人眼感知的。 同样 50% 的亮度值，黄色看起来就比蓝色亮。这就导致设计师需要为每个主题手动调色。
Linear 换成了 LCH 色彩空间（Lightness-Chroma-Hue）。LCH 的核心优势是感知均匀——亮度值为 50 的红色和黄色，在人眼里看起来真的差不多一样亮。
改版前后对比：
| 指标 | 改版前 | 改版后 |
|---|---|---|
| 主题定义变量数 | 98 个 | 3 个（基础色、强调色、对比度） |
| 主题生成方式 | 手动调整 | 系统自动生成 |
| 高对比度支持 | 需单独设计 | 通过对比度变量自动生成 |
此外，他们大幅减少了蓝色装饰元素的使用。方法很简单：限制颜色系统计算中蓝色的占比。 浅色模式的文字变深了，深色模式的背景对比度提高了。
2.4字体层级
以前标题和正文都用 Inter，分不出轻重。现在的方案是：
- 标题：使用
Inter Display，笔画更粗、字距更紧 - 正文：继续使用标准
Inter
层级清晰了，用户扫视页面时能更快找到重点。
2.5 像素级对齐
侧边栏、标签页、面板，所有元素都重新卡了像素对齐。间距也统一了规范。
设计师 Yann 说：
「图标、文字、按钮，横竖都得对齐。这么小的地方塞了这么多元素，对齐是个挑战。这部分改动你不会马上看出来，但用几分钟就能感觉到。」
2.6 动态布局
- 状态灯不再固定位置，有标签页时会自动调整
- 收件箱间距收紧，一屏能多显示内容，但使用 1.5 倍行高保持舒适度
- 筛选器精简，操作路径变短
2.7 三端统一
通过设计令牌（Design Tokens）和组件库，macOS、Windows、浏览器三端的视觉终于一致了。同时还保留了原生体验——比如 macOS 的窗口控制按钮还是按苹果的标准来。
3.1他们是怎么做到的？
探索：一个人做了几百个屏幕
Karri 的工作节奏是这样的：
每天设计一整套屏幕和流程。 今天可能专门设计收件箱视图，明天就去弄路线图和项目，有时候探索即将推出的新功能。过程中试了边栏、视觉风格、颜色的各种版本。
然后把屏幕链接成原型，测试能不能用。
这样做了几百个屏幕，最后收窄到几个主要方向。这时候他开始和其他设计师、公司内部的人分享，收集反馈。最后确定了主要方向，做了一些视图来展示。
概念有了。下一步是让它变成真的。
从概念到原型：「这辆概念车能做得多真实？」
设计师 Yann 加入了项目。
这时候 Karri 的概念还没完全定型，需要继续设计。他们不知道怎么把旧界面和新样式连起来，也不确定新设计能不能支持所有的应用状态和选项。
有些改动可以马上做，比如更新颜色系统。有些得晚点做，比如不同的标题样式。为了加快进度，两个人同时干不同的部分。
Yann 做原型的时候，参考示例屏幕来保持新的视觉风格。他一直问自己一个问题：
「这辆概念车能做得多真实？」
然后在测试时尽量接近它。
3.2 压力测试：在走太远之前确认方向
UI 改版项目很容易越做越大。在投入更多资源之前，他们得确认方向对不对。
所以在开始真正实施前，做了三类压力测试：
环境测试
Linear 基于 Electron，要在 macOS、Windows 和浏览器上跑。导航按钮、历史记录、标签页这些东西，在浏览器里得能拆掉。
他们测了很多种布局，从很紧凑到很宽松的都试了。Yann 经常参考苹果的标准，让应用更接近原生体验。
他还花了大量时间调边栏和标签里的对齐——图标、文字、按钮，横竖都得对齐。这么小的地方塞了这么多元素，对齐是个挑战。
「这部分改动你不会马上看出来，但用几分钟就能感觉到。」
外观测试
Linear 支持浅色和深色模式，还有自定义主题生成器。Karri 探索时主要用黑白不透明色，这帮他快速出结果，也帮 Yann 理解元素之间的关系和层级。
他们的系统依赖一组变量。Yann 和工程师 Andreas 一起，对核心变量做了打磨和迭代。
Andreas 之前重建过主题生成系统，从 HSL 换到了 LCH 色彩空间。但这个系统一直没完全推出——自定义主题还在用旧的 HSL 系统，新系统只用在一些表面上。
这次改版，新系统终于全面上线了。 不光是自定义主题，连主要的浅色和深色主题都用上了。
效果立竿见影：
对比度变量特别有用——可以自动为需要高对比度的用户生成超高对比度主题。他们继续用 LCH 生成主题，因为它最接近人眼感知，能更好地处理不同层级的表面（背景、前景、面板、对话框）。
层级测试
Linear 用一套结构化布局来支持导航和内容：额外的标题存储筛选器和显示选项，侧板显示元数据，主区域显示列表、看板、时间线、分屏、全屏等视图。
Karri 已经收集了应用的大部分视图和状态，所以 Yann 能很快跑完所有测试。他主要按视图类型来测——列表、看板、分屏这样分。
这样更容易集中精力，也能确保每个决定在所有情况下都有效。
3.3 里程碑：五个阶段，步步推进
他们把项目分成五个里程碑：
| 阶段 | 内容 |
|---|---|
| 压力测试 | 测试主要视图方向：收件箱、分组、我的问题、问题列表、项目、周期、路线图、搜索 |
| 行为定义 | 记录并定义主要组件行为：边栏、标签页、应用标题、视图标题 |
| 框架刷新 | 实现第一批改动，改进浅色/深色模式外观，使用功能开关内部测试 |
| 私人测试版 | 推出私人测试版，逐步向一定比例的工作区推送 |
| 正式发布 | 向所有工作区发布新界面 |
团队协作：雅典一周，六周收尾
Karri 说：
「最好尽快重新设计。不然会阻碍几乎每个项目，还会产生新的设计债务——新加的功能和屏幕创建后马上就需要重新设计。」
一旦有了最初方向，他们组了个小团队专门干这个：
- 设计主导：Romain、Yann
- 工程支持：Andreas、Adrien
- 全员参与：整个设计团队贡献力量
工程师 Romain 说：
「我们知道要快速行动并成功交付，需要投入时间和资源。不能当副业项目。」
他们在雅典开了个线下会，
在那处理了大部分初始工作——边栏、标签页、不同级别的标题。
工作方式很有意思：每天下午，编码部分分成两组，
每组两个工程师。设计师迭代项目的其他部分，给他们建管道。
设计师和工程师每天来回沟通。
结果是：周末前就拿到了新界面的第一个能用的版本。
那一周的成果加到功能开关里，Linear 的其他人可以开始测试新界面了。
接下来他们改收件箱：重新设计了通知，更聚焦通知类型，强调队友的头像；
简化了标题和筛选器，改善整体导航；审查了评论对齐，把按钮的外观和新主题协调起来。
继续和 Andreas 打磨新的颜色主题，增加整体对比度，恢复更中性和永恒的外观。
怎么做到的？限制颜色系统计算中蓝色的占比。
浅色模式的文字变深了，深色模式变浅了，内容对比度也提高了。
他们开始用 Inter Display 做标题，增加表现力，同时保持可读性。其他文字元素继续用标准 Inter。
整个项目花了大约六周。
3.4 内部测试：让不同团队「挑刺」
所有新功能公开发布前，他们都会自己先用，确保一切正常。
在雅典那次会后，继续打磨了大约一周。然后在内部开放了功能，邀请公司任何人试用并反馈。
从不同团队拿反馈很关键。 产品、客户成功、销售、品牌等团队，他们倾向于用应用的特定部分：
- 产品团队和销售团队经常看路线图视图
- 项目负责人经常用文档
- 客户体验团队经常在特定团队中提交问题，处理问题视图
他们在内部开发工具栏加了个开关，可以快速打开或关闭新界面。这样团队更容易对比应用的不同部分，发现问题。
反馈管理：Eat their own dog food
他们想确保所有更新都能在一个地方找到。
做法很简单：在 Linear 里创建了个专门的项目，
链接到 Slack 频道。 Slack 里关于项目更新的讨论和问题会自动同步到 Linear。
这样不会在工具或团队之间丢失任何信息。
用自己的产品来管理自己产品的改版——这大概就是「dogfooding」的最佳实践了。
4.能学到什么？
Linear 这两年的变化，本质上是从追求速度转向追求质量。
早期要活下来，快比什么都重要。但活下来之后，就得还之前欠的设计债。
新技术帮了大忙
LCH 色彩空间、设计令牌这些东西，以前做不到的现在能做了。
他们没追什么设计趋势，而是在建一套能用很久的体系。
快速迭代和精致设计不矛盾
前者是生存手段，后者是长期选择。关键是知道什么时候该从前者切到后者。
Linear 给的答案是：活下来了，就该还债了。
小团队的力量
没有无限循环的流程，没有研讨会，没有便签纸。
小团队，集中精力，快速迭代。CEO 支持，全员反馈。
六周时间，还清设计债。
关联阅读
Linear 官方资源：
色彩空间相关：
设计系统相关：
