Efficiently Building a Design System with 0.5 Person Resources

The design system was treated as a product in its own right, with the focus on making it actually used by users and developers. Rather than pushing completeness to the max in one go, the key was building an MVP quickly and improving it through short iterations.

The adoption strategy differed depending on the nature of the service. For the admin, which had many complex Table and feature-driven requirements, Ant Design (ANTD) was chosen, and tokens were extracted to apply a Custom Theme so it wouldn't clash with the existing admin's tone and manner. As a result, design work per screen was cut by up to 75%, and development work by about 87%.

On the other hand, the customer-facing service required UI/UX that matched 29CM's sensibility, which meant a structure that allowed custom styling. The existing Ruler was based on emotion (css-in-js), but runtime performance issues surfaced especially on screens with large numbers of compound components like ProductCard, and the styling approach was changed to address this.

The final choice was TailwindCSS + tailwind-variants.

• TailwindCSS: PostCSS-based compile-time style processing reduces JavaScript bundle size and runtime overhead
• tailwind-variants: prevents class conflicts, and provides a Variant API, autocomplete, and type safety
• Token-based configuration makes it easy to manage colors, spacing, fonts, breakpoints, radius, and more
• A rich ecosystem and IDE support maintain development efficiency

There was also trial and error along the way. Bugs occurred, such as overlapping close buttons in Dialog, missing underlines in Tabs, and the pointer cursor not being applied in ProductCard. Through these, the team learned that fast deployment and feedback matter more than perfect components. To address this, they set up a component-level review and QA process with Chromatic + Storybook, and opened up a Wiki and contribution system to run it like an open source project.

Managing spec changes was also a major challenge. ProductCard went through multiple changes, such as the extraBadge on the image Preview, icons in the bottom Badge group, and separate clicks for the brand name, and since AOS/IOS/FE all had to stay in sync, history management was necessary. So GitHub Projects was used to track progress and the reasons for changes on a per-component basis, reducing spec fragmentation across platforms.

The conclusion is clear: rather than building a massive system from the start, starting with the most necessary components, applying them quickly, and building a maintainable structure through automation and a collaborative setup is the most realistic solution with 0.5 person resources.