Apply OOAD in the building design system with Figma (Part 2)
Following part one, this article will demonstrate how to build components in the design system by applying OOAD.
The simple rule throughout this article is the three steps design process:
Thus, you need to consider the following before designing:
- How to make the decision?
The structure of a design system - How to organize and manage?
Design with a tool (Figma) - How to use it?
Connect to design token.
I want to present my ways by using Figma for only one reason Figma has what both designers and developers need.
TL;DR
The structure of a design system
The important thing is sustainability with the following fundamental properties: Scalable, Consistent, and Accessible. We have three layers of use in a design system:
- Layer 1 — Core/Foundation: If you have already read https://designsystemchecklist.com/, you can imagine this layer is focused on describing the design token — you can learn more about design tokens in my article here. Which are designed in this class, including colour, layout*, typography*, and iconography.
- Layer 2 — Platform/Component: We aim to design a cross-platform product. However, a prominent organization will have many departments that need to be aligned with each other. For example, the front-end team has to optimize each platform’s experience, iOS and Android (maybe internal or external libraries such as Google material, iOS library, and so on). The Design system needs to be divided into three groups, which things will have in common and separately.
- Layer 3 — Application: The project files will apply the libraries in those two layers above.
Core/Foundation and Platform/Component layers must be publicly shared for layer 3 to access.
Design with Figma
Before designing, we considered the OOAD methodology when creating the component with Figma.
The object’s anatomy
We consider the building blocks of Object-oriented. The description of an object includes the following:
- Classes: classify the objects with the same structure into a group (make object’s variants).
- Objects: analyze their structure.
- Methods: its interaction when reacting, such as the methods of a button are active, inactive, hover, filled, or on load focused, loading, etc.
- Attributes: appearance to describe its appearance, such as color, typography, size, border radius, padding, and style, such as dark/light, long/short, and so on. Or by use cases such as web/mobile/tablet screen break-point, default/customized, or something like that. These attributes will be overridden when used.
See more about What an object is.
After all the decisions above, the UI designer must link the properties (defined in Foundation) and relationships, make the components, and then group them into the classes with their variants.
Design tokens
As you know, at this layer (Foundation), we have to design these tokens:
- Colour
- Layout
- Typography*: they depend on the platform (iOS, Android, web).
- Iconography
I love to use this plugin Figma Tokens to generate tokens with my JSON file and make them in Figma quickly.
The biggest challenge is that the designer has to name the tokens using a well-defined rule. I prefer to apply CTI, BEM, or ABEM for naming in Layer 2 (Platform/Component) and 3 (Application).
Design buttons
Design a form
Design an abstract object
There are two things we need to understand first when deciding to create an object (nesting):
Usage: define the use cases. When does it is used? Maybe we need to base it on the design principle described in the Design language.
Anatomy (Its structure): decompose the object to answer the questions:
- How many parts does it include?
- Where do they come from?
- Which objects must create new ones?
- Is it possible to override the available things in the design system and nest them to build this object? What are its integrity and accessibility?
Remember that we will face these problems:
1. Scalable design
We don’t know exactly when it will be changed or extended, but we can prepare for the growth in the future. If we have a small change for an object, maybe we have to update many others because the objects linked in the design system will be changed by every small change (domino effect). That’s why we should consider applying the OOAD method with its principle abstraction.
Applying abstraction means that each object should only expose a high-level mechanism for using it. This mechanism should hide internal implementation details. It should only reveal operations relevant to the other objects.
For example, there are many types of mobile app navigations:
When we analyze this object, all the variants have the same structure. Thus, we can combine all of them into one.
2. Design consistently
If a component has a good structure, it may not change over time. The designer only needs to override its attributes (See Figma help).
3. Accessibility
Every object/component in the first layer (Core/Foundation) should be public for accessibility by the following layers. In layer two (Platform/Component), some objects could be local, and we can hide them when someone explores them in the other files or in layer three (Application). See this tip. You can add a “_” or “.” before its name, and then it will hide from the component library.
Connect to design token
If you love storybook, you might use this add-on Figma design to stick the developers and designers in one place. It’s the best way to collaborate.
Key takeaway
Design framework for creating an object in the design system:
Define usages
- Where is its address in the three layers?
- When do and don’t use it?
- How do we get it and override it in design?
Analyze anatomy/structure
Focus on lean design and override their attribute to make the variants.
Link the components
Everything has to link with the design tokens and the related components.
Thanks for reading.
