In the past two weekly issues, we have introduced the differences between Components and Pattern respectively, and also one of the very important concept of Pattern — Perceptual Pattern.
For the whole Design System, Components and Pattern not only provide help for product development efficiency, consistency and Design guidance, but also shoulder another important mission:
Through them, we can express the Design principles created in the Design System and participate in the construction of products, so as to create emotional brand recognition for products.
As we mentioned earlier in the Principles section, design rule creation is as important as execution. From the perspective of goal attainment, we expect that each role involved in the product should be able to memorize these principles and “imagine” how these Perceptual patterns will appear to users. This requires us to have a controlled and extensible approach to maintaining the style system of the product, which is the Design Token we will discuss today.
What is a Design Token
In real production, this is completely cut off during development. The style code we usually see (below) is mostly motion-free, and it’s hard to imagine what it would look like to “decorate” the interface. If the product is complex, it can be a pain to iterate globally over time.
But if we encapsulate these parameters and describe them semantically, the “picture” of the interface will be much clearer. These “font-size-level03” and “border-separate-background” defined in the system are Design tokens defined from different thinking logic.
Of course, the semantic function of the text is limited, and it is only a final presentation of the Design Token. In order to truly enhance the “pictorial sense”, so that people can read and understand, we also need to establish a set of corresponding systems in the Design System, and let people have a clear memory of them.
Here, we will continue to take Salesforce’s Lightning Design System as an example to give you a detailed analysis of Design Token.
Lightning Design System Design Token
Token originally means Token, used in engineering logic for user identity and server-side authentication operations. In the Design System world, the definition of a Design Token is more like a Design variable. Proper definition of design variable names makes property parameters easier to understand and product style control easier.
Salesforce also explains their definition in the documentation, which simply says:
The Design Token is the visual Design atom in the Design system. They are a set of entities with a common naming convention that stores specific parameters of the visual design part, such as HEX color values, spacing, dimensions in pixels, and so on. Using it can help maintain a scalable, consistent visual architecture for UI development efforts.
For example, in the background color section Lightning defines (excerpt) tokens such as Notification, Badge hover and Error dark, and defines specific color values for them in the process of establishing the style system. As you develop, you will see a more semantic description.
If the overall style of the product needs to be adjusted, as long as the system is robust enough, the whole implementation process will become more efficient and safe.
Lightning defines a whole set of tokens, including the following classes of attributes:
- Background Color
- Text Color
- Border Color
- Font
- Font Size
- Opacity
- Line Height
- Spacing
- Radius
- Sizing
- Shadow
- Time
- Media Query
- Z-index
The abstract mainline logic of this set of rules is the Style attribute value of the element plus a little custom business. This is also the safest course of action, since it has been proven in the CSS syntax field for a long time and is much more stable and extensible than if you tried to do it yourself.
Let’s take two more examples and go a step further and see how each of these properties is defined and operated.
###Radius and Shadow
Typically, a lot of people do complete styling for each “card”. The usual result of this process-by-process approach is that it multiplies as the business complexity increases.
As shown in the picture below, you may only need one card at the beginning (card01). The designer wants to make some stylistic differences in a project, so card02 and 03 appear.
Then, as the cards are used in more scenarios, cards of different sizes and rounded corners appear on the right. In the end, no one could figure out how many rounded rectangles there were, or how to use them.
via: www.lightningdesignsystem.com/design-toke…
The same goes for the shadows. Lightning defines many different states for different business scenarios. For example, the shadow of focus on the button, the change of the shadow when dragging, and the shadow of the picture.
via:www.lightningdesignsystem.com/design-toke…
One problem you may notice here is that Lightning’s hierarchy definition seems to be different from what we usually do. What we often see is similar to the lower (Carbon), which increases step by step from small to large.
While Lightning is defined more according to the scene, that is, the table rounded corner, card rounded corner, button rounded corner, etc. But I’m sure they also have a set of hierarchical guides that are “hidden”.
For developers in the Salesforce ecosystem, more direct guidance is needed to determine exactly what the components will look like in a given scenario. Lightning does this precisely because of its business characteristics, so I would like to mention it again.
Each System we see may think and work differently, because its main purpose is more efficient service and business. So there are ways of thinking we can borrow, but not all of them.
Does ###Design Token only do so much?
The answer is clearly no. In the early stage of mobile terminal Design, PinDesign proposed a concept of “Design unity across multiple terminals”, and Design Token has great value in the Design unity across multiple terminals.
For the vast majority of products, we probably have to at least think about designing for the Web, iOS, and Android, which can take multiple times to add or update features.
But if you think about it from a system point of view it’s obviously not a scientific thing. As the product expands to more ends, the design becomes more resource-intensive and less controllable.
At this point, we need to ask for the Design Token again. It is not just a variable to store styles, but a set of “passwords” to “translate” between operating systems in a multi-endpoint design.
If we think of the product as a “person,” then the Design Token can be used to translate in different languages. The same is shadow, we can set the translated content (specific parameters) according to the requirements of different languages (systems).
As long as the product design framework is robust enough, the amount of design resources consumed in different systems will be significantly reduced, and the efficiency and consistency of development will be better guaranteed. More importantly, designers can pay more attention to the logic and flow design of products, which is what designers should really do.
This is part 5 of the Design System series. In the rest of the article (the paid part) I will focus on the hands-on part and talk about how to create Design tokens for your products and what to focus on during the process.
Join PinDesign to receive the full text of this issue’s theme “Design Token inDesign System” and the first three weekly issues of this series.
Design System is a new series of PinDesign Weekly, based on book notes and lessons learned within the framework of the book “Design Systems”. I hope to share my feelings and experience with you to help you read.
Click to receive a 50 yuan coupon for PinDesign membership program
Design System review:
- What is the Design System
- What are Design Principles
- What exactly are the differences between Components and Patterns
- What kind of temperament should you design for the product
