A component library and token system for a regulated life-sciences platform, built so multiple product teams could ship consistent, accessible interfaces without redesigning the basics each time.
A shared foundation for finding evidence, comparing documents, and reviewing changes with clinical accuracy.
The platform supports work with medical knowledge: finding records, comparing content and reviewing changes. Long passages and dense lists make consistency more important, not less.
I was the sole designer on the three-month project. My scope covered the design language, component library, custom iconography, accessibility and documentation.
The challenge was inconsistency across typography, spacing, icons and component behavior. Dense layouts made those differences harder to navigate.
The system needed clear rules for recurring decisions. These questions summarize the project concerns, rather than findings from a new audit.
Does the hierarchy stay consistent from one view to the next?
Do equivalent actions have the same behavior and feedback?
Can people distinguish the content, its status and the next action?
Can people understand and use the controls with different input methods?
How do you bring consistency to a research tool without losing the detail people need?
Consistent color, typography, icons and spacing give components a shared starting point. Clear roles make those choices easier to reuse.
The palette and type scale below follow my original project references. The modern examples and proposed token structure belong to the 2026 reconstruction.
Neutral surfaces keep attention on the content. Blue (#09609F) and green (#1D8755) give this case study its visual identity.
In the original palette, green supports primary actions and blue supports navigation. Separate colors communicate errors, warnings, success and information.
The original type scale defines a role for headings, subtitles, body copy and supporting text. Regular weights carry the reading experience; semibold weights distinguish labels and subtitles.
These specimens retain the supplied sizes, weights and line heights. The reference does not identify the original font family. This portfolio uses Manrope for body text and Flecha, with Georgia as a fallback, for titles.
Medical guideline management
Compare document versions
Review the selected change
Document details
Content comparison
Reviewer annotation
Keep the source, date and review status visible beside the content.
Each document retains its context while the reviewer moves between changes.
Each document retains its context while the reviewer moves between changes.
A longer passage needs room to breathe. The reading view keeps related information together and gives each line enough space to follow comfortably.
REVIEW STATUS
DOCUMENT DETAILS
Supporting information appears beside the content it describes.
REVIEW
02 / Sizes, weights and line heights transcribed from the supplied typography image. Both Body 2 treatments are retained, with 24 px and 28 px line heights.
I designed custom icons as part of the original system, with guidance for consistent sizing and use.
A shared grid and consistent strokes help icons work as a family. Familiar actions should use recognizable symbols; less familiar actions need text labels.
03 · Original icon library and construction grid.
View icon documentation (opens in a new tab)Density is not simply about fitting more into a screen. Related content needs to stay together, while different tasks need enough separation.
Consistent spacing makes those relationships clear: tighter gaps group related information, while larger gaps separate tasks.
The final designs bring the foundations, components and icons together in medical guideline workflows. Clear hierarchy keeps document details, research content and review actions organized.
These screens show how the system supports reading source material, identifying changes and recording review decisions within a consistent interface.
Buttons, fields and supporting patterns.
Each needs clear states, feedback and guidance.
A compact control needs room to press. A reusable value needs a name that explains its purpose.
These reconstruction studies show how target size and token naming support consistent interfaces.
A proposed 44 × 44 px minimum hit area keeps the smaller control easy to target.
Supplied sizing illustration. Dashed outlines show recommended targets; solid outlines show visual bounds. Target recommendations do not establish historical accessibility compliance.
Trace a raw color through a primitive, a semantic role and a component alias.
Proposed Figma variable aliases for the 2026 reconstruction. Each step references the preceding layer so shared color updates stay consistent across the light theme.
Readable text is one part of accessibility. Components also need visible focus, keyboard support, clear status messages and useful error guidance.
The original scope included accessibility. These reconstruction checks demonstrate intent; they are not a claim of historical compliance or a complete accessibility audit.
#151515 on #FFFFFF
Calculated contrast for this pair.
KeyboardVisible focus, logical order and native controls.
FeedbackLabels and errors communicate meaning without color alone.
MotionFuture video examples should include pause controls and reduced-motion support.
ReadingResponsive type and horizontal scrolling for dense tables.
I created the original design work in Adobe XD and used Zeroheight for documentation. The Figma structure is a new proposal for a modern reconstruction.
The proposed handoff brings together component names, states, responsive behavior and accessibility notes, so developers can understand how each pattern should work.
For the next iteration, I would use a short contribution path. A new component should solve a recurring need, with clear states and ownership.
The following process is a proposal for future maintenance, not a record of the original release process.
Start with the workflow and existing alternatives.
Agree on behavior, accessibility and implementation requirements.
Align the library, code and documentation.
Document exceptions and explain how to replace outdated patterns.
My contribution covered the component library, custom iconography, and documentation. The project screens demonstrate the system applied to document comparison and change review.
The result is presented through design artifacts and documented rules. The case study does not claim a measured improvement in adoption, delivery speed, or business performance.
Color, typography, spacing, and custom icons.
Component patterns and supporting documentation.
Document comparison and change-review screens.
I would track component use, accessibility issues, time spent on comparable tasks, and feedback from designers and developers. Each measure needs a baseline, a defined sample and a review date.
Review whether patterns cover the required states, behave consistently in real workflows, and have clear guidance. Component counts alone do not establish usefulness or adoption.
I want the next designer or developer to understand why the decision was made.
For product design, design systems, prototypes, and AI-powered design workflows.