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