管理设计系统的技巧
成功的设计系统需要成为组织DNA的一部分,帮助你的团队提供更一致的用户体验,在设计和开发之间架起桥梁,并在不暴露你的组织结构图的情况下帮助你改进设计过程。
设计系统使产品团队能够通过使设计可重复使用来更快地创建产品。但通常情况下,尽管每个人都有最好的意图,但产品团队为制作周到的设计系统所付出的努力总会落空。
如今,解释什么是设计系统以及如何创建设计系统的文章并不少见。然而,对于如何管理设计系统,仍然缺乏切实可行的建议。
让我们填补这个空白。在本文中,我将讨论你可以采取哪些措施以便在设计系统中设置你的组织, 从而取得长期成功。
1.鼓励采用你的设计系统
比建立设计系统更重要的是鼓励每个人都使用它。设计系统为组织设定了新的方向,组织是否接受这个方向将在很大程度上取决于人们对变化的反应。根据公司的规模,鼓励人们采用单一的设计系统可能是一项艰巨的任务。只有当他们发现这种系统有价值时,才会乐意采用该系统。
以下是你需要做的事情,以使你的组织遵循你使用设计系统建立的方向。
创建愿景声明
我们将要达到什么程度?我们想要实现什么?我们为什么要实现这一目标?这些是你需要回答的基本问题,以便建立一个共同的愿景。
愿景声明定义了你的团队、产品或公司正在尝试实现的目标是什么,更重要的是,为什么。愿景声明将成为你的北极星,它将团结团队并引领团队走向一个共同的目的地。
你可以用来创建你的愿景声明的一个简单的技术就是描述你的产品或组织在五年内应该是什么样子的。通过这样做,你将定义目标条件。
愿景声明是对“我们将要达到什么程度”这个问题的回答建立指导性设计原则
你如何定义好的设计?你怎么知道什么时候有东西准备发布?在评估设计质量时,设计师通常依赖于他们自己的一套标准。但随着团队的发展,采用这种方法会在产品设计过程中带来很多混乱,因为每个设计师都会有自己的主观理想。这就是设计原则可以挽救这一点的地方。
设计原则是产品团队的标准,并帮助他们衡量自己的工作。它们用明确的标准取代主观理想,帮助团队成员做出以用户为中心的设计决策。但是,在许多情况下,让人们遵循指导方针并不难,难的是让人们就指导方针达成一致意见。这就是为什么不仅要建立设计的基础原则,而且要让参与产品创作的人对这些原则做出承诺。
在处理设计原则时,需要记住以下几点:
- 设计原则应反映产品的性质。例如,当谈到汽车的人机界面设计时,最重要的设计原则应该是“安全第一”。每个设计决策都应该以安全性为衡量标准,目标是保证驾驶员和乘客的安全。
- 练习公开讨论。如果一个组织有许多设计团队,那么让他们参与讨论是至关重要的。通过获取他们对设计原则的反馈,你可以根据用户的需要调整这些原则。
- 设计原则听起来不应该像规则。产品创作者不应感到受限制或克制。让每个人在工作时都感到舒适是很重要的。
让利益相关者买账
如果决定资金的人不买账,设计系统将不会起飞。你需要得到高管的支持才能让系统获得资金支持。
撰写一份有明确提案的策划书,并将其提交给关键的决策者。你的目标是表明系统解决了实际问题。确定关键的痛点,人们花费大量时间(尤其是日常操作) 的领域,并制作一个演示文稿(或一系列演示文稿)以展示设计系统如何节省时间。
快速提示:以故事的形式包装你的演示文稿。通过讲述成功案例,你将有更好的机会吸引利益相关者。
推广你的设计系统
你可以创建世界上最好的设计系统,但如果你不在组织中积极推广它,那么整个工作将会受到很大影响。这就是为什么,从你的系统的第一个版本开始,你就需要努力促进其被采用并创建一个支持者社区。
传播设计系统。创建一个由资深设计师领导的志愿者小组,他们将推销和销售有关你的设计系统的想法。推广人员应参加各种活动,如研讨会和网络研讨会。所有这些活动的目标应该是提高对该系统存在的认识,并教育人们如何使用它。
通过沙盒环境显示价值
众所周知,人们看到价值的最佳方式就是体验它。因此,创建一个沙盒环境,允许产品团队成员使用你的设计系统快速构建应用程序原型。使用Adobe XD,可以轻松地创建一个环境,让人们可以尝试自己的想法。实际上,这是一个两步走的过程。
首先,你需要教人们如何使用XD构建东西。XD团队准备了系列教程,让人们熟悉Adobe XD的基础知识。
其次,你需要为你的设计系统奠定坚实的基础。同样,你不需要从头开始。Ole Fredrik Lie专门为设计系统制作了一个UI套件:Semantic UI Kit(下载ZIP文件)。该套件包括开始大规模设计所需的所有基本组件,如按钮,输入框,搜索,选项卡等。
Semantic UI Kit2.建立沟通文化
每个团队成员都应定期使用设计系统。通过这样做,团队成员将学会系统地解决问题,而不是单独解决问题。沟通在这个过程中发挥着关键作用。在此过程的早期就开始创建沟通文化,将增加采用设计系统的可能性。
共享语言
语言是协作的基础。设计语言需要在参与产品创建的人员之间共享。共享语言允许团队成员在为新组件和界面元素命名时以及在引用对话中的现有组件时遵循相同的方法。
传达更改
一旦设计系统被用于产品设计,将更改和更新传达给整个组织至关重要。定期发送更新, 并使用更改日志。日志应告诉用户在新版本中引入了哪些更改,以及升级将如何影响他们的工作。
Salesforce’s Lightning Design System的发布说明用于获取更新的开放渠道
将沟通渠道融入团队的日常工作流程。这将有助于维持设计系统的用户和制造商的参与。
从简单开始。为更新创建触发器,每当有人将更新推送到设计系统时,向你的团队协作工具发送通知,并向团队宣布已提出更改。此外,要努力通过团队协作工具来回答问题。
建立定期检查的实践
除了设计系统的制造商和用户之间的日常对话外,还需要安排定期会议,以便与制造商,用户和利益相关者一起审查设计系统。讨论哪些有效,哪些无效,哪些需要改进以及何时需要改进。这些会议将帮助你确定优先级并制定改进系统的路线图,从而更好地满足业务需求。
3.提高设计效率
减少设计元素的重复
设计元素的重复导致碎片化,而碎片化会导致不一致。识别设计元素的重复有助于团队避免团队成员从头开始并在一段时间后发现该元素的版本已经存在的情况。
正如 Brad frost(“Atomic Design”一书作者)所描述的那样,进行界面清查 Interface Inventory是了解正在使用的内容的一种流行方式。在构建实际设计系统之前,值得在界面清查上投入时间,因为通过这个过程将使你能够识别需要注意的问题区域,并帮助你了解你的团队有多少设计债务。
界面清查示例分析人们如何使用你的设计系统
与你设计的任何其他产品类似,你需要找到以下问题的答案:谁将使用你的设计系统?他们将如何使用它?进行研究以找到这些问题的答案。
如果你刚开始将设计系统整合到组织的设计过程中,请进行一系列访谈以了解人们如何使用它。通过这样做,你可以提前找出问题。尽量抽出时间进行面对面的反馈会议,因为此类会议将为你提供比远程访谈或在线调查更多的洞察力。
同时,还建议你进行用户旅程映射。用户旅程映射可帮助你更好地了解用户体验。
努力创建可重复使用的组件
许多设计系统都遇到过同样的问题:团队成员创建过于专注于单个用例的组件。结果,系统变得太不灵活,其用户(设计人员和开发人员)每次需要覆盖特定场景时都必须创建自己的组件。
一个成功的设计系统是高度可重复使用的。拿Bootstrap来说,因为它的架构可用性强,成千上万的网站都是用它作为建站基础的。
Bootstrap框架尝试开发不依赖于单个用例并且可以在多个上下文中重用的组件。要实现可重复使用和可扩展性, 组件需要满足以下条件:
- 模块化。模块化组件是独立的, 它们没有任何依赖关系。
- 可组合。可以组合组件来创建新组件。
- 可定制。可以调整和扩展组件,使其在各种环境中工作。
每次要引入新组件时,请考虑它在你设计的各种平台上的工作方式。理想情况下,你设计的每个组件都应该适用于所有平台。
引入版本控制
版本控制可以更轻松地跟踪更改。对于版本化版本,用户可以将特定版本作为依赖项引用。他们还可以控制何时以及如何处理新版本的升级。
版本控制还可以帮助你处理重大变化,即组件代码更改破坏了该组件的现有用法。
版本控制有两种类型:
-
对整个系统进行版本控制。在这里,系统中的所有内容都只属于一个版本号。作为用户,我们每次更新移动操作系统时都会处理整个系统的版本控制,当我们更新iOS时,我们会更新整个软件。对设计系统采用相同的方法意味着用户必须在更新期间更新设计系统中的所有内容。例如,如果你更改了主要字体,添加了新的辅助颜色或弃用了特定的UI元素,那么当设计系统的用户选择升级时,他们将一起获得所有这些更改。
-
按模块进行版本控制。这种类型的版本控制涉及为设计系统中的每个组件或样式都有一个版本号。与整个系统的版本控制相比,按模块进行版本控制可以提供更大的灵活性,即用户可以选择仅升级他们需要的元素。
建立清晰的治理策略
正如他们所说,变化是唯一不变的。建立清晰的治理策略对于确保你的设计系统能够适应变化至关重要。一个强大的治理策略首先要回答有关如何处理更改的一些关键问题,例如:
- 谁批准对设计系统的修改?
- 如何处理新组件的请求?
- 在设计系统中发现错误时会发生什么?
设计系统的组织对其可扩展性非常重要。在Nathan Curtis的文章“缩放设计系统的团队模型”中,描述了三种模型:
- 孤立模型。在这个模型中,“霸主”统治着设计系统。
- 集中式模型。在这个模型中,一个团队负责系统并指导其发展。
- 联邦式模式。在此模型中, 来自多个团队的几个人负责该系统。
上面的每个模型都有优点和缺点,但第一个是最脆弱的,因为它有一个内在的风险,即当一个人负责这么多时,这个人很快就会成为完成许多任务的瓶颈。正如Nathan Curtis在他的文章中提到的,霸主不会扩大规模。这就是为什么许多团队正在从孤立模型转向集中式或联邦式模型,这些模型通常更适合扩展设计系统。
在许多情况下,可以尝试组合模型。例如,Salesforce团队的模型是集中式和联邦式模型的组合楷模。虽然Salesforce的Lightning设计系统有一个核心团队,但也有一些贡献者充当了从业者的联盟。
Salesforce 使用两种模型的混合体。在严谨性和灵活性之间找到适当的平衡点
设计系统的主要目标之一是扩展创意方向。该系统应该让设计人员和开发人员在选择要遵循的方法之前可以自由地探索各种方法。
至关重要的是,该系统不会阻止设计师探索不同的风格。在设计系统这本书中,Alla Kholmatova定义了两种类型的设计系统:
- 严格的。在系统中引入新模式时,设计人员和开发人员必须遵循严格的流程。
- 宽松的。该系统用来充当框架,允许设计人员和开发人员尝试各种方法。
你必须在这两个极端之间找到适当的平衡。
跨职能协作
设计好比一项团队运动,创建设计系统也不例外。你需要的不仅仅是设计师才能创建高效的设计系统。跨职能协作的专业知识和创造力将帮助你创建最适合组织需求的系统。
产品经理、项目经理、高管和其他利益相关者拥有独特的视角, 无疑可以为工作提供更多有用的信息。
以下是你在创建和管理系统过程中需要参与的相关人员的列表:
- 前端开发。前端开发人员检查代码并重新编写代码以使其模块化。
- 后端开发。后端工程师帮助确定可能影响前端UI的架构决策。
- 内容管理。内容策略师设定了设计系统的声音和基调。
- 用户体验研究。研究人员了解用户的需求并帮助将这些需求融入系统。
- 性能测试。性能工程师可帮助你避免性能下降。
- 领导。领导者确保将愿景与整个公司保持一致。
同时,这并不意味着每个学科都应该不断参与系统的开发。跨学科探索更好。进行跨团队冲刺:创建来自不同团队成员组成的团队,让他们一起工作,探索不同的设计和开发领域。这些活动将帮助他们找到许多团队认为重要的常见问题,并提出解决方案,换句话说,设计系统的用户将根据自己的需要定制系统。
及早且经常性发布
与常规产品一样,更新的等待时间在采用设计系统时起着关键作用。实施定期的增量发布,而不是大量展示,并努力尽快将组件集成到产品中。
为实现这一目标,请为新组件,代码审查和其他过程定义明确的时间表。
测试你的设计决策
一些产品团队认为,一旦建立了设计系统,工作就完成了。不对。设计系统是一个产品,将其作为产品而非项目进行管理至关重要。设计系统需要持续的维护和改进,以满足需求。
测试设计系统和使用它的产品至关重要。当你测试设计系统时,你将确信你的设计具有坚实的基础。
如果你刚刚开始将设计系统引入你的设计过程,那么请从小处开始测试系统的基础,然后再扩展到较大的部件。找到一个试点项目,使用这种新方法重建产品的真实部分,并查看它是否适用于你的团队。
以下三种类型的测试可以帮助你:
- 功能测试。
- 视觉回归测试。可视化回归测试可帮助你捕获组件样式的意外视觉更改。
- 手动和自动可访问性测试。这可确保你的组件是可访问的。
衡量进展
评估你的设计系统在实现目标方面的效果。定义关键指标,并在每个版本中跟踪它们。
4. 投入时间在说明文档上
精心打造的设计系统是一个极好的工具。但比拥有一个伟大的工具更重要的是知道如何正确使用它。文档的作用就在于此。
撰写文档以使其清晰透明
尽量减少行话和特定术语。用简单的、人类可读的句子编写文档,以便团队中的每个人都能理解它。这个决定还可以在新员工入职时节省大量时间。
保持文档最新
如果系统的某些部分没有记录,它就不存在。如果设计系统的某些元素没有记录,则存在重复元素的风险。因此,尝试通过自动化文档使文档与你的系统代码保持同步,即文档应在组件更改时自动更新。这应该包括可视化引用和代码示例。
良好的信息可查性
确定文档中包含信息部分的优先级,并确保搜索工作正常。你选择的结构应遵循用户在浏览文档时遵循的模式。
用户应该能够自己找到要找的东西,而不必通过其他人来找到它。
将最佳实践融入文档
当最佳实践(例如可访问性,性能,人体工程学等)被融入系统时,用户可以更轻松地应用它们。
Shopify的Polaris系统总结
将系统融入设计文化需要花费大量时间; 这是一个渐进的过程。而你管理设计系统的方式在其被采用中起着至关重要的作用。成功的设计系统需要成为组织DNA的一部分,帮助你的团队产生更一致的用户体验,在设计和开发之间架起桥梁,并在不暴露你的组织结构的情况下改进你的设计流程。
英文原文:地址
原文作者:Nick Babich
原文译者:Twitter / Linkedin / 微博
以上译文仅代表原作者观点。如需转载请遵循CC版权协议正确标明出处。
image