A design system, component library, and content architecture built to launch a comprehensive wellness platform on Shopify — and to keep scaling long after launch. Hundreds of pages across supplements, prescriptions, at-home testing, clinical consultation, and subscriptions, all built from a single source of truth.
I was brought in as a senior UX/UI design contractor as BodyHealthRx was preparing to launch an entirely new arm of their e-commerce platform — expanding from supplements into at-home diagnostic testing, compounded prescription medications, online clinical consultation, and subscription-based wellness programs — all built on Shopify, all launching under a new brand identity, and all being defined and refined at the same time. The rebrand had been underway for more than a year. For me, it started on day one: absorb context fast, operate independently, and deliver. This wasn't a simple redesign. It was months of discovery and design compressed into weeks.
The project spans three phases. Phase 1: a new website and brand for prescriptions and at-home testing to complement the existing supplements business. Phase 2, recently kicked off: a full user portal and personal wellness dashboard covering appointment scheduling, lab results, order tracking, rewards, and personalized wellness recommendations. Phase 3: the redesign and rebuild of the primary BodyHealth website. Three distinct phases, one design system, built on a foundation that was still being poured.
The BodyHealthRx site alone includes more than 100 designed pages:
The dashboard and user portal add significantly to that total — and the system was built to support all of it.
The design work I encountered when I arrived was great. There was a strong visual sensibility in place, real brand instincts, and a clear point of view. The people responsible for it cared about the work and it showed.
What was missing wasn't talent or intention — it was structure. There was no methodology connecting the good instincts to a repeatable, scalable process. Styles and variables existed, but they had been built up organically over time, applied case by case without an underlying naming convention or organizational logic. Components hadn't been systematized. The files were hard to navigate and harder to hand off. The ingredients for a great design system were already there. What they needed was someone to build the kitchen.
I typically begin any engagement with what I think of as BEM exercises — working through the block, element, and modifier relationships of a design before touching a single component. Color, spacing, typography: I build the framework for those decisions first, establishing variables and values and making sure the architecture is sound before the walls go up. From there I move into atoms and molecules without trying to solve everything at once.
I've never been a fan of traditional wireframes. They tend to be either too abstract for stakeholders to react to meaningfully or too polished to invite real feedback. Instead, I build what I've started calling handsome wireframes — layouts with real content and at least a baseline style applied, something that establishes a framework and gives everyone at the table something genuine to respond to. The goal is to get work in front of real people as quickly and efficiently as possible and to create something that enables other people's creativity rather than replacing it.
The token system I built for BodyHealthRx follows a semantic, purpose-driven naming convention throughout. Colors are named for what they do rather than what they look like — color/brand/primary, color/text/inverse, color/background/secondary — so the system communicates intent at every level. Variable collections are organized by category, with responsive modes for desktop and mobile baked in at the token level rather than patched on afterward. The V1 system used desktop and mobile modes. The V2 system expanded to mobile, tablet, and widescreen — not because every layout needs a tablet breakpoint, but because the line between screen sizes has been narrowing and classic breakpoint labels like "desktop" don't describe the range of devices people actually use. A laptop isn't a desktop, and neither is an HD TV. The extra mode gives us flexibility where information density demands it, particularly as the dashboard work deepens.
Across both systems, the token architecture includes more than 300 variables spanning color (with light and dark modes), spacing, and typography — each collection resolving responsively at every breakpoint. A good design system should be invisible infrastructure: when it's working, nobody thinks about it. They just use the components, and the components do the right thing.
Design systems get a lot of attention. Content systems rarely get the same treatment, but they should — because the two represent the same opportunity: efficiency, flexibility, and portability at scale. If your components are modular and reusable, your content needs to be modular and reusable too, or the whole thing falls apart at scale.
When product details became more concrete, a copywriter was brought on board, and components and screens began converging on templates, the timing was right to restructure the content pipeline. I reorganized the master copy document into structured product data spreadsheets for test products, Rx products, and supplement categories — organized so that large blocks of data could be imported into Figma designs quickly and efficiently rather than transcribed by hand.
The survey system got the same treatment. The platform includes roughly 10 survey paths covering different treatment types, each with its own routing logic. I mapped the entire system into a structured spreadsheet — one tab per category, plus pre-survey and summary tabs — and then created a flat data import sheet for bringing that content into design tools and templates. I laid the survey content out horizontally because that's how my brain visualizes data becoming a user experience: I needed to see the flow the way a user would move through it.
None of this is glamorous work. But it's the work that makes the glamorous work possible. When I know that a platform needs to support 100 pages and growing, I can't afford to populate designs by hand. The content pipeline has to be as systematic as the component pipeline, or one of them becomes the bottleneck.
The first system was built from experience and best practices, drawing on everything I know about atomic design, token architecture, and responsive-first thinking. The library that came out of that effort was comprehensive: alerts, badges, banners in multiple configurations, buttons across three types and three states, cards for products, lifestyle, partners, and categories, a full input system, navigation, surveys, tabs, typography components, and a motion control system for carousels and sliders. I also built a custom Resizer utility — a Figma-native tool embedded in text components to enforce consistent line lengths and eliminate widows and orphans across the layout.
The system worked well. The components were solid and the architecture was sound. But as I spent more time with the team and developed a deeper understanding of how they worked — how they thought about the relationship between brand standards and design flexibility, what they actually needed from a component library day-to-day — I began to see a better way to build it.
I've occasionally been accused of throwing the baby out with the bathwater when I propose starting something over. I've never really seen it that way. We evolve. User needs evolve. Best practices evolve. Business needs evolve. The tools we use to do the work should evolve too, and sometimes evolution means building something new rather than continuing to patch something old.
The first system was already better than what most teams have ever worked with. The decision to build a second one wasn't a judgment on it — it was the result of knowing more than I did when I started. You can't fully design a system for a team you don't know yet, and what I learned working closely with the creative team was that maximum flexibility wasn't actually serving them. What they needed was something more purposefully constrained — specific components and size and spacing structures with room to flex within a well-defined system, not an open-ended library that required constant decision-making.
The second system reflects that understanding in concrete ways. Typography, for example, is no longer organized around semantic HTML tags. In V1, styles were tied to structural elements — h1, h2, p — which made sense architecturally but didn't map naturally to how the creative team thought about type. In V2, the style is separated from the architecture entirely. The organizing principle is heading, body, small, and fine, with t-shirt size options available for each. The underlying HTML structure is still there and still correct, but the design system speaks the language of the people using it.
The component library follows the same logic. Rather than grouping everything by anatomy — a card section that grows longer with every new variant — V2 organizes components by use case. Lab results have their own family. Product display has its own family. Portal components, questionnaire flows, rewards tracking — each one is a coherent group built around what it does rather than what it looks like. This makes the system easier to navigate, easier to extend, and far easier to hand off to developers who need to understand not just the component but its purpose.
The V2 library now includes 97 components across 14 component sets, with 148 variables spanning color, spacing, and typography — each with responsive modes for mobile, tablet, and widescreen. It's the system that will build the dashboard, and eventually the redesign of bodyhealth.com.
The two systems continue to inform each other. Lessons from V1 shaped V2, and discoveries made in V2 have found their way back into V1 as updates and refinements. That's how living systems are supposed to work — and it's how this one does.
Animation was identified early on as an important part of the user experience, and when I saw an opportunity to move that work forward, I took it. I had plenty of experience building interactive HTML prototypes, but this felt like a chance to extend what I knew — to stretch deliberately and build something I hadn't built before.
The result is a parametric motion design laboratory: a browser-based tool that allows the creative team to dial in animation settings interactively — easing curves, entry and exit speeds, fade values, panel shifts, masking logic, and directional behavior — and see the results in real time. It was built with GSAP for the motion and transition timelines, and plain HTML, CSS, and vanilla JavaScript for the component structure, styling, controls, and state. No build system, no framework. That was an intentional choice, made with the developer on the other end in mind. The easier it is to pick up and implement, the more useful it is.
The output options were designed with the same handoff philosophy: JSON for direct implementation, portable CSS for developer reference, and a shareable URL that encodes the exact configuration as query parameters. That last feature turned out to be the one that stopped the room. The idea that you could tune an animation to exactly the right feel, copy a single URL, and send a developer the precise specification with nothing lost in translation — that landed in a way I didn't fully anticipate. It was one of those moments where a tool does exactly what it was built to do, and everyone in the room understands it immediately.
Phase 2 centers on a user portal and personal wellness dashboard — a single authenticated experience that brings together appointment scheduling, lab result tracking, wellness score visualization, order history, rewards, and personalized product recommendations across mobile and widescreen.
The dashboard is built around the idea that a wellness platform should feel personal from the moment you arrive. The experience greets users by name and opens with a daily affirmation. It knows the time of day and adjusts the banner imagery accordingly — a different feeling in the morning than in the evening. It surfaces the local weather and temperature for your location. It shows you notifications for upcoming appointments, your current rewards status, and your wellness score before you've had to navigate anywhere. Everything above the fold is contextual, relevant, and yours.
From there, tabbed navigation moves between Appointments, Wellness Score, Lab Results, Orders, Rewards, and Recommendations. Lab results include biomarker grids, reference range visualizations, and chip-tagged clinical insights that help users understand what their numbers actually mean. The rewards section uses a progress bar with clear points accrual and redemption tracking. Personalized recommendations are organized by product category — supplements, prescriptions, and testing — and presented as curated cards based on the user's wellness history and goals.
I built the dashboard home page as a fully functional Figma prototype — every tab clickable, real content throughout, responsive at both mobile and widescreen. The whole thing came together in about two weeks. I'd already been building the V2 library before the dashboard was assigned, so when it became an urgent priority the system was ready. The components, the tokens, the responsive modes — all of it was in place. I wasn't building screens from scratch. I was assembling them from a library that was already working.
The dashboard designs were developed collaboratively and presented to a cross-functional group of senior stakeholders and subject-matter experts spanning design, operations, and clinical. The reaction was telling: the room had very few questions and no suggestions for improvement. For a cross-functional executive review of this scope, silence is the highest compliment — it means nothing needed to be defended because nothing needed to be fixed.
These were handsome wireframes — real content, real style, real responsive behavior — presented as a framework to react to rather than a finished deliverable. The fact that a room full of executives treated them as if they were finished says something about the approach.
A design system is only as good as what it builds. The real test isn't how the components look in Figma — it's how faithfully they translate when a developer picks them up and puts them to work. The BodyHealthRx Shopify build is that test, and it passes.
The side-by-side comparison below shows the Figma design and the live Shopify implementation of the home page and the at-home tests page. The layout, spacing, typography hierarchy, component structure, and visual tone are essentially identical. The token architecture, the naming conventions, the responsive modes — all of it was built to make this moment possible. Not just a design that could be handed off, but one that could be built from.
The system didn't just translate faithfully — it accelerated the build. When asked about working with the design system, the founder and CEO of the Shopify Plus agency building the site put it directly: "This thing is 1000x better than just about anything I ever work with. Light years ahead."
Figma home page desktop design
Scroll to compare
Shopify home page build
Scroll to compare
Figma test page desktop design
Scroll to compare
Shopify test page build
Scroll to compare
I love this work. I love building things and working with people who want to figure things out together. I love mining for efficiencies — finding ways to make processes faster, less prone to error, and more effective without adding complexity. I love the moment where a system starts working for the team instead of the other way around.
This project is a good example of all of it. A design system built to anticipate the next phase of a platform before that phase had been scoped. A content architecture restructured to mirror the component architecture so that neither becomes the bottleneck. A second, better-fitted system proposed not because the first one failed, but because there was a more purposeful solution available once I knew the team well enough to design for them specifically. A motion design tool built from scratch to give the creative team real-time control over animation behavior — and to give developers a single shareable URL as the spec. Figma files organized so clearly that a project manager leading the platform rollout stopped to ask for a thirty-minute walkthrough of how the system was built because it was so comprehensive and complete.
Design systems don't succeed on their own. They require organizational commitment, cross-functional trust, and a shared willingness to invest in the foundation before the returns are visible. BodyHealthRx made that commitment, and the work reflects it. The engagement is ongoing. The platform is still launching. The system is still evolving. That's exactly the point.