[Design System]
LINE Flex Message Component System
Managing component versioning and design-development alignment during a visual system overhaul.
Structuring Notification Components During a Design System Transition
[Context]
The team was undergoing a visual design overhaul led by a senior designer. I was responsible for reorganizing existing notification components in alignment with the updated design direction, while maintaining clarity between old and new component versions.
[Role]
Identified versioning gap
Restructured component system
Authored documentation
[Timeline]
Jun. 2025 – Jul. 2025
[Deliverables]
Figma component library
GitBook documentation
[Tools]
Figma
Gitbook
[Problem]
The team was in the middle of a significant visual design overhaul — a senior designer was leading the updated direction, and many components were being redesigned from scratch. In this context, I was asked to help organize the existing notification system.
As I worked through the files, a more fundamental issue emerged: old and new component styles were coexisting without clear version boundaries. There was no reliable way to tell which assets reflected the previous design direction and which had been updated — creating real risk that developers might implement the wrong version.
The existing workflow compounded this problem:
⠀The immediate task was to organize the notification components. The underlying problem was making sure the team — and any incoming developers — could clearly distinguish what belonged to the old system and what reflected the new direction.
[Before]
Old and new component styles coexisted in a shared folder without version labeling, consistent structure, or clear ownership. With an external development team already behind schedule, the absence of a versioning system created risk of implementing outdated designs.
[Solution]
I reorganized the notification system by establishing clear version boundaries and aligning the updated design components with their corresponding code implementation.
1. Component Standardization in Figma
Working from the senior designer's updated direction, I consolidated notification layouts into a structured component system built around five consistent zones:
Title — notification type and status label
Primary information — key details (time, date, event name)
Booking details — customer name, add-ons, assigned staff
Payment summary — total amount and payment method
Action button — primary CTA and secondary link
A three-tier spacing system (xs: 4px / md: 8px / lg: 16px) was defined and applied consistently across all components, ensuring visual coherence across notification types and making the new system visually distinguishable from the old one.
2. Mapping Design Components to Code
In GitBook, I documented each component module alongside its corresponding code structure. Each entry included:
Code snippets ready for implementation
Visual references generated from the LINE Flex Message simulator
Variations across different notification states and use cases
Organizing by Use Case
Rather than listing components in isolation, I structured the documentation around the six core notification scenarios the product needed to support:
Booking invitation — sent to customers awaiting confirmation
New booking — triggered when a reservation is made
Booking confirmed — full details after successful confirmation
Payment notification — outstanding balance with payment options
Pending checkout — unpaid sessions requiring follow-up
Booking declined / cancelled — cancellation details and next steps
Each use case links to the relevant component combinations, helping both designers and developers understand how to apply the updated system — and which version to reference.
[After]
Notification components were reorganized into a versioned, scalable system with consistent structure, defined spacing, and reusable modules mapped to both Figma components and code.
System Flow
Before - Mixed old and new styles → no version labels → developer uncertainty → risk of implementing outdated designs
After - Figma component (new version) ↔ GitBook documentation ↔ Code implementation
Impact
The system was completed and handed off at a critical transition point — when a new contractor was onboarding to take over development. Many features were still pending implementation at the time of my departure, but the structured documentation provided a clear, versioned reference for the incoming team to work from.
Consolidated 6 notification use cases into a unified component system aligned with the updated design direction
Established clear version boundaries between old and new component styles, reducing the risk of implementing outdated designs
Defined a shared spacing standard (xs / md / lg) applied consistently across all layouts
Created a single source of truth linking Figma components to code — accessible to both designers and incoming developers
[Reflection]
This project started as a discrete organizational task and expanded into a versioning and handoff problem once I understood the broader context — a design system in transition, an external team behind schedule, and no clear boundary between old and new.
The most transferable learning was recognizing that in transition periods, documentation isn't just about organization — it's about risk reduction. Without clear version markers, teams default to using whatever is most familiar, which in a design overhaul often means the outdated version.
If I were to extend this work, the next step would be establishing a formal versioning protocol and deprecation process, so that as the new system matures, old components are explicitly retired rather than left to coexist indefinitely.