Socar Design System 2.0 Development Story Part 1: Operating as a System (Web)

The core of Socar Frame 2.0 lies in redefining it beyond a UI library into a system that also encompasses policy, integration, and operations. Design tokens, components, documentation, and integration rules were kept as a common foundation, while service-specific UI policies and screen composition were separated as each service's own responsibility, clearly defining the boundary of roles.

There were two design goals. One was to build a system, including a UI library, that could respond to change and scale. The other was to streamline the existing workflow centered on Figma.

The integration system was strengthened in two directions.

• Designer → Developer (library): Using the Figma Plugin, static assets such as icons and spacing tokens were changed so that designers could directly create PRs themselves. This reduced lead time by cutting down on the previous process of Slack handoffs, manual PRs, verification, and deployment.
• Developer (library) → Developer (service): To complement the existing Storybook-centered verification flow, Figma Code Connect was applied. It immediately shows the library code corresponding to the node selected by the designer, shortening the usage flow.

In particular, components with many states and variants, such as DatePicker, were difficult to map simply, and the difference in working methods between design and development was also significant. While the design side was accustomed to thinking centered on Figma Variants, the development side needed the flexibility of a composite component structure, so in the end the Slot concept was adopted to align the design with Code Connect.

Operations were maintained with a flow suited to a long-term project: regular meetings → UI/UX policy agreement → implementation → verification. Milestones were divided by priority, completed components were reflected in services as quickly as possible, and some were operated using a partial application → feedback → revision approach.

During the process, differences in implementation across OSes, cross-discipline agreement on slot structure and state definitions, and quality management through QC emerged as important challenges. Ultimately, it emphasizes that a design system becomes a repeatable production framework only after design methods and operational rules are agreed upon—it is not simply a bundle of components.