— Overview
Dreamscape Learn (DSL) is an immersive learning platform that merges virtual reality (VR) and interactive digital experiences to revolutionize education.
With multiple development teams working across different DSL platforms, we faced challenges in maintaining a cohesive user experience and streamlining collaboration between designers and engineers.
To support scalable growth, I led the foundation, documentation, and rollout of a centralized DSL Design System, ensuring cohesive UI patterns, efficient collaboration, and reusable components tailored to internal tooling needs.
Team
Michelle Torres – Senior Immersive Designer
Myself – UX Designer
Dev Team
— The Problem: A Fragmented Inefficient Workflow
As our projects at DSL scaled, I noticed a growing challenge: the absence of a cohesive structure within our design system.
Multiple DSL projects used ad hoc components, causing:
One-off Components without shared guidelines
Lack of a Single Source of Truth
Scalability Issues
Duplicate Work
Slow Design-to-Development Handoff
— Business Challenge: Why This Needed to Be Fixed
Beyond the immediate pain points, the bigger issue was scalability.
Without a standardized design system, the ability to launch new features quickly and maintain a seamless user experience was at risk.
— Solution: Enter the Design System
Modular, scalable Figma components
A library of predefined, flexible components that adapt to different use cases.
Developer-Ready Code
Components mapped to code-based counterparts in Storybook, ensuring a seamless transition from design to development.
Comprehensive Documentation
Detailed annotated guidelines on usage, accessibility, and customization for every component.
Scalability & Responsiveness
A system built to evolve with the product, ensuring adaptability for future growth.
— Behind the scenes : How I Achieved a Scalable and Unified Design System
Laying the Foundation
Before jumping into building DSL, I needed to understand the gaps in our current workflow, learn from industry best practices, and define the key requirements for a scalable, developer-friendly design system.
Internal Research: What Wasn’t Working?
To build a system that teams would actually use, I first needed to identify what wasn’t working.
First. I reviewed 100+ screens across DSL Admin, Booking, and Affiliate tools, identifying pattern overlaps, inconsistencies, and redundant components.
I collaborated with 5 cross-functional members (PMs, Devs, QA, Designers) to gather pain points, key flows, and requirements for the focus areas.
Through interviews with 10+ designers, engineers, and PMs, I identified key pain points:
Lack of Documentation → Devs struggled to implement designs correctly.
Scalability Issues → Existing components didn’t support variations.
Inconsistent Naming → Caused confusion across teams.
Competitive Benchmarking
Starting from scratch with a design system was challenging, and structuring components felt overwhelming. While I looked to Atlassian, Apple, and Google for inspiration, their extensive systems weren’t a perfect fit for DSL.
Best Practices and Accessibility
The turning point came when I adopted Atomic Design principles, breaking components into atoms, molecules, and organisms. This approach brought clarity, making organization, scalability, and collaboration with developers much more efficient.
Through formal and informal research, I identified accessibility gaps early, reducing biases and ensuring DSL was inclusive, adaptable, and usable for all.
— Component Framework
Building DSL from the Ground Up
The turning point came when I adopted Atomic Design principles, breaking components into atoms, molecules, and organisms. This approach brought clarity, making organization, scalability, and collaboration with developers much more efficient.
The turning point came when I adopted Atomic Design principles, breaking components into atoms, molecules, and organisms. This approach brought clarity, making organization, scalability, and collaboration with developers much more efficient.
Phase 1: Establishing Design Foundations
I began by defining the visual language of the system.
These foundational tokens ensured consistency across all components and laid the groundwork for responsive design and accessibility compliance.
Phase 2: Building Reusable Components
I combined foundational elements into scalable, flexible components like buttons, form fields, and interactive elements.
Phase 3: Creating Modular UI Patterns
Designed 35+ atomic & compound components.
In this phase, I combined atomic components into scalable UI patterns.
These patterns were designed to be dropped into different DSL tools with minimal customization, speeding up delivery while maintaining visual consistency.
— Documentation and Developer Handoff: Bridging the Gap
I chose Coda as our primary documentation hub. It serves as the single source of truth for all DSL Design System components, guidelines, and best practices.
To ensure seamless implementation, I focused on a documentation-first approach, making it easy for designers, developers, and stakeholders to access, understand, and apply the system.
What’s Inside the DSL Design System Documentation?
Figma Annotations: Bringing Context to Designs
I embedded detailed annotations in Figma to provide real-time design context for developers.
Coda as a Developer-Friendly Reference
Figma provides visual guidance, but Coda offers in-depth implementation support. Each component in Figma links directly to its Coda documentation.
Storybook for Live UI Previews
For developers, seeing components in action speeds up implementation. I integrated Storybook.
Testing & QA
I also included usage + QA checklist templates to reduce friction during dev implementation.
Result
Design QA bug rate dropped by ~40% within 3 sprints post-adoption
— Impact: Transforming Workflow and Efficiency
Measurable Outcomes
90% component reusability across DSL portals
30% faster design → dev handoff
40% drop in visual QA bugs
Improved dev-design trust and reduced UI debt
Challenges and Lessons Learned
Defining What to Include in the System
Challenge: The scope kept expanding as different teams wanted everything standardized.
Structuring Components for Maximum Reusability
Challenge: Some components were too rigid, making customization difficult.
Managing Variants Without Overcomplicating
Challenge: Too many variants led to complexity and maintenance issues.
— Further Steps
