IBM Carbon to AEM Application

Case Study: Carbon-to-AEM Builder
Bridging the Gap from Design Tokens to Production Code

The Challenge: The Design-to-Development Chasm
IBM’s Carbon Design System is a world-class framework, and designers heavily utilize it within Figma to create high-fidelity mockups. However, a significant bottleneck existed in the transition to Adobe Experience Manager (AEM).

Manual Reconstruction: Developers had to manually recreate Figma designs in AEM, translating visual properties into HTL (HTML Template Language), JCR (Java Content Repository) nodes, and CSS.

Inconsistency: Minor discrepancies in spacing, color tokens, and accessibility roles frequently slipped through during manual coding.

Velocity: The time-to-market for a single page template often spanned weeks due to the repetitive nature of component mapping.

The Process: AI-Augmented Engineering
The project utilized Gemini AI Studio as the core thought partner to move from concept to a functional design-to-code tool.

Heuristic Evaluation: Before coding, the system was evaluated against Nielsen’s 10 Usability Heuristics . Gemini was used to simulate user personas (Designers vs. Developers) to identify friction points:

Consistency and Standards: The builder was locked to the Carbon v11 library to prevent "off-system" design choices.

Flexibility and Efficiency of Use: A "Figma-first" UI was adopted so designers didn't have to learn AEM’s complex backend structure to be productive. Gemini Pro was also embedded so the designer could use AI in the tool to create components, pages or images.

AI-Assisted Prototyping: Using the Carbon-to-AEM PRD, Gemini AI Studio generated the initial React application structure. By feeding the AI the TypeScript interfaces for component mapping, the team rapidly prototyped:

1. A Drag-and-Drop Canvas that understands Carbon grid logic.
2. A Dynamic Property Panel that updates based on selected components (e.g., switching a button from 'Primary' to 'Ghost').

Evidence-Based Design: Design decisions were driven by technical constraints of the AEM architecture. The tool was built to ensure that every visual change on the canvas corresponded to a valid JCR XML property. This "Evidence-Based" approach meant that if a layout wasn't possible in AEM, the builder wouldn't allow it on the canvas.

The Solution: Carbon-to-AEM Builder. The final application is a web-based IDE that acts as a "Living Component Library."

Key Features: Pixel-Perfect Canvas, A workspace that renders `@carbon/react` components in real-time. Automated AEM Package Generation: With one click, the system compiles the canvas JSON into a `.zip` package containing: HTL Templates: Clean, semantic Sightly code. Dialog XML: Fully authored `_cq_dialog` files for AEM authors. Accessibility Labels: Auto-populated ARIA roles based on Carbon’s spec. Property Panel: A Figma-inspired sidebar for editing AEM-specific properties without touching code.

Results & Impact

90% Reduction in Developer Handover: Components no longer need manual "re-coding" for the AEM environment.

Total Compliance: 100% adherence to Carbon Design System tokens and AEM coding standards.

Democratized Development: Designers can now generate valid AEM component structures, allowing developers to focus on complex backend logic rather than CSS styling.