KakaoStyle Unveils 'UX Builder' to Resolve SDUI Hardcoding Issues

The Zigzag team at KakaoStyle developed UX Builder to solve the 'server-side hardcoding' issues that arose after adopting SDUI (Server-Driven UI). While traditional SDUI allowed for screen changes without app deployments, the logic for screen composition—such as colors, copy, and display conditions—was hardcoded into server code, creating a bottleneck where developers had to handle all changes.

Limitations of SDUI and Hardcoding Issues

In the previous approach, color constants (e.g., #F06ADF), HTML tag assembly, and event branching logic (if statements) were directly embedded in the server code. Consequently, even minor modifications to copy or colors required writing PRs, code reviews, and deployments. A/B testing and targeting logic were also managed through code branches, making maintenance difficult. A structural vulnerability existed where changes to color values in the design system necessitated corresponding updates to the server code.

Data-Driven Screen Composition System 'UX Builder'

KakaoStyle shifted to a model that separates screen composition decisions from code, managing them via data. UX Builder is a system that allows operators to create screen versions, place modules in slots, and configure the content and display conditions (targeting, scheduling, etc.) for each module.

• Hierarchical Structure: Composed in the order of Page (app screen) -> PageRevision (version control) -> Layout (placement).
• Operator Permissions: Developers provide module tools such as 'product card carousels,' which operators combine to compose screens.
• Minimized Deployment: Changes to screen composition are achieved through data updates without code deployment, enabling flexible responses without developer intervention.