将情境带入设计系统

设计系统中的组件并不是存在于真空中,它们存在于为真实环境中的真人服务的应用中。Brad Frost 指出,原子设计的核心部分一直是将底层组件与其所驱动的软件应用程序页面之间的点连接起来。根据我们的经验,我们已经使用设计系统的参考站点来捕获给定组件的具体应用,以帮助提供情境和达到给定组件时的额外考虑因素。本文作者Hayley Hughes将以Shopify的设计系统Polaris为实例,讲述如何将情境带入到设计系统中。

将情境带入设计系统

在过去的七年里,我曾在IBM、Airbnb和Shopify从事设计系统的工作。我花了数百小时与团队一起学习他们如何使用系统。我的工作,以及任何好的设计系统的工作,都不是制定解决方案,而是要描述一个整体的各个部分之间的关系,把事情之间零散的点联系起来,这样团队才能做出最好的决策。

我一次又一次经历这样的思维定势:跨领域、跨品牌或跨业务的团队往往认为他们的产品是独一无二的。而事实是,它们相差无几。

好比每次都要反复讲同样的话,我的建议是:“你应该和A、B、C团队谈谈,他们都在做类似的事情。”

团队都具有一个共同点,那就是情境。他们可能分享着相似的受众、环境、设备或设计任务,但却又无从所知。

为什么会这样呢?因为今天,设计系统是由我们用来构建产品的乐高积木组成的。这些颜色、组件和代码为UI带来了统一性。

将情境带入设计系统

Airbnb DLS 设计系统的UI组件


但是,这些构建模块并不是设计系统的全部。今天,我们的文档中缺少UI工具包之外的内容。这些内容不是由组件组成的,而是根据我们用户的情境来构建的。

向团队展示其系统设计决策的情境,使他们能够以更符合用户需求的方式来应用系统。这也使团队摆脱了平庸的对接服务,并由我告知他们应该与谁合作。

没有情境的世界

几年前,我打开Airbnb的UI套件,发现有些组件应用了深青绿色渐变,而其他组件则没有。当我问设计系统团队什么时候应该使用渐变时,他们告诉我:"它们是为特殊时刻准备的。"

但这个特殊时刻是对谁而言的呢?我举例问了一些问题,才发现这个决定早在几年前就已经做出了。特殊时刻的用例没有记录下来,也没有人问过为什么会有渐变的出现。我们的设计技术专家Gavin Owens把这种缺失情境的案例称为机构失忆症(Institutional Amnesia)。

当组织忘记所学内容时,就会发生机构性失忆症。当人们不反思自己的工作,不进行记录或长时间不在公司工作时,就会发生这种情况。当每个人都在坚持着由少数几个人设定的方向,却又不知该如何到达那里时,这是一个危险的陷阱。

一旦一套组件在系统中变得标准化,团队往往会不自觉地认为其背后的决策是有效的,并继续使用它们,而不是质疑它们至今是否仍然可以满足需求。

在没有情境的世界里,团队无法学习如何将系统更好地应用到他们特定的用例中。他们失去了做出正确决策的信心,从而使他们放慢了脚步。他们最终无法在整个组织范围内扩展风险很高的要求,因为无法了解做出决策的原因,更不用说挑战决策了。

情境用例

在Shopify的设计系统Polaris中,我们有一个日期选择器(Date picker),可以实现多月模式。这使得用户可以一次选择两个月。在纳税季节,企业主可能需要选择两个月以上的账单进行下载。有些账单是按季度发送的。由于账单团队在Polaris设计系统中共享这些任务的情境,因此我们可以使日期选择器更灵活地适用于特定的税务用例。

将情境带入设计系统

Shopify设计系统Polaris的Date picker日期选择器组件


在Airbnb,我们为专业房东设计了从营销邮件到统计仪表板的所有内容。我们根据我们想向房东表达的内容更改了语调。一种语调更具庆祝性,另一种语调则更值得信赖。这些具体示例说明了系统并非是一刀切的。在每种情况下都需要对它们进行解释,以便团队可以决定最适合用户的内容。

让情境可见

我们如何将情境带入设计系统呢?一种方法是将情境系统化,就像我们将产品系统化一样。

将情境带入设计系统

系统应包括产品的各个部分以及从经验中收集的情境


在Shopify,我们使用讲故事的方法将情境引入Polaris。我们与团队一起编写场景,以帮助他们将情境从脑海中释放出来,并记录在设计系统中。
想要深入的了解这种方式,请阅读由我们的零售团队创建的场景。为了收集情境资料,这个团队走访了多家商店,并采访了零售人员。他们在Polaris中的用户体验指导受到了他们所了解到的员工如何经营实体店的影响。

想象一下,走进一家嘈杂的商店,顾客排着长队。工作人员从明亮的店面中为顾客结账快速转到昏暗的后台管理库存。当他们来回走动时,读卡器和平板电脑显示器上的屏幕变得难以阅读。

这个场景让人更深地体会到在零售业工作的感受。由于商店里的照明条件差异很大,零售团队在设计系统中创建了一个高对比度的黑暗模式,以支持员工在多个设备上切换环境。

在了解了零售团队创建黑暗模式的背景后,我们的运输团队现在正在仓库中试行同样的高对比度黑暗模式,因为在仓库中,可变照明也是一个很大的挑战。

在这个例子中,情境帮助团队相互利用了彼此的工作。他们了解为什么创建设计以支持某些用例而不是其他用例。他们利用情境来诊断一个设计什么时候工作不正常,从而确保我们避免重复错误。在系统团队中,情境帮助我们确定是否应该扩展现有的设计以适用于新的用例。

在未来,我们希望突出显示场景中的变量,即用户世界中不断变化的情境将成为设计的约束。在Shopify,我们已经确定了一个变量,就是分割焦点(Split Focus)。

本地送货司机的注意力会出现分散,即他们的注意力被分割在道路和手机之间。拣货员也会出现注意力分散的情况,即他们的注意力被分割在扫描一排排沉重的箱子和将数据输入在仓库地板上移动的机器人中。

这是两种截然不同的体验,它们都有分割焦点(Split Focus),作为我们所做产品设计中的一个变量。我们的假设是,拥有共同变量的团队很可能拥有可以相互利用的见解或组件。

情境第一,系统其次

对于使用设计系统的团队来说,情境是至关重要的。如果没有情境,他们要么强行将用户的需求融入到无法扩展的组件中,要么屈服于从头开始制作一切的技术负担。这两种方法都会造成更多的孤岛,而不是协作,并加剧了机构失忆症的形成。

将情境带入设计系统

Shopify设计系统 Polaris 中的商家情境和UI屏幕


我们设计的产品总是受到用户所处世界的影响。通过首先将情境引入设计系统,然后再构建由此产生的组件,我们使团队能够更有自信地做出决策,并为用户提供更好的结果。

英文原文:https://www.designsystemsforfigma.com/blog/bringing-context-to-design-systems

原文作者:Hayley Hughes

编译作者:@设计吐司

本文由 新媒体之家 作者: 设计吐司 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
1

发表评论