vue 分步引导组件_拆箱设计系统组件的质量保证分步指南

vue 分步引导组件

When building or updating a component, the work seems to be very straight forward; It is only about changing the color of that button, updating the icon or increasing the margin, up to the library and done! But, in reality, a design system is more than just a library of components. Without considering a defined building process and the different inputs and outputs of the system, mistakes will happen.

在构建或更新组件时，工作似乎非常简单。 只是要更改该按钮的颜色，更新图标或增加页边距，直到库完成！ 但是，实际上，设计系统不只是组件库。 如果不考虑定义的构建过程以及系统的不同输入和输出，就会发生错误。

Depending on the size of the organization the design system serves, the number of hands interacting and contributing to the system increases too. Naturally, the same thing happens with the number of mistakes and misalignments. This is why scalability is a must, and to ensure alignment across the teams, we need to have a plan.

根据设计系统所服务的组织的规模，交互并为系统做出贡献的人员数量也会增加。 自然，错误和错位的数量也会发生同一件事。 这就是为什么必须具有可伸缩性的原因，并且为了确保团队之间的一致，我们需要制定计划。

A rules book, basic guidelines or a quality checklist is necessary to avoid design /tech debt generation. We ensure everyone follows the same rules and the same steps and with this, we can reduce the Quality Assurance backlog.

为避免产生设计/技术债务，必须使用规则手册，基本准则或质量检查表。 我们确保每个人都遵循相同的规则和步骤，并以此减少质量保证积压。

四个盒子 (The Four Boxes)

The idea is simple, imagine you receive a new camera you bought online. After 5 min of unboxing you find yourself opening more boxes than expected before getting to the product you bought. Apart from ecological considerations and how annoying this could be, there is a reason for each box to be there. The first one is to transport the article, the second one inside is to protect it and the third one is to present the product and provide us with information about it.

这个想法很简单，假设您收到了在线购买的新相机。 取消装箱5分钟后，您发现自己打开的盒子比预期的要多，然后才可以购买所购买的产品。 除了生态方面的考虑以及这可能有多烦人之外，还有理由将每个盒子都放在里面。 第一个是运输物品，第二个是内部保护物品，第三个是展示产品并向我们提供有关该物品的信息。

Now imagine that the new camera is a design system component and that each box is an action or task required we need to complete before presenting the component to our users. In order to release that component, we need to open each box. These are there to fulfill a purpose.

现在，假设新相机是设计系统组件，并且每个框都是在向用户展示组件之前我们需要完成的一项动作或任务。 为了释放该组件，我们需要打开每个框。 这些在那里实现目的。

第一个方框：库分配和系统依赖性 (First Box: Library allocation and system dependencies)

The first box is the biggest one. This step is about providing us with a sense of location for that component and a whole overview of the system. How the changes we want to apply to the part will impact the whole. During this first step, we need to make sure the component belongs to the right library and that its links and dependencies are not broken; And if they are, trace a plan to fix it before opening more boxes.

第一个盒子是最大的盒子。 此步骤旨在为我们提供该组件的位置感以及系统的整体概览。 我们要应用于零件的更改将如何影响整体。 在第一步中，我们需要确保该组件属于正确的库，并且其链接和依赖项没有中断。 如果是这样的话，请在打开更多包装盒之前跟踪计划进行修复。

Some questions to be answered here:• Is this the right library/category for this component?• Is it inheriting the right type or color token? • Are the updates breaking any other parts of the system?

这里需要回答一些问题： •这是该组件的正确库/类别吗？•是否继承了正确的类型或颜色标记 ？ •更新是否破坏了系统的其他任何部分？

第二个方框：命名约定和标签 (Second Box: Naming convention and labeling)

If the first box was purely about organizing the component. The second box is all about naming it. It seems non-important or very straight-forward at first, but by not having a well-defined naming convention and label structure we can impact negatively the findability of the component. If the primary users of our design system are having difficulties finding the component in the libraries or the dev kit, we need to revisit the naming convention.

