Building the design-system foundation for two operational healthcare MVPs
Loading content...
Loading content...
PantherRX was building two connected products at once: SWFTx, an operational workspace for pharmacy associates, and the Clinical Survey Tool, a configuration tool for implementation teams. Both products were moving quickly toward MVP, but their UI needed a shared foundation for consistency, accessibility, and maintainable delivery.
I owned the Storybook-based component system and UI/UX direction across both products. My role was not to make final business decisions; I created the component base, design tokens, reusable patterns, and implementation-ready recommendations that product, engineering, QA, and business stakeholders used to move decisions forward.
By August 6, 2026, neither product had launched to a broader user population, so I cannot claim adoption or business impact. The measurable result was a shared design-system foundation used across both MVPs: approximately 93 exported component families, 308 token definitions, 216 automated accessibility assertions, and 200 published design-system releases.
PantherRX’s products support rare-disease pharmacy operations: helping teams manage patient outreach, prescription fulfillment, survey-driven work, implementation configuration, and related workflows. The larger goal was to help patients get prescriptions filled and remain on therapy.
SWFTx and the Clinical Survey Tool had different users and workflows, but they shared an underlying problem: both were evolving rapidly, with requirements, prototypes, and implementation often advancing in parallel.
The work exposed recurring UI risks:
Without a shared system, each MVP risked accumulating one-off fixes, inconsistent patterns, and UI debt while the team was trying to reach launch readiness.
I owned the shared Storybook design-system foundation and UI/UX recommendations across SWFTx and the Clinical Survey Tool.
My responsibilities included:
I did not have final business decision rights. Jen, AJ, Matt, implementation stakeholders, and the broader product and business organization informed requirements and approvals. My contribution was design leadership: I brought the component system and the interface expertise that made decisions concrete, consistent, and shippable.
The team’s intended workflow was to use Storybook components, then page-level mockups, then PRD validation and implementation—a shared review path rather than disconnected design artifacts.
The products were not being developed in a slow, linear handoff model. The team was building MVP functionality while requirements, technical constraints, and UI details continued to evolve.
For the Clinical Survey Tool, implementation work surfaced spacing and alignment problems, inconsistent layout density, unclear modal behavior, and component-level issues that needed correction.
The team also identified more specific usability problems: blank loading states that did not communicate progress, navigation and tab alignment issues, unfinished card patterns, and inconsistent visual behavior across screens.
In SWFTx, complex operational workflows required a common language for highly reusable interactions: configurable queues, task selection, work sessions, forms, patient context, and configuration rules.
I treated the design system as delivery infrastructure—not as a visual-polish layer.
Rather than producing separate screen-by-screen implementations for each product, I focused on a shared Storybook system.
This created a common source for:
The intended business mechanism was straightforward: a shared system would reduce duplicated implementation work, lower UI inconsistency risk, make reviews more concrete, and allow the team to improve components once rather than separately in two applications.
Both products needed to display dense operational and configuration information without defaulting to large, difficult-to-scan data grids.
I built reusable card and list patterns to support configurable content, status, actions, filtering, selection, and expansion. This aligned with the project’s broader effort to move away from “data grid fatigue” where a grid was not the best fit for the task.
User benefit: People can scan status, relationships, and actions in a more structured presentation.
Intended business value: A reusable card system reduces repeated implementation effort while allowing different teams to work from consistent interaction patterns.
Both products needed stable navigation, tabs, sidebars, top bars, and contextual page layouts. I built these as shared foundations rather than allowing each feature area to invent its own approach.
The need for consistent tabs, headers, navigation treatments, and information hierarchy was repeatedly identified in SWFTx reviews.
User benefit: Familiar structure reduces the effort required to reorient across screens and workflows.
Intended business value: Shared navigation patterns make later feature development more predictable and reduce design and implementation drift.
The Clinical Survey Tool needed users to create and manage questions, logic, tags, content, pre-population, and writeback behavior. These were not simple forms: configuration could involve dependencies, conditional content, application contexts, and reusable values.
I built shared controls for rich text, forms, dynamic tags, PEL expression editing, and logic builders.
User benefit: These patterns make complex configuration surfaces more consistent and give users a repeatable way to author, inspect, and test logic.
Intended business value: Reusable authoring controls give implementation teams a scalable foundation for future survey and workflow configuration rather than requiring bespoke UI for every new requirement.
Accessibility was treated as a system requirement. The project discussions covered WCAG targets, contrast, typography, keyboard behavior, labels, focus states, and color-independent communication.
I built accessibility into the Storybook foundation through:
User benefit: Reusable components provide a more consistent baseline for keyboard access, focus visibility, labels, contrast, and non-color-dependent UI.
Intended business value: Catching accessibility issues in a shared layer reduces regression risk and avoids repeatedly solving the same compliance and usability problems across products.
Measured against origin/main at bcbe824b / v0.1.207, I delivered:
Area
Delivered
Exported component families
~93
Top-level component functions
137
Headless hooks
100
Total exports
523
Core primitives
19
Form controls
19
Navigation components
7
Overlay components
6
List / selection patterns
5
Layout utilities
3
Advanced editors
5
AI chat-layer components
10
Icons
85
CSS token definitions
308
Clinical Survey Tool page patterns
12
Survey question controls
15
Dynamic-tag authoring components
7
Published design-system releases
200
Merged PRs since March 30, 2026
243
Story files
135
Story exports
843
Interaction test cases
347
Automated accessibility assertions
216
The system included the reusable foundations I considered most valuable for both products:
The meeting record shows that Storybook was used as a component and review foundation, with a workflow connecting components, full-page mockups, PRD validation, stories, and implementation.
For the Clinical Survey Tool, the team reported that 95% of testable scenarios were complete by June 3, 2026. Some functionality—including tags, auto-generated fields, and parts of question logic—remained in progress.
Later meetings described the Clinical Survey Tool as approaching MVP/big-feature completion, with CAB testing planned to show it would not affect existing production systems.
As of August 6, 2026:
I would not claim that the design system improved business performance yet. The current evidence shows a shared, tested foundation for reaching MVP and preparing for adoption.
I learned that a design system is most valuable when it is treated as operational infrastructure.
The important work was not creating a library for its own sake. It was creating a reliable path from product discussion to reusable UI, accessibility expectations, implementation, and review.
I would preserve:
I would change:
This work demonstrates how I approach design in an environment where product requirements, engineering constraints, and MVP delivery are all moving at once.
I did not treat design as a handoff artifact. I built the shared system through which the UI could be created, reviewed, tested, and shipped across two products.
The goal was not a more polished interface in isolation. The goal was to give two operational healthcare MVPs a coherent, accessible, reusable foundation that could support implementation teams now and real-world adoption after launch.
Claim
Classification
Confidence
Supporting evidence
Qualification needed
I owned the Storybook-based design-system foundation and UI/UX recommendations across both products.
Confirmed
High
User-provided repository evidence; shared-component direction documented in meetings.
Do not claim final business decision rights.
SWFTx and the Clinical Survey Tool were connected MVP efforts with distinct operational and configuration workflows.
Confirmed
High
Keep product scopes distinct while describing the shared foundation.
Rapid development created UI consistency, accessibility, and requirements-alignment risks.
Confirmed
High
Avoid saying those risks caused business harm.
The system contained ~93 exported component families, 308 token definitions, 216 automated accessibility assertions, and 200 releases.
Confirmed
High
User-provided repository comparison against origin/main at bcbe824b / v0.1.207.
Identify these as repository delivery metrics, not user outcomes.
The system included cards, app shell, rich-text controls, logic builders, and form controls.
Confirmed
High
User-provided repository inventory; meetings support the need for these patterns.
Do not imply every component was consumed equally by both products.
Accessibility was embedded into the shared implementation layer.
Confirmed
High
User-provided accessibility evidence; accessibility priorities discussed in meetings.
Do not claim formal certification unless independently verified.
The design system reduced implementation duplication and inconsistency risk.
Reasonably inferred
Medium
Shared-component strategy and reusable cross-product patterns.
Phrase as an intended mechanism or design rationale, not a measured result.
The Clinical Survey Tool had 95% of testable UAT scenarios complete by June 3, 2026.
Confirmed
High
This is a point-in-time status, not a current August 6 measure.
The products were nearing MVP and preparing for CAB.
Confirmed
Medium-high
Do not state CAB approval or launch occurred.
The system improved adoption, productivity, task completion, error rates, or business performance.
Unknown
Low
No post-launch evidence available.
Exclude from case study until measured after launch.
Coverage note: Based on all 111 meetings in the PantherRX folder plus your repository comparison against origin/main at bcbe824b / v0.1.207. Repository metrics describe delivered system infrastructure; meeting evidence supports MVP progress and UAT readiness, but not post-launch user or business outcomes.