在我使用设计系统的经验中，我发现我必须牺牲自己的作品集才能做好它。与许多其他设计工作不同，在其他设计工作中，展示 Dribbble 级的界面和设计相对容易，但我担心系统比那要复杂得多。
你可以把东西做得漂亮，但设计系统团队做得最好的工作往往并不漂亮。事实上，很多最好的工作甚至都没有被看到。
例如，大多数时候我会与团队中的其他人配对，帮助他们了解我们的系统是如何工作的；从 CSS 架构、字体堆栈、UI 工具包到组件如何被操作以解决特定问题，以及介于两者之间的事情。我尽我所能帮助其他设计师了解什么难以构建，什么容易构建，以及何时根据技术或其他设计约束更改他们的设计。
此外，还有许多艰苦而勤奋的工作投入到对系统没有任何可见影响的项目中。上周，我注意到我们的复选框有一个奇怪的东西。我们的 Checkbox React 组件会输出这样的 HTML
<div class="checkbox">
<label for="ch-1">
<input id="ch-1" type="checkbox" class="checkbox" />
</label>
</div>我们需要用一个 <div> 来包装复选框以用于样式，并且从快速浏览来看，这个标记没有问题。但是，<div> 和 <input> 都有一个 .checkbox 类，并且 CSS 文件中有一些混乱的样式，这些样式首先设置了 <div> 的样式，然后撤销了这些样式以修复 <input> 本身。
解决这个问题很简单：我们只需要确保类名是特定的，这样我们就可以安全地重构任何混乱的 CSS
<div class="checkbox-wrapper">
<label for="ch-1">
<input id="ch-1" type="checkbox" class="checkbox" />
</label>
</div>问题是，这项工作花了不止一周的时间才发布，因为我们必须重构应用程序中大量的复选框，使其以相同的方式运行，并确保它们都使用相同的组件。这些复选框是现在明显更好、更不容易混淆的事情之一，但很难在作品集中让它看起来很性感。如果我想写关于我的工作或向其他人展示它，我不能简单地将它们放到一个大型 iPhone 模拟器中并将其作为精美作品集文章的一部分进行旋转。
再举一个例子：我花了一整天时间对我们的插图进行审核，以帮助我们的团队了解我们在应用程序中如何使用它们。我打开了 Figma 并截取了几十张屏幕截图
很难为这项工作邀功，因为主要的负担是调解讨论和帮助团队进行计划。这是一项重要的工作！但我感觉很难证明这项工作的价值，也很难在一个大型组织中展示这项工作的影响。“现在事情不那么混乱了，”这并不是一项伟大的成就——但它确实应该是。 **这些无聊的、有条理的改变对于良好的设计系统来说至关重要。**
另外……将“我写了文档”放在作品集中的感觉很奇怪，就像说“我与设计师和工程师配对合作了三年”一样。这当然不如你设计的一个很酷的界面的大而光滑的 JPEG 那么令人满意。我不确定其他地方是不是这样，但我做的工作只有大约 10% 是视觉上的，值得炫耀。
我的意思是，像这样构建新的组件，比如我之前设计过的 RadioCard，是极其罕见的，只占我所做的有用工作的很小一部分。
查看 Pen
Gusto App – RadioCard 原型 由 Robin Rendle (@robinrendle)
在 CodePen 上。
我很想看看你是如何处理这个问题的。你是如何展示你的前端和设计系统工作的？你是如何使它在你的组织中变得可见且有价值的？请在评论中告诉我！
稍微有点跑题，但为什么不直接在你的样式表中使用 div.checkbox 和 input.checkbox 选择器来选择正确的元素，而不需要更改你的 HTML？尤其是在你不得不回去更新 CSS 的情况下。
好点。也许另一种方法对于系统来说更可靠？
因为你提高了特异性：1 个类很容易覆盖，标签加上一个类更难。
而且，如果你有一天出于某种原因将你的
<div>变成<span>，你将有更多东西需要更改。多年来，我所见过的最佳实践倾向于将 HTML 标签和样式解耦，因此标签用于 HTML 标记，构建文档，而类用于应用样式。
我的策略始终是尽可能少地触碰东西，以获得你想要的结果。尽量不要碰它们。
喜欢这篇文章。IMO，设计系统的真正价值主张是解决大规模问题（而在大型组织中，这更多的是组织挑战，而不是技术挑战）。有条理且可预测的路径是前进的道路！
几乎所有关于作品集构建器上的展示型“垃圾桶”网站几乎都不像企业应用程序开发。
录制你自己的视频/屏幕截图，介绍你的流程。
这需要一些练习，但我对它在新的项目周围产生的积极反应感到很欣慰。事实上，我刻意不制作作品集，而是针对每个新项目定制我的视频，将其与客户联系起来，以及可能适合他们想要聘用我的项目的良好方法。
在内部也可以这样做。一旦你擅长它，制作这些视频就不需要很长时间，而且你可以在一个简短的视频中解释你为什么要以这种方式处理事情，并在发生重大变化时重新制作它们。
文档往往不会被阅读/审查。仅仅展示“漂亮的东西”确实会贬低你正确指出的所有辛苦工作，而这些工作实际上是维护此类系统和方法的核心。
我目前正在构建我的作品集。我大部分的工作都是不可见的：计划、协调、沟通、讨论、分析等。我决定将这些项目更多地构建为案例研究。我尝试将文本减少到每个视觉元素一句话。视觉元素将是与步骤相关的图表，或结果。最后，我会添加一到两张结果的图像。
单个项目页面的结构将是
1) 标题，
2) 一到两个词描述我在项目中的角色（例如研究或项目协调），
3) 简短的项目描述，
4) 简短的段落，总结项目执行情况、挑战，解释我在项目中的角色，并感谢团队的其他部分，
5) 步骤的可视化（项目特定的方法，解决挑战的方案），最后
6) 项目的可见结果。
整个结构基于讲故事。我认为，认识到一些访问者可能不会阅读除了项目标题和相关关键字之外的任何文本（参见 2）也很重要，这意味着视觉元素（以特定的顺序）在一定程度上应该是自解释的。这种方法的另一个含义是，单个项目页面可能需要略微不同的布局，因为内容的复杂性需要一个超越简单图片库的页面布局——遵循讲故事的想法，视觉元素可能具有不同的尺寸，并以支持理解的方式进行排列。
作为一个招聘职位的设计经理，我更重视这种工作，而不是一堆闪闪发光的 JPG 图像，老实说。
嗨，Robin
我们使用更改日志。它将有助于维护代码库，并显示提交或合并触及的所有更改。
嗨，大家好
我非常喜欢你在文章中解释的那种工作。我是一名前端开发人员，我创建 HTML 和 CSS 布局，我没有做设计部分，有时很难让设计师和程序员理解有条理地构建事物以及用组件思维构建事物的重要性。
我和我的团队成员是负责创建 HTML+CSS 组件、构建设计系统和文档，以及与 40 多名程序员和 3 名设计师“斗争”，以便他们用这些组件创建网站所需的大量页面的人。
我喜欢它，但有时会让人筋疲力尽，令人沮丧，我认为我们的工作没有得到很好的重视 ;)))
感谢你的文章！我现在也正在与同样的问题作斗争。
我不确定该如何解决这个问题，但我正在研究讲述这个故事的最佳方式。
我想我会回来分享和学习。
我很喜欢这篇文章，因为我正在考虑将类似的 DS 案例添加到我的作品集中。你们知道 DS 案例的好例子吗？