Project Overview
Espad is an ERP solution provider offering a suite of B2B applications that support various organizational workflows such as tender offers, supply chain management, human resources, and form building tools. Over the years, the company had acquired and developed several separate design solutions across these applications. This resulted in a fragmented ecosystem with inconsistent styles, redundant components, and disconnected user experiences.
To solve this, we proposed creating a unified design system that would replace all existing design solutions. The goal was to align more than twenty services under a single, cohesive visual language that ensures a consistent brand presence, improves usability, and simplifies collaboration between design and engineering teams. It was the most logical and sustainable response to the ongoing problems with disorganized styles and inconsistent user experiences.
Challenge
Each product team had been designing and developing UI components independently, resulting in redundant design efforts, inconsistent experiences, and increased maintenance overhead. A unified design system was needed to streamline design and development, improve collaboration, and enable faster product delivery.
My Role
After joining Espad, I was assigned to lead the design system initiative, a year into my tenure. My responsibility was to define the vision, establish the structure, and guide both design and development teams in creating a scalable, component-driven foundation for all Espad products.
Key results
Methodology
We initially started building the design system based on the Atomic Design methodology. This approach structures user interfaces into five hierarchical levels: atoms, molecules, organisms, templates, and pages.
Atoms are the smallest UI elements such as buttons, labels, and icons. Molecules combine these atoms into simple functional groups, while organisms are more complex assemblies of molecules that form significant sections of an interface. Templates and pages represent the final compositions that define layouts and content structure.
Problem
However, during the process we began to notice several limitations. The boundaries between levels were often unclear, and it became difficult to decide whether a specific component should be classified as an atom, molecule, or organism. More importantly, this structure did not always align well with the realities of how our components were built and implemented in code.
To address this, we developed our own methodology, inspired by Atomic Design but more practical and flexible. Instead of grouping components by complexity, we organized them by function, usage, and family relationships.
This functional grouping allowed us to create a more modular, scalable system that better reflected how components are actually designed, built, and reused across Espad’s applications.
Documentation
In product development, documentation is often treated as an afterthought, written only at the end of a project. However, with design systems, documentation is not a final step — it is a continuous process that must evolve alongside the system itself.
At Espad, we made documentation an integral part of our workflow. Each time a new component was designed and added to the library, documentation was created simultaneously. This approach ensured that every element of the system remained clear, consistent, and ready for use by both designers and developers.
We spent a significant amount of time discussing, reviewing, and analyzing each component to make sure the documentation contained all the information necessary for proper use. The goal was to prevent ambiguity and reduce the chance of misuse across different teams.
To address the specific needs of both audiences, we prepared two complementary types of documentation:
1. Developer Documentation
Each component was documented with all its possible states, variations, and usage examples in code. This allowed developers to understand expected behaviors and edge cases immediately, reducing the risk of implementation errors and ensuring technical consistency.
2. Designer Documentation
For designers, we prepared detailed usage guides explaining how and when to use each component. This included visual examples, spacing rules, and “do and don’t” guidelines that clarified the design intent and supported consistent application across products.
By maintaining these two layers of documentation in parallel, we created a shared language between design and development — ensuring that every new feature built on the Espad Design System followed the same principles, structure, and visual language.
What We Built
1- Scalability and Consistency: From Simple Foundations to Complex Interfaces
To make the design system flexible and future-proof, we structured it to grow from simple building blocks into complete interface compositions. This modular approach helped us keep every part of the system consistent and easy to maintain as it expanded.
We began by defining the smallest reusable elements, such as buttons, inputs, icons, and text styles. These fundamental parts served as the foundation for everything else in the system.
After establishing clear standards for these elements, we started combining them into larger interface components — items that could handle more complex interactions and layouts.
This method ensured that every new layer of the system was built upon solid, reusable foundations. As a result, the Espad Design System can scale naturally to support new products, screens, and features while maintaining a unified look and feel.
2-Interchangeability: Swapping Components Without Breaking the System
Every component in the Espad Design System was designed to be interchangeable — meaning it can be replaced or updated without affecting the overall structure or visual harmony of the interface.
To achieve this, we established strict standards for spacing, sizing, and iconography, ensuring that related components share the same proportions and visual rhythm.
We also put significant effort into designing usable placeholders for components. These placeholders made it easier for designers and developers to visualize how elements fit together even before the final versions were ready, helping maintain alignment throughout the design and development process.
This approach allows smaller or alternative versions of components to be created when needed, without introducing visual inconsistencies or layout issues. Designers and developers can exchange one element for another — for example, switching a button style or replacing an input field — while keeping the entire interface stable and cohesive.
By treating components as flexible, standardized modules, the system remains both adaptable and reliable, even as products evolve and new requirements emerge.
3-Independence and Modular Structure: Components as Building Blocks for Applications
Each component in the Espad Design System was designed to function independently, making it easy to combine, reuse, or update without depending on other parts of the interface. This modular approach turns every component into a self-contained building block that can be assembled to create complete application screens or workflows.
By structuring the system in this way, we ensured that updates or improvements made to one component do not break others. This isolation allows the design system to evolve safely while maintaining stability across all applications.
The modular structure also gives teams more flexibility. Designers can focus on composing interfaces using ready-made parts, and developers can integrate only the modules they need — keeping each product lightweight, efficient, and consistent with the rest of the Espad ecosystem.
4-Adaptability: The System Adjusts to Component Replacement
The Espad Design System was built with adaptability at its core. Every element is designed to respond smoothly to change, allowing components to be replaced, updated, or extended without disrupting the overall structure of the interface.
This adaptability ensures that as products evolve, the system evolves with them. When new components are introduced or existing ones are refined, the surrounding layout, hierarchy, and visual rhythm remain consistent.
We achieved this by defining clear dependencies, scalable spacing rules, and consistent alignment patterns across all components. These foundations allow designers and developers to make updates confidently, knowing that the system will adjust automatically and maintain visual and functional harmony.
In practice, this means the Espad Design System can grow and adapt to new products, devices, or design trends — all without requiring large-scale redesigns or technical rework.
5-Reusability: We Use What We Design
Reusability is one of the main principles behind the Espad Design System. Every component, token, and pattern was created with the goal of being used repeatedly across different products and contexts, rather than redesigned for each new project.
By reusing existing components, we reduced design and development time, improved consistency, and minimized the risk of visual or functional discrepancies between applications. This approach also helped the team focus on solving new problems instead of recreating already-tested solutions.
Our process ensured that every element added to the system had a clear purpose and potential for reuse. Once documented and implemented, these components became reliable building blocks that supported multiple products within the Espad ecosystem.
In short, we built the system once — and used it everywhere.