Case Study
Ethereal Glass: A Design System from My Idea to Figma to Production
From wireframes to Framer Motion to Reanimated: the design story behind PrayerMap’s UI.
The journey // from a conversation to a shipped app
Idea
A call with Mom
Figma
Ethereal Glass
React Native
Production code
PrayerMap
The design came first
PrayerMap was born during a discussion I was having with my Mom in Michigan about how there has to be a way for AI to connect humans in a way that creates a positive feedback loop (the opposite of doom scrolling). So, I started playing around in Figma to see if a visual form of prayer creation and connection could make the invisible act of praying, visible.
PrayerMap's UI was not sketched in code. It was designed in Figma as a named design language, Ethereal Glass, with a full handoff package: color system, typography, glassmorphism tokens, interaction specs, and screen inventory. The code came after, and the code's job was to preserve the design.
This case study is about the part of the work that's usually invisible on a resume: the Figma file that existed before the repo, the wireframes that became production components, the animation spec that survived a platform migration, the iteration loops that happened in a dedicated sandbox before touching the real app.
Act I // November 2025
The source of truth was a Figma file.
Before a single line of production code, the entire visual language lived in Figma: the color system, typography, glassmorphism tokens, component frames, and an interactive prototype that defined the motion language. Watch the file itself.
Walking through the source-of-truth Figma file: design tokens, component frames, typography system, and the interactive prototype that defined the motion language. Every screen in the shipping app traces back to a frame in this document.
Same timing curves. Same motion language. Different platform.
Act II // Shipping now
The motion system in production.
Captured from the shipping iOS build. The animation you are watching was prototyped in Framer Motion on the React web version, then preserved through the React Native migration via a 470-line animation spec. Rendered natively in Skia and Reanimated.
Featured recording
Prayer response: memorial line animation
The 6-phase choreography, live on iOS: node pulse, quadratic Bezier draw, arrival burst, persistence shimmer, graceful fade. Captured from a production build. Same timing as the Figma prototype, rendered natively in Skia and Reanimated at 60fps.
Phase 1
Node pulse, line origin
Spring damping 15, stiffness 300
Phase 2
Quadratic Bezier draw
Control-point offset // category glow color
Phase 3
Arrival burst, persistence, fade
One-year memorial lifetime
More recordings (creation flow, living map, memorial hub) coming soon.
Figma to production, in three acts
The Ethereal Glass system shipped through three distinct phases. Each one is a stage in the same design to code translation discipline: decide the language first, prove it in a fast framework, preserve it through the platform that the product actually needs.
Nov 19, 2025
Figma: Ethereal Glass design language
The design language was named and formalized before a single line of production code. A master handoff package defined the color system, typography (Cinzel display, Inter body), glassmorphism tokens, 8 category-specific glow colors, and the interaction choreography for the living map and prayer connections.
Nov to Dec 2025
Phase 1: React + Vite web app
The Figma file became a working React web app. Wireframes and interactive prototypes translated into 11 components (EtherealMap, PrayerAnimationLayer, PrayerMarker, SunMoonIndicator, and more). Framer Motion handled the motion system. The design to code translation was 1:1 on layout and within a few ms on every key transition.
Dec 2025 to Present
Phase 2: React Native pivot
The web app shipped, but native fidelity demanded more: haptics, 60fps on the map, background audio, a watchOS target. I authored a 470-line Animation Preservation Spec mapping every Framer Motion interaction to Reanimated and Skia equivalents, then migrated the design system one component at a time. The visual language survived the platform change intact.
Four pillars of Ethereal Glass
The design language is documented across six formal handoff documents. Here is the shape of the system: what every production decision anchored to.
Color system
8 category-specific glow colors (thanksgiving, petition, lament, praise, confession, intercession, healing, unity) mapped to prayer types. Glassmorphism tokens layered over a twilight base. Every color has a defined purpose in the UI; no decoration without meaning.
Typography & hierarchy
Cinzel for headers carries the sacred weight of the app. Inter for body copy keeps it legible at watchOS sizes. Tracking, leading, and optical sizing specified per surface so the same system renders identically on a 41mm watch face and a 16 inch display.
Motion as identity
A 6-second prayer connection animation choreographed across 6 phases: node pulse, line origin, quadratic Bezier draw with control-point offset, arrival burst, persistence shimmer, and graceful fade. Spring physics (damping 15, stiffness 300). Motion is how the app breathes.
Design tokens, not style sheets
Every value (spacing, radii, elevations, easing curves, glow radii) lives as a named token, not a hardcoded literal. That token layer is what made the React Native migration viable. Changing platforms meant changing renderers, not redesigning the product.
The 470-line animation preservation spec
The hard problem in the React Native migration was not business logic, it was motion. Framer Motion and Reanimated have different mental models: one is declarative and runs on the main thread; the other is imperative shared-value plumbing that runs on the UI thread. A naive port would have shipped a different app.
So I wrote ANIMATION-SPEC.md: 470 lines documenting every animation with exact timing, easing curves, gradients, and side-by-side translation tables. Eight animation systems mapped end to end, with code snippets in both dialects.
Alongside it lives a dedicated animation lab, a second repo named prayermap-animation-lab-v2, with named experiments (prayerConnections, memorialHub) for iterating on the native front-end in isolation before touching the shipping app. That is where the 60fps target was won.
The Animation Lab // prayermap-animation-lab-v2
The place where 60fps was won.
Preserving the animation spec on paper was necessary. But a document cannot tell you whether a spring feels right at 60 frames per second on a real device. For that, you need a harness.
Experiment index
prayerConnectionsvalidated6-phase line-draw choreography against real Reanimated shared values.
memorialHubvalidatedEntrance sequence, persistence shimmer, and fade lifecycle.
prayermap-animation-lab-v2 is a standalone sandbox repo built for one purpose: iterate on native motion in isolation, without risking the shipping app. Each experiment runs on-device, profiled against the 60fps bar, before a single line moves into production.
The lab also compounds. Every future animation starts from a running sandbox with working imports, device configs, and profiling scripts already in place. The next experiment inherits the last one's infrastructure. That is the difference between starting from zero and starting from proof.
6 docs
formal design system handoff
470 lines
animation preservation spec
60fps
native motion target hit
Iteration, documented in commits
The design story also lives in git. A sample of front-end iteration commits that shipped the motion system:
10853a6// prayer animation: native bounds fit, throttled line, slower rating fadee4dd391// prayer connection animation: line draws, no rating interrupts105e327// living map feed cards, circular sidebar buttons, AR unlock6e7ac6a// migrate Animated to Reanimated
Tech Stack
Frontend
Mobile
Tooling
Want to discuss the architecture?
Get in Touch