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 is Figma has what both designers and developers need.
TL;DR
The structure of a design system
The important thing is sustainable with the following fundamental properties: Scalable, Consistency, 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 include Colour, Layout*, Typography*, 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 as Google material, iOS library, so on). The Design system needs to divide into three groups which things will be 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 public to share for layer 3 can access.
Design with Figma
Before designing, we consider the OOAD methodology to create 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 are 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: its appearance to describe how does it look, such as color, typography, size, border radius, padding, and its style such as dark/light, long/short, so on. Or by use cases such as web/mobile/tablet screen break-point, default/customized, something like that. These attributes will be overridden when use.
See more What is an Object?
After all of the decisions above, the UI designer must link the properties (defined in Foundation), relationships, and make the components, 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 the designer has to name the tokens with 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 based 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?
- Is it possible to overrides the available things in the design system then nesting 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 growing in 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, maybe it will 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 at the other files or in layer three (Application). See this tip, and you can add a “_” or “.” before its name, then it will hide from the component library.
Connect to design token
If you love storybook, you might use this add-on Figma designs to stick the developers and designer in one place. It’s the best way to collaborate.
Key takeaway
Design framework for creating an object in design system:
Define usages
- Where is its address in the three layers?
- When do and don’t use it?
- How to 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.
