Apply OOAD in the building design system (Part 1)
In this article, I want to explain and share my experience when building a design system with these key points:
- The designer should use the left brain to think and work as-is and with the developer.
- Why, what, and benefits of using OOAD.
- How do you apply OOAD when designing the components with Figma?
WARNING: if you are a designer who doesn’t like boring logic, let's read some of the main points and move on to part 2, which I think is more appealing 😎.
Have you ever performed a UI audit and found you’re using a few dozen similar hues of blue or permutations of the same button? Multiply this by every piece of UI in your app, and you begin to realize how inconsistent, incomplete, and difficult to maintain your design has become.
I start with a question from this article Introducing-design-systems.
Of course, the answer is we need to build a design system for the development team. Moreover, some critical problems the designer has to face such as:
- Collaborate with others to design and hand over
- Design faster, do testing more.
- The design components will be extended at some time. When should the design be maintained?
- Design Debt
- Design consistently
- Accessibility for stakeholders
How does the designer solve them?
Many designers suppose that only the designer is responsible for the Design System and deals with the problems above from the designer’s perspective and knowledge. That approach intangibly puts the designer in a difficult position, both wanting to do and not doing those jobs, regardless of having a large team.
Don’t work hard, work intelligently
Of course, we need hard work, but the right way. In this case, you are not alone. Our design team includes the designers, aka UI developers, the front-end developers, and BA members… I only focus on the design team’s primary roles in this article: the Designer and UI Developer.
You are not alone
As an experienced designer with three years of experience in game design and UX design from 2016, I realized that if I could not get people to work with me on every design step, I would have failed. As you know, the designer needs to build the design system to manage, scale quickly, after that, deliver it to the developer. Conversely, the developer wants a delivered design that can be inspected and understood quickly. He approved of the idea of reusing the designs to build a consistent and lean system.
Right vs. Left Brain
Our brain includes two hemispheres, and it takes both to function correctly — The left brain vs. the Right Brain. Sometimes our right brain knows many feelings but may not know how to handle or maintain such feelings. That is where the left brain logically thinks of a way to help retain them and solve problems.
That is no different from how the designers and developers work together, similar to how one brain works. The differences between designers and developers and their definitions are also essential to understanding how each works differently and how their differences help create a better digital product.
The designer needs an advocate from engineering.
The design challenge
It is necessary to have a methodology to build and design a uniform and scalable design system that is sustainable over time and requires the slightest effort to produce.
The designer should use the left brain to think and work with the developer.
In this article, I want to describe a little bit of the Object-Oriented Programming (OOP) method — a famous computer science method. Almost all programmers already know how to apply it when building and designing the system with Figma. Moreover, we will understand the mindset of Object-Oriented Analysis Design (OOAD) methodology.
What is Object-Oriented Analysis Design (OOAD)?
(skip if you have known this)
As a product designer, the needed documenting process includes OOA, OOD, and the prototypes (wireframe, UI flows, visual demo), then delivered to the developers. In short, describe below (source: tutorialspoint.com).
Object–Oriented Analysis (OOA) is the procedure of identifying software engineering requirements and developing software specifications in terms of a software system’s object model, which comprises of interacting objects.
Object–Oriented Design (OOD) involves implementation of the conceptual model produced during object-oriented analysis. In OOD, concepts in the analysis model, which are technology−independent, are mapped onto implementing classes, constraints are identified and interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies.
Object-oriented programming (OOP) is a programming paradigm based upon objects (having both data and methods) that aims to incorporate the advantages of modularity and reusability. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.
Principles of Object-Oriented Systems
The four object-oriented programming principles are Encapsulation & Information Hiding, Abstraction, Inheritance, Polymorphism & Dynamic Binding.
Class and Object
Class — Template to define specific instances or objects
Object— Instantiation of a class
Attributes— Describes the object
Methods (Behaviors) — specify what object can do
For more information and simple examples, reference this article:
https://www.freecodecamp.org/news/object-oriented-programming-concepts-21bb035f7260/
How OOAD affects the Design system
The purpose of the building design system is to build it consistently and make it scalable. Hence, the design requirements include two key things:
- Design consistently: Standardized components used consistently and repetitively create a more predictable and easy-to-understand application.
- Scale design: the design problems have to be solved collectively and systematically. We are against fragmented visual language, which is a common design language. The designed objects are reusable and inherited when applied, maintained, and improved.
Every design component in a Design System is an object. Thus, it also has its use cases, methods, and attributes. By the time the components’ visual or style is changed or improved. However, its use cases, methods, and attributes are invariant.
The OOAD method helps us define its relational map in the design system. And keep it lasts over time. If everyone has a common design language or the same design mindset, discussing the working mechanism and managing the design system structure is significantly shortened. The designer only focuses on how it looks and feels, and the developer only focuses on implementing it.
In part 2, I will share more details and give some examples of the building design system.