如果第一个框纯粹是关于组织组件的。 第二个方框是关于命名的。 乍一看似乎不重要或非常简单，但是由于没有明确定义的命名约定和标签结构，我们可能会对组件的可发现性产生负面影响。 如果我们设计系统的主要用户在库或开发套件中查找组件时遇到困难，则需要重新考虑命名约定。

I talk in more detail about the importance of a shared language and a pre-defined naming convention structure in my article “Building a Design System. Start with a Map”.

在我的文章“构建设计系统”中，我更详细地讨论了共享语言和预定义的命名约定结构的重要性。 从地图开始” 。

Some questions to be answered:• Is the name of this component following a pre-defined naming convention?• Are the combination of naming and labeling ensuring the findability of the component across the different sources?

需要回答一些问题： •该组件的名称是否遵循预定义的命名约定？•命名和标签的组合是否可确保在不同来源中都可找到该组件？

第三箱：解剖，变化和状态 (Third Box: Anatomy, variations, and states)

The third box is there to present all the core information about the component. What is its purpose? How it is built? Here it is important to have a defined specs template and documentation that will help us review and update components.The documentation to guide our work here must cover information about the component we are building or in the case of a new component, the category where it should live. It also must cover the points in common across components, like supported interaction and notification states and libraries layer structure for these.

第三个框用于显示有关组件的所有核心信息。 目的是什么？ 它是如何建造的？ 这里重要的是要有一个定义的规格模板和文档，以帮助我们检查和更新组件。在此指导我们工作的文档必须涵盖有关我们正在构建的组件的信息，或者在涉及新组件时，应涵盖其类别。应该活着。 它还必须涵盖各个组件之间的共同点，例如支持的交互和通知状态以及这些组件的库层结构。

Some questions to be answered here:• Is the anatomy of this component and its variations aligned with existing components?• Are we using our tokens correctly to build or update this component?• Are we applying the supported states and are these organized in a specific order in our libraries and code?

这里要回答一些问题： •该组件的结构及其变体是否与现有组件一致？•我们是否正确地使用令牌来构建或更新此组件？•我们是否应用了受支持的状态并将这些状态组织为特定状态在我们的库和代码中订购？

第四个方框：工具特性 (Fourth Box: Tool characteristics)

This is the last of the boxes, responding more specifically to the characteristics of the design tool we use. Here we need to make sure the component behaves as it should when interacting with it within the workspace provided by our design app. Things like the resizing behavior of a layer when its containing frame is resized or the auto-layout feature are some of the tool requirements we need to review here.

这是最后一盒，对我们使用的设计工具的特征有更具体的React。 在这里，我们需要确保组件在我们的设计应用程序提供的工作空间中与之交互时表现正常。 调整包含图层的框架时调整图层大小或自动布局功能等行为是我们需要在此处查看的一些工具要求。

总结一下 (To sum up)

I like to use the analogy of the boxes because of the logic constraints this idea offers. You can’t open the second box without opening the first one. This approach allows us to think systematically when working on components or any design system element. Organizing our work following steps (or boxes) that need to be completed before moving on, helps us maintain the focus on the task while reviewing the previous step. This way it is not only easier to assign resources, plan the work and achieve alignment but we also ensure that proper quality verification is in place when working on our design system.

我喜欢使用盒子的类比，因为这种想法提供了逻辑约束。 如果不打开第一个框，则无法打开第二个框。 这种方法使我们在处理组件或任何设计系统元素时可以系统地思考。 按照继续进行之前需要完成的步骤(或框)来组织我们的工作，这有助于我们在回顾上一步的同时保持对任务的关注。 这样，不仅可以更轻松地分配资源，计划工作并达成一致，而且在设计系统上工作时，我们还可以确保适当的质量验证 。

Thank you for reading! 😊

感谢您的阅读！ 😊

翻译自: https://blog.prototypr.io/unboxing-a-design-system-component-a-step-by-step-guide-to-quality-assurance-106df86b60d6

vue 分步引导组件