Overview
Flywheel is a cloud-based biomedical research data management platform used by academic medical centers, research hospitals, and pharmaceutical organizations worldwide. The platform manages the full lifecycle of research data — ingestion, curation, analysis, and collaboration — for modalities including MRI, fMRI, PET, and a range of computational neuroimaging pipelines.
The user population is demanding and technically sophisticated: principal investigators managing multi-site studies, data scientists running computational pipelines, radiologists reviewing acquisitions, research coordinators tracking compliance and workflow, and data governance officers managing access and provenance. Designing for this population requires fluency in research workflows and an unusually high tolerance for information density — the work is not about simplification for its own sake, but about surfacing the right information at the right moment for people who need precision, not convenience.
My engagement spanned three distinct workstreams: design systems infrastructure through the Vision corporate design system, an AI-assisted documentation experience embedded across the product, and a full research and concept sprint for a proposed research manager platform redesign called Trial Builder.
Vision Design System
Vision is Flywheel's corporate design system — the shared token layer, component library, and pattern documentation that spans the product suite. My role encompassed both contribution and stewardship: building and extending components, maintaining consistency across the library, and acting as a resource for product teams implementing Vision in their workflows.
Design systems work at Flywheel operated under the same constraints that apply to any enterprise platform with a technically exacting user base: components need to handle data-dense layouts gracefully, information hierarchy has to function at smaller type sizes than a consumer product would accept, and the system has to be stable enough that research teams can build confidently without worrying about upstream changes breaking their implementations.
Explore the Design Library → Explore the Product Demo →
AI-Driven Documentation
Flywheel's primary product for research managers is complex enough that documentation is not optional — it is a core part of the user experience. The question was how to make that documentation useful at the moment it is needed, rather than something users had to leave the product to find.
The AI-driven documentation system was designed to surface contextual help and guidance directly within the product interface, meeting users at their current task rather than sending them to a separate knowledge base. The same system extended to standalone documentation pages, where it served users approaching the platform from outside the product — onboarding, reference lookup, and troubleshooting without requiring a live session.
Designing across both surfaces required careful thinking about context: what a user already knows when they are inside the product is not what they know when they arrive at a documentation page cold. The interaction model, information depth, and visual treatment needed to differ between surfaces while the underlying intelligence remained consistent. That dual-surface constraint was the central design challenge of the engagement.
Trial Builder
Trial Builder was a proposed redesign of Flywheel's research manager platform — the product used by the people responsible for coordinating, running, and governing clinical and scientific research studies. The existing product had been built incrementally around individual features rather than around the researcher's end-to-end workflow. Trial Builder was an opportunity to reconsider the platform from first principles.
Research foundation
The engagement began with a structured research sprint in FigJam, establishing a shared understanding of who the platform actually served. Seven personas were developed across the full research workflow:
- External Data Contributor — researchers and institutions submitting data from outside the primary organization
- Research Coordinator — the operational backbone of a study, managing scheduling, compliance, and participant communication
- Data Manager — responsible for data quality, pipeline execution, and storage governance
- Data Scientist — building and running computational analyses, often across large multi-site datasets
- Radiologist — reviewing acquisitions for clinical quality and flagging issues before data enters the analysis pipeline
- PI / Sponsor — accountable for the study as a whole, primarily concerned with progress, compliance, and results
- Data Governance Officer — managing access, provenance, and regulatory compliance across the platform
Each persona was developed with extended depth: a "Day in the Life" narrative, current Flywheel touchpoints, pain points, workflow gaps, strategic opportunities, and an assessment of the persona's strategic value to the platform. This level of detail was intentional — surface-level personas produce surface-level design decisions. The goal was a model of each role that was specific enough to make difficult design trade-offs against.
Concept and workflow analysis
Workflow analysis documented the current state for each persona — what they actually did in and around the platform, where friction accumulated, and where Flywheel had visibility into user needs it was not yet acting on. Current-state analysis preceded any concept work; understanding what was broken had to come before proposing what to build.
User journey maps extended this analysis across time, showing how a research coordinator's experience of a study differed from a data scientist's or a governance officer's — and where those journeys intersected in ways the platform was not yet designed to support.
Concept sketches and early design exploration followed, grounded in the workflow analysis rather than in feature enumeration. The question driving the concepts was not "what should this screen do" but "what does this person need to know and do at this moment in their work."
Status
The Vision design system contributions and the AI-driven documentation system are live, in production use across Flywheel's product suite. Trial Builder was a research-and-concept sprint: the persona framework, workflow analysis, and concept exploration above were delivered as a proposed direction, not an implemented product. A next phase would move from concept validation into detailed design and engineering scoping.