设计模式是当今设计中使用最为频繁的一些概念。我们都知道当你到处有一些想法时会发生什么，我们开始像鹦鹉学舌一样，并将它们应用于一切事物，从而扭曲了它们的含义。我们最终由于过于复杂的概念和许多花哨的词汇而错过了这一点。因此，在应用我所追求的东西时，我谦虚谨慎地尝试着让设计模式更加清晰：始终保持简单！
保持简单
在我的文章《理解设计系统的各个组成部分》中，我提到了具有更“中性”定义的模式：
设计模式由可重用的组件集合组成，这些组件在解决设计问题时可以通过它们各自的交互行为来定义。这些必须作为业务案例采纳并记录，并且共同构建一个一致且强大的生态系统。
正如在同一篇文章中提到的，基于此定义，我们可以定义3个关键指标以帮助发现和验证模式是什么：
- 模式是一个常见的设计问题的解决方案，总是与商业案例相联系。
- 模式本质上是可重用的，并且始终链接到设计系统的组件和其他部分。
- 一个模式必须被以文档的形式记录下来，并提供关于产品团队如何解决问题的指导方针。
矛盾的地方在于，在这种情况下，仅仅一个足够简单的定义就可能导致多种解释，并在应用模式时精挑细选。那么我们如何在保持简单的同时更好地解释它呢？我找到的解决方案是给这个定义一个更具体的格式。这将有助于我们保留其简单性，同时使设计系统团队在使用模式时达成一致理解。
将模式视为故事
我们来自工厂，非常需要相信故事才能有效合作。在科技领域，这些故事被转化为价值观和准则，定义了我们是谁以及我们如何工作。从公司价值观到系统架构，这些故事都在指导我们并赋予我们意义。现在，让我们把它应用到模式上。
模式是一个关于如何解决常见问题以及我们可以从中学到什么的故事。
就像每一个故事都有一个叙事结构。首先是人物介绍和情节发展，然后是高潮，下降动作以及最终的解决方案或结论，以及得到的经验。
叙事结构
一开始，这似乎很难与我们如何定义模式或设计系统联系起来。但是，如果我们仔细观察，可以看到一个故事如何不仅给我们一种人类喜欢的格式，而且易于消化理解。它还为我们提供了定义、组织和维护模式所需的结构。
模式的叙事结构
现在，让我们将此叙述结构应用于文档层次结构：
相同，但也不同。
故事带来的经验
就像每个故事一样，这是我们达成解决方案的部分。将模式理解为我们系统的故事可以为我们带来一些好处，在这里值得一提的关键要点是：
-
将焦点放在文档上。正如Nathan Curtis——设计系统领域最重要的声音之一——所说：“模式由许多单词组成”。将模式视为故事，将重点放在我们讲这些故事的方式上。将这一点应用到我们的设计系统中，可以将文档仓库理解为模式存在和演进的自然场所。
-
正确的格式。叙事结构为我们提供了一个很好的格式来记录和阅读模式。首先介绍要解决的问题及其影响（冲突）、系统依赖性（故事的特点）、视觉效果（高潮）和最终指导原则（下降动作和解决方案）。
-
在模式和组件之间创建了清晰的边界。将模式视为故事，根据其性质将它们置于完全不同的级别，同时保留它们与系统组件和其他元素之间的链接。这将阻止我们将模式视为“更复杂的组件”，这会导致难以使用和维护的过于复杂的模板。
-
使我们的设计系统更加清晰。一个具有良好定义的结构和基于故事的文档策略的正确组合的设计系统是一个更有用的系统。更容易被组织中的多个团队和个人阅读、理解和采纳。
像构建故事一样的构建模式为创建更多更好的故事打开了大门，不仅涉及复杂的解决方案，而且涉及系统的更简单的部分。同样，我们可以欣赏各种各样的故事，从长篇非小说类到短篇小说，同样可以应用于我们系统中的模式。对模式能够解释复杂问题的想法进行投资，使我们能够在有好故事的基础上构建一个结构良好的系统。在已经提到的好处中，它还为已经有条不紊的构建活动带来了更人性化的感觉。
免责声明：2017年，我写了一篇有关讲故事的文章，作为一个忠告提醒大家在讨论和创作故事时要谨慎。在这里，我的意图是创造更好的产品和系统。当你对讲故事感到兴奋时，一定要记住：我们的系统/产品的故事是给我们策划者写的，但由他们即我们的用户来讲述的。
作者：Carlos Yllobre
原文：https://blog.prototypr.io/patterns-the-stories-of-our-design-systems-dc5f788f33b9
本文已获得原作者授权：
网友评论