I designed and engineered a scalable digital healthcare platform that unified patient education, content management, e-commerce, multilingual experiences, AI-assisted publishing, and administrative workflows into a single headless ecosystem.
This was not a website redesign. JourneyLite needed a healthcare product platform that could replace plugin-dependent operations, unify disconnected patient and staff workflows, and give non-technical teams the flexibility of WordPress without the long-term cost, fragility, and governance problems of the legacy stack.
The previous platform had accumulated heavy WordPress plugin dependency, disconnected commerce, slow publishing workflows, technical debt, poor editor experience, and limited scalability. The product vision was to design a headless ecosystem that could support patient education, content operations, e-commerce, translation, AI-assisted publishing, forms, analytics, and admin workflows from one modular foundation.
I owned product strategy, UX research, information architecture, interaction design, design systems, CMS architecture, AI workflow design, technical SEO, frontend engineering, and platform implementation. The output was a product ecosystem, not a set of pages.
The business problem was operational as much as visual. The legacy system made it harder to publish, harder to govern content, harder to scale services, harder to maintain commerce, and harder to evolve the patient experience without adding more plugins.
Heavy WordPress plugin dependency
High recurring software and maintenance costs
Disconnected website, commerce, learning, and content workflows
Slow publishing cycles that required technical intervention
Limited scalability for new services, languages, and patient education
Technical debt from years of incremental template and plugin additions
Poor editor experience and inconsistent content governance
Fragmented commerce and unclear long-term maintainability
Designed for Four Distinct User Groups
Rather than designing for a single audience, the platform balances the needs of patients at different stages of their care journey while empowering internal teams to manage content, operations, and growth.
Prospective Patients
“I am exploring whether bariatric care is right for me.”
Primary Goal
Understand treatment options and build confidence without pressure.
Key Needs
Procedure education
Eligibility guidance
Cost transparency
Trust signals
Design Considerations
Organize education around plain-language exploration before conversion, so patients can compare options and reduce uncertainty first.
The core design challenge was balancing patient clarity with operational scalability. Patients needed a calm, trustworthy experience that made complex healthcare decisions easier to understand. Internal teams needed flexible tools that let them publish, update, translate, and manage content without creating more technical debt.
The solution was not simply a redesigned website. It was a headless healthcare platform that preserved the ease of a CMS while moving the business onto a faster, safer, more maintainable architecture.
03Platform Architecture
The architecture was designed to be modular: content, commerce, AI, localization, analytics, and admin workflows can evolve independently while still serving one patient experience.
Locale routing, language switching, translation cache
08Analytics
Publishing, conversion, content, and patient pathway measurement
This structure separates patient-facing presentation from content governance, commerce operations, AI-assisted publishing, localization, and operational data. That separation is what makes the platform maintainable over time.
04Platform Capabilities
I framed each major feature as an internal product capability, with a problem, design decision, implementation approach, and business value.
Headless CMS Platform
Problem
Staff needed WordPress-level flexibility without inheriting WordPress plugin fragility.
Design Decision
Design a Sanity-powered content platform with structured content, reusable sections, rich text, Markdown, HTML support, drafts, relationships, and publishing workflows.
Implementation
Modeled a modular page builder, reusable content blocks, structured schemas, content relationships, and editor-friendly publishing states.
Business Value
Non-technical teams can assemble and maintain complex pages without waiting for custom templates or developer support.
AI Content Studio
Problem
Publishing healthcare content was slow, repetitive, and hard to optimize consistently for SEO, disclaimers, internal links, and review.
Design Decision
Treat AI as an editorial copilot inside the publishing workflow, not as an autonomous author.
Implementation
Designed AI-assisted blog generation, metadata generation, disclaimer drafting, testimonial generation, content refinement, rich HTML, Markdown, internal linking, streaming output, and human review checkpoints.
Business Value
Editors can move faster while retaining clinical judgment, brand control, and final human approval.
Dynamic Form Builder
Problem
Third-party form plugins created inconsistent validation, fragile integrations, spam risk, and difficult lead routing.
Design Decision
Make forms a reusable product capability instead of a plugin dependency.
Implementation
Defined visual form builder behavior, custom field types, validation states, conditional fields, success states, reusable templates, submission management, spam protection, and lead routing.
Business Value
The organization can launch new intake and campaign forms without adding more plugin debt.
Flexible Page Builder
Problem
Every new campaign, service page, or resource risked becoming a custom one-off build.
Design Decision
Build pages from governed reusable blocks rather than fixed templates.
Implementation
Created composable modules for hero sections, CTAs, FAQs, testimonials, cards, rich text, image blocks, process steps, statistics, resources, forms, callouts, and button groups.
Business Value
Marketing and operations teams gain flexibility while the design system preserves consistency and accessibility.
Headless Commerce
Problem
WooCommerce added operational complexity to a site that also needed healthcare education, content governance, and future scalability.
Design Decision
Move commerce into a Shopify-backed storefront architecture.
Implementation
Separated storefront presentation from commerce operations, improving checkout, inventory, integrations, and maintainability.
Business Value
Commerce can scale independently while still feeling connected to the patient journey.
Translation Platform
Problem
Multilingual support needed to be architectural, not a layer of translated static pages.
Design Decision
Design localization around shared content models, locale routing, language switching, SEO-aware metadata, translation caching, AI-assisted translation, and RTL readiness.
Implementation
Planned translation states, reusable localized content fields, routing conventions, and governance for translated healthcare content.
Business Value
The platform can expand language coverage without rebuilding the content system for every locale.
Content Migration Platform
Problem
Legacy articles, metadata, images, SEO value, and internal links could not be discarded during modernization.
Design Decision
Treat migration as a product system with extraction, cleaning, transformation, validation, redirects, and preservation.
Implementation
Mapped legacy content to structured schemas, converted rich text, preserved metadata, planned image migration, internal links, and redirect strategy.
Business Value
The platform keeps existing search equity while moving content into a maintainable future-state architecture.
Design System
Problem
The legacy experience had too many one-off interface patterns, inconsistent spacing, weak governance, and inaccessible form/content states.
Design Decision
Create reusable foundations for healthcare content, admin tools, CMS blocks, and conversion flows.
Implementation
Defined buttons, forms, cards, spacing, typography, tokens, navigation, charts, healthcare components, CMS blocks, and reusable layouts.
Business Value
Future product work starts from a shared system instead of repeatedly solving the same UI problems.
05Product Artifacts
The most important visuals were not polished screenshots. They were system maps that explained how the product worked.
User Journey
Prospective patient, high-intent patient, returning patient, and internal staff paths.
Information Architecture
Navigation and content model organized around patient intent instead of departments.
CMS Schema Diagram
Reusable content types, page sections, relationships, and publishing states.
System Architecture
Next.js, Sanity, Shopify, Supabase, AI services, localization, analytics.
Patient education context connected to Shopify checkout and product operations.
06Discovery
Six weeks of structured research across four parallel tracks — before a single frame was designed.
01AlignStakeholder interviews & goal setting
02ResearchUser archetypes & journey mapping
03AuditAccessibility, IA & technical review
04SynthesizeAffinity mapping & opportunity matrix
05DefineProblem framing & product strategy
06PrioritizeRoadmap & feature scoping
Business Discovery
Aligned stakeholders around shared goals, constraints, and measurable success criteria before any design decisions were made.
Stakeholder interviews
Business goal workshops
Feature prioritization
Success metric definition
Requirement gathering
UX Research
Mapped real patient behaviors, mental models, and barriers to task completion across all four user states.
User archetypes & mental models
Patient journey mapping
Competitive analysis
Navigation & IA audit
Heuristic evaluation
Mobile experience review
Accessibility Review
Identified 20+ WCAG 2.2 AA failures across the live platform — from contrast to keyboard navigation to cognitive load.
WCAG 2.2 AA compliance review
Keyboard navigation testing
Screen reader evaluation
Color contrast analysis
Cognitive accessibility
Form & label accessibility
Technical Audit
As both designer and engineer, I audited the existing codebase directly — surfacing component debt, performance gaps, and SEO issues.
Component architecture audit
CMS schema mapping
Lighthouse & Core Web Vitals
Bundle & rendering analysis
SEO implementation review
Design consistency audit
Research Repository
15 documents · All completed
Product BriefGoals, constraints & scope
4pDone
Research PlanMethods, timelines & objectives
6pDone
Stakeholder AnalysisInterview synthesis & themes
8pDone
User ArchetypesFour patient & staff profiles
5pDone
Jobs To Be DonePatient goal mapping
4pDone
Journey MapEnd-to-end patient experience
7pDone
Service BlueprintCross-channel service flows
6pDone
Accessibility AuditWCAG 2.2 AA findings
9pDone
Navigation AuditIA & labeling issues
5pDone
Information ArchitectureBefore/after IA diagrams
8pDone
Heuristic Evaluation10 Nielsen heuristics scored
6pDone
Design System AuditComponent & token inventory
7pDone
Technical AuditCode, performance & SEO
8pDone
Opportunity MatrixPrioritized problem space
4pDone
Product RoadmapPhased delivery strategy
5pDone
30+Research Artifacts
80+Pages
6Research Phases
20+A11y Findings
15+Journey & IA Deliverables
3Integrated Platforms
The complete research dossier.
Every artifact produced during discovery — from stakeholder interviews and journey mapping to accessibility audits, technical analysis, service blueprints, IA diagrams, and product strategy — documented in a single comprehensive internal dossier.
Open full-screen dossierReview research artifactsScan IA, accessibility, and platform strategy
07Insights
Four themes appeared consistently across every research method.
Discoverability
Patients struggled to understand where to begin, which treatment fit their needs, what would happen next, and how educational resources connected to treatment decisions.
Accessibility
The platform created unnecessary cognitive load. Medical terminology, inconsistent heading hierarchy, unclear CTAs, and dense content made critical information harder to understand.
Design Consistency
Years of incremental growth resulted in duplicated patterns, inconsistent spacing, varying typography, and multiple interaction styles that eroded trust and predictability.
Operational Scalability
Content publishing relied heavily on manual processes, making updates slower and increasing the likelihood of inconsistency across the platform over time.
See the full 21-section research dossier behind these findings.
08Problem Statement
How might we create a healthcare platform that helps patients confidently navigate treatment while providing staff with scalable content management — without losing the brand identity patients already recognize?
09AI-Augmented Design
Rather than using AI to generate finished designs, I integrated AI throughout discovery, analysis, documentation, and implementation — accelerating repetitive work while keeping every design decision grounded in research and product strategy.
Claude
Research synthesis
Affinity mapping
Journey mapping
Information architecture exploration
Content strategy
Research documentation
Opportunity identification
Claude Code
Claude Code became a design engineering partner by analyzing the existing application directly.
AI accelerated the process — but final design decisions were always validated against user needs, stakeholder goals, accessibility standards, and technical feasibility.
10Information Architecture
The existing IA reflected internal organizational structure, not patient goals. Pages were organized by department, not by what a patient needed to know or do next.
Before
Home
→ About Us
→ Procedures
→ General Surgery
→ Bariatric
→ Products
→ Patient Portal
→ Contact
Organized by department. Patients had to know what category their need fell under before navigating.
→
After
Home
→ Your Journey
→ Explore Options
→ Schedule a Consult
→ After Surgery
→ Learn
→ Shop
→ Patient Portal
→ About
Organized around patient goals and readiness stages. Every path starts with intent, not category.
Curious how the design system supports this new structure?
Rather than replacing JourneyLite's existing visual identity, I evolved it — maintaining patient recognition while introducing the consistency and accessibility the platform needed to scale.
Maintain recognition
Brand equity built over years was worth preserving.
Increase consistency
One token set governs spacing, color, and type across all surfaces.
Improve accessibility
Every decision tested against WCAG 2.2 AA from the start.
Scale efficiently
New pages and features compose from existing components.
Accessibility wasn't a final pass. It was embedded into every decision — from IA to copy to component design to implementation. WCAG 2.2 AA was the floor, not the ceiling.
Rather than redesigning individual pages, I redesigned the underlying platform. Each capability below solved a business, operational, or patient experience problem while contributing to a scalable healthcare ecosystem.
A patient-facing system that helps people understand options, compare pathways, build trust, and move toward consultation without cognitive overload.
Challenge
Patients entered JourneyLite from different states of readiness. Some were researching symptoms and eligibility, while others were ready to schedule but still needed reassurance around cost, safety, financing, outcomes, and next steps.
Product Decision
I organized the experience around patient intent instead of internal departments. The scalable decision was to connect education, calculators, procedure comparison, trust signals, and consultation CTAs into reusable pathway patterns.
Patient journey model
01Explore options
02Compare treatments
03Check fit
04Schedule consult
05Continue care
The model connects Explore, Compare, Decide, Schedule, and Continue stages with relevant content, tools, and conversion points.
Content PlatformModular CMS
A Sanity-powered content platform that gives editors WordPress-like flexibility without plugin fragility.
Challenge
Staff needed to launch pages, update service content, manage CTAs, and publish resources without waiting on developers or stacking more WordPress plugins.
Product Decision
I designed structured content models and a flexible page builder instead of fixed templates. This keeps the editor experience flexible while preserving governance, accessibility, and design consistency.
CMS publishing architecture
01Schema
02Reusable blocks
03Page builder
04Review
05Publish
Editors compose pages from governed blocks, rich text, Markdown, HTML sections, reusable templates, and structured relationships.
AI WorkflowsAI Content Studio
An internal AI product for creating, refining, formatting, optimizing, and preparing healthcare content for human review.
Challenge
Blog posts, landing pages, LMS course content, testimonials, metadata, accessibility checks, and SEO formatting were repetitive and time-consuming, but healthcare content still required governance and human judgment.
Product Decision
I positioned AI as a workflow accelerator inside the admin platform, not an autonomous publisher. The scalable product decision was to generate structured drafts, formatting, metadata, and checks while keeping staff in control.
AI prompt workflow
AI Prompt
Create a patient-friendly gastric sleeve landing page with FAQs, SEO metadata, accessibility checks, internal links, and a reviewed CTA block.
A prompt-driven studio streams structured drafts, SEO metadata, accessibility suggestions, internal links, course modules, and page sections into an editor review queue.
CMSDynamic Form Builder
A reusable form system that lets staff create, validate, route, and manage conversion forms without form-plugin debt.
Challenge
Consultation, eligibility, campaign, and support forms had inconsistent validation, fragile third-party dependencies, spam risk, and unclear lead routing.
Product Decision
Forms became a first-class platform capability. I designed reusable fields, conditional logic, validation, spam prevention, routing, and submission states as governed editor tools.
Form lifecycle
01Build form
02Add logic
03Validate
04Route lead
05Measure
Editors build forms from validated field types, attach routing rules, preview states, publish forms, and measure submissions from the admin surface.
Design SystemDesign System
A shared system of tokens, components, layouts, healthcare patterns, CMS blocks, and responsive behavior.
Challenge
Years of incremental additions created inconsistent spacing, typography, cards, forms, CTAs, and accessibility behavior across patient and admin surfaces.
Product Decision
I created a shared system that powers both the public experience and CMS-generated pages. The system constrains quality without limiting editor flexibility.
Component relationship map
01Tokens
02Components
03CMS blocks
04Layouts
05Patient flows
Tokens feed components, components feed CMS blocks, CMS blocks feed patient pathways, and the same accessibility rules govern every surface.
CommerceHeadless Commerce
A Shopify-backed commerce model connected to the broader patient education and care journey.
Challenge
WooCommerce created operational complexity inside a healthcare platform that also needed content governance, education, translation, and scalable maintenance.
Product Decision
I separated commerce operations from the patient-facing app by designing a headless Shopify architecture. This gave operations a stronger commerce backend while preserving unified branding and pathways.
Commerce architecture
01Education
02Products
03Cart
04Shopify checkout
05Operations
Product education, recommended items, and patient pathways stay in the platform while checkout and commerce operations run through Shopify.
LocalizationTranslation Platform
A multilingual architecture for locale routing, shared content, AI-assisted localization, and SEO-aware translated experiences.
Challenge
Translation could not be handled as duplicated static pages. Healthcare content needs shared governance, review states, metadata, routing, and future readiness for different language needs.
Product Decision
I designed localization as a platform layer with shared content models, locale routing, translation workflows, SEO metadata, and RTL readiness.
Localization workflow
01Source content
02AI assist
03Human review
04Locale routes
05SEO metadata
Content moves from source copy to AI-assisted translation, human review, localized metadata, and locale-aware publishing.
Admin PlatformAdmin Platform
A staff-facing operating layer for content, publishing, translation, forms, commerce, AI tools, governance, and analytics.
Challenge
The organization needed more than a public website. Staff needed one place to manage publishing workflows, content quality, forms, translation, commerce updates, AI drafts, and governance.
Product Decision
I framed admin tools as a product surface with role-aware workflows instead of disconnected plugins. This creates a maintainable operating model for the business.
Admin operating model
01Content
02AI tools
03Forms
04Commerce
05Analytics
06Governance
The admin surface connects CMS publishing, AI drafting, review queues, form submissions, commerce updates, analytics, and governance into one workflow.
MigrationContent Migration Engine
A migration system for preserving legacy content, metadata, URLs, images, internal links, and SEO value during modernization.
Challenge
Legacy articles, media, metadata, and internal links represented real business value. A rebuild that discarded or manually recreated that content would risk SEO loss and operational drag.
Product Decision
I treated migration as a product system: audit, extraction, transformation, validation, redirects, image handling, and structured publishing.
Migration pipeline
01Audit
02Extract
03Transform
04Validate
05Publish
06Redirect
Legacy WordPress content maps into structured schemas, media assets migrate with references, metadata is preserved, and URL continuity is protected through redirects.
16Product Outcomes
The outcome was not a redesigned homepage. It was a more scalable operating model for JourneyLite's digital healthcare ecosystem.
Reduced dependency on more than 10 WordPress plugins by moving key capabilities into owned platform architecture.
Consolidated disconnected website, content, commerce, learning, and admin workflows into a unified ecosystem.
Reduced recurring software and maintenance pressure by replacing plugin sprawl with reusable product systems.
Enabled non-technical staff to create complex pages from governed reusable blocks.
Migrated commerce strategy from WooCommerce complexity toward a Shopify-backed headless model.
Established AI-assisted publishing workflows for metadata, content drafts, disclaimers, internal links, and translation support.
Created reusable design system foundations for patient education, forms, admin workflows, and CMS-driven pages.
Improved long-term maintainability through structured content, modular architecture, and scalable localization planning.
Connected Platform Surfaces
Marketing Website
Patient-facing service discovery, education, conversion, and technical SEO.
Patient Portal
Learning continuity, resources, and future care-pathway entry points.
Admin Dashboard
Internal workflows for staff, content operations, forms, and reporting.
Content Operations
Sanity-powered publishing, structured content, AI assistance, localization, and governance.
Headless Commerce
Shopify-backed product operations connected to the broader patient journey.
Currently waiting on third-party EMR integration for consultation requests.
This project reinforced that mature product design is often less about designing pages and more about designing the systems that make good pages, workflows, and operations possible.
The most important work happened at the platform level: balancing editor flexibility with governance, designing reusable systems instead of one-off templates, reducing plugin dependency, and creating workflows that could scale after launch.
Designing AI-assisted workflows also required restraint. AI was useful for synthesis, metadata, drafts, translation support, and documentation, but the platform still needed human review, clinical sensitivity, and strong content governance.
The lesson: a healthcare platform succeeds when patient needs, business operations, content governance, accessibility, and engineering architecture are designed together.
Like what you see?
Let's work together.
I'm available for product design, design systems, and frontend engineering engagements. Let's build something worth using.
