Photo by Xavi Cabrera on Unsplash

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 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.


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 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:

  • 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:

  • 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

Define the button’s variant
Analyze the button's structure.
Example: Design the button’s variant with Figma

Design a form

Example: Design the forms with Figma

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:

  • 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.

by Alexander Petkov

For example, there are many types of mobile app navigations:

Example: Design the top navigations with Figma

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

  • 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.



I’m a UX Designer, living in Hanoi, Vietnam.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store