RegNav, by Element
Overview
Joined an R&D department at the early stages of MVP build, leveraging digital solutions to accelerate the time-to-market for medical devices. Played a key role in all stages of the design process, from initial research, concept development, and a scalable design system.
Outcome
Launched RegNav, an AI-powered regulatory intelligence platform that provides MedTech companies with a comprehensive understanding of safety & performance requirements.
Role
Sr Product Designer
UX/UI/Research
Discovery
User Testing
Worked with
Directors
Product Managers
Developers
Regulation Experts
Data Scientists
Brand
Element Material Technology
RegNav
Who Are Element?
They have nearly 200 years’ experience in testing with 270 labarotories in 30 countries, with 9000 employees, 55k customers, and 1,5bn+ non-digital revenue. Element is owned by PE-fund Temasek since 2022. Currently, Element operates in 4 key areas: Life Sciences (pharmaceuticals and medical devices), Connected Tech (mobile phones), Built Environment and Aerospace.
Vision: To position the company very differently from a traditional TIC player (Testing, Inspection, Certificate), providing digital services to their customers.
Why RegNav?
Problem Statement
The commercialisation of new medical devices, particularly Class III and De-Novo devices, faces significant hurdles due to the complex and resource-intensive regulatory intelligence and testing phase. Specifically, medical device companies struggle with:
Navigating regulatory complexity: Difficulty in accurately determining necessary examinations, device classifications, and applicable Standards due to a lack of clarity and expertise.
Accessing qualified expertise: Challenges in identifying and securing experienced and qualified regulatory consultants, leading to potential delays and inaccuracies.
Efficiently processing Standards: The manual review of a vast number of Standards (1500+) is time-consuming, inefficient, and prone to human error, risking inaccurate Standard selection.
Managing documentation: The compilation of extensive regulatory documentation (3000+ pages) is a burdensome and complex process.
Maintaining post-market compliance: Ongoing challenges in staying updated on changes and predicate device updates after product launch, risking non-compliance.
These challenges contribute to the low success rates, extended time-to-market (2-7 years), and high costs ($2-5m, potentially exceeding $10m) associated with bringing medical devices to market, particularly for high-risk device classes.
RegNav VS Competitors
RegNav's competitive advantage is an offering of Compliance Plans, and integrated digital testing via Element's established presence in the TIC sector.
List of players and our competitive offering.
Segments and Value
We defined 3 segments, initially focusing on Start-ups, benefitting from reduced costs.
Startups (0-10):
Faster time to market.
Accurate Compliance Plans.
Reduced market entry costs.
SMEs (2-50):
Faster time to market.
Accurate Compliance Plans.
Large Enterprises (100+):
Reduced product launch risk.
Compliance Plan accuracy checks.
Breakdown of segments.
Priority Enhancements
An external agency had begun developing RegPath (later RegNav), a platform designed for AI-driven Standards identification using questionnaires and expert review.
As the first in-house hands-on designer, I immediately:
Reviewed existing design decisions.
Acquired ownership of design assets/documentation (Figma, Miro, user research).
Participated in discovery workshops, to understand the domain.
Based on existing user research, I collaborated with cross-functional teams to deliver 3 key priority enhancements:
Navigation/Stepper: Streamline navigation and workflow.
RegNav Identity: Establish brand hierarchy, integrate the Element logo, and implement a new UI adhering to best practices.
Optimise Payments: Fix payments issues, and user flow.
Navigation/Stepper
User testing revealed confusion in distinguishing between the linear input, and output stages of the workflow. Furthermore, the horizontal tabs demonstrate limitations for future feature expansion and exhibit scalability issues.
Ideate
I began by mapping the existing user flow, and explored the step groupings, adding new steps to enhance clarity.
I shared visual designs and taxonomy with stakeholders, iteratively improving navigational language, layout, and brand, from existing to final UI.
Define and Build
Final (RegNav): Leveraging parallel brand identity updates, I implemented key changes:
Hierarchical structure to better differentiate between the user's input and output stages.
Input - Provide Device Details (About, Classification, Characteristics, Review Essential Principles, Request Compliance Plan).
Output - Compliance Plan (Overview, Standards, Essential Principles).
Simplifying the language, introducing section titles, and removing overwhelming redundant copy.
Iconography and progress indicators.
Consistent CTA placements.
Removing unnecessary clutter, framing, and establishing grid systems.
Future proofing for reusable features e.g. collapsible navigation, and breadcrumbs logic.
RegNav Identity
In parallel with product development, a key branding/marketing requirement emerged to clearly establish RegPath as a product within the Element brand. This led to a small-scale identity project, resulting in the introduction of an overarching Element bar, and the creation of the RegNav logo. I reviewed product UI legibility, replacing FreightSans Pro with Inter and creating tonal color palettes for optimal contrast, adhering to WCAG guidelines.
Optimise Payments
Payment navigation and upload problems were identified through user testing. I visually mapped the existing flow, pinpointing issues like loops and W9 uploads.
Ideate
Before making any updates, I created a high-level flow to assess the payment placement. While we considered moving the payment step, we retained its initial placement due to product cost, onboarding, and security concerns.
Define and Build
After addressing the pain points and approving the updated flow, I created final UI for the payments section leveraging the new RegNav identity. Key changes were:
Removed confusing loop scenarios.
Added W9 upload functionality as part of the flow.
Consistent hierarchy for costs and CTA’s.
A clear path for direct Compliance Plan start.
Updated UI/identity.
Standardised language.
Design System Kick-Off
To improve design efficiency and consistency, I kicked-off a design system initiative with developers. Key objectives were:
Review and confirm Radix (open source library), removing redundant components.
Create a Figma UI kit, documenting variables (typography, spacing, colour) and sub components.
Implement the design system connecting Figma and Storybook.
Establish an iterative process for refining, expanding and developing custom components.
Summary
I made the conscious decision to keep the UI simple, focusing on functional components and UX patterns, setting linear foundations to build on systematically as we learnt more, and evolve the identity. I created a centralised product copy repository to facilitate collaborative feedback, and improve readability.
The first couple of months were a hugelearning exercise, understanding the domain, industry terms, working with Medical Experts, and forming strong teams as we transitioned away from the agency.
Product Code Finder
What Problem Are We Solving?
User research with Element’s Friends & Family network revealed users struggle to assign a regulatory path, class, and product code. This is an essential step for compliance, determining FDA review pathways, and device comparisons.
Key requirements:
Regulatory path and class assignment: Inform users about the available options, for their device.
Accessible product code information: Provide details on FDA product codes (6500+) for relevant selection and comparison.
Multiple product code support: Enable users to add multiple codes, designate a primary code, and provide experts with more information.
Classification bypass: Allow users to skip classification if they cannot identify a relevant product code.
Ideate
Building upon the Navigation/Stepper enhancements, I further explored the 'Classification' section. I developed user flow diagrams, and rapid prototypes for new concepts, facilitating team discussions.
Progressive disclosure concept: This approach guided users through hierarchical steps, presenting in-depth contextual information to inform classification choices, and filter product code options while minimising information overload. An open product code search dialog with additional information was provided as a secondary pathway for users unable to proceed linearly.
Prototyping revealed complexity in handling classification conflicts. The repetition of regulatory path, and class data within product codes indicated potential for automation. Consequently, we shifted away from the hierarchical approach, and explored the open search pathway.
Define and Build
Comprehensive search: We prioritised a comprehensive search interface with detailed product code information, and filters. We automated classification by capturing product code data, and streamlined the workflow . Key features included:
Intelligent search: Word match search, with planned semantic search improvement.
Filtering: Comprehensive filters (class, submission type, medical specialty, device function).
Product code details: Structured, scannable product code information (definition, physical state, technical method, regulations).
Information side-panel: In-app details on classification types, with external links.
Cross-referencing: Product code comparison, referencing their intended use, and indication of use.
Product code management: Add multiple codes, assign primary code.
Automation: Accurate submission path and class assignment via product code data.
Secondary pathways: Bypass confirmation component without code identification, expandable content on zero results, and landing screen.
Measure
I conducted observational user testing across the RegNav stages: Payment, Device Details (About, Classification, Characteristics, Essential Principles Review), and Compliance Plan requests.
The insights were documented in Dovetail and summarised/shared in Microsoft Teams, highlighting Product Code Finder key takeaways.
Dovetail user testing documentation.
Dovetail user testing notes and labels.
key takeaway examples:
The simple product code and word match search is not enough for less experienced users, it would require a semantic search to provide more accurate results when searching from a device description.
There is a distinction between experienced users that already know their product code at this stage, and less experienced users who would search by describing the device.
Needs to be more obvious that you can add multiple product codes and what that means, however there is a distinction between a standalone product and a system configuration.
Consider removing the initial screen, landing straight into the search.
Quote examples:
“I would go with 510K exempt (submission type) for my company. BUT, I would start with the Product Code Finder just to make sure I was right when starting.”
“I saw my product code being populated on the top right, it’s intuitive.”
“I’ll go without using the filter, I don’t feel comfortable… it’s removed a few things.”
We categorised actions into quick fixes and larger features, such as distinguishing standalone products from system configurations, which required more development. The product code finder was used as a marketing teaser, using Amplitude to monitor user activity. These metrics, combined with customer interviews, informed a larger market fit strategy pivot, and roadmap changes.
Compliance Plan
In order to test RegNav's end-to-end customer journey, we needed to create a sample Compliance Plan. Due to resource constraints, we opted for a static version, enabling early testing before building a dynamic online version.
What Is a Compliance Plan?
A medical device Compliance Plan is a documented system to ensure product safety, and regulatory adherence throughout its lifecycle.
Key sections:
Overview: Product details (classification, use).
Standards: Device safety/performance evaluation methods.
Essential Principles: Design/manufacturing requirements.
Product Codes: FDA identifiers for tracking.
Predicates: Legally marketed device for comparison.
Static PDF Version
To understand the core components of a Compliance Plan, the Experts walked me through the Excel version, which combines RegNav AI with their expertise.
Knowledge transfer:
Experts provided detailed explanations of CSV columns and terminology.
Insights into the hierarchical structure of the Compliance Plan content.
Design
Imported CSV data into InDesign, its limitations acted as a valuable constraint.
Limitations forced critical evaluation of essential vs. non-essential information, enhancing our understanding of user needs.
Improving language, and naming conventions across the CSV and PDF versions.
CSV - Sample Compliance Plan.
InDesign build - Sample Compliance Plan.
User Research
We conducted usability testing of the static Compliance Plan with the same Friends & Family network who had previously completed thier 'Provide Your Details' journey within the RegNav platform e.g Chamber Tech' and Participant 2.
key takeaway examples:
Enhance clarity and understanding: Provide educational content, clear explanations, and practical examples throughout the document. Simplify jargon, and technical terms where possible.
Add validation and human touch: Include authoritative statements, references to similar products, and reviewer credentials to build trust. Incorporate photos, and human elements to make the document more relatable.
Provide practical resources: Add legends, guides for interpreting detailed tables, and product codes. Include example Compliance Plans, and predicate device references to demonstrate practical application and accuracy.
Testing labs: More specific information on testing labs, and what they can provide.
Quote examples:
“Needs more specificity about the testing that they can provide. This is pretty general info - if I'm looking for a tasting lab, I know what kind of testing lab I am looking for, this does not tell me that.ˮ
“Something that would fill me with more confidence would be a statement below telling me “this is what we would expect for a predicate device etcˮ - ie. like a Sainsburyʼs shopping list. Put a link to other FDA approved products that are similar to my device, to validate this.ˮ
“Putting a human element into it might help put me more at ease. Maybe say whoever it was reviewed by and click here to see the three decades of experience this person has.”
The static Compliance Plan, despite its limitations, served as a customer-facing deliverable, and played a crucial role in securing our first paying customers.
Market Fit
While our MVP launch gained some startup traction, research suggested a significantly larger market opportunity within the large enterprise segment. We strategically pivoted due to the following key reasons:
Risk mitigation: Strong positive feedback on RegNav's value in risk management (patient, product, liability), being another layer of checks on manual compliance processes.
Customer acquisition: Leveraging the Medical Experts' enterprise network and the Element brand.
Higher revenue: Enterprises developing 30+ products, and will pay 2-3x more for AI extraction of Product-Level Requirements.
Lifecycle support: Opportunity to provide ongoing lifecycle management, including compliance updates and testing lab management.
Personas
Following the shift in target market towards the large/enterprise segment, we updated our user personas to reflect the specific needs and characteristics of our primary audience: Enterprise Regulatory Affairs Professionals. These professionals were characterised by their attention to detail and risk-averse nature, which significantly influenced our product strategy.
Enterprise:
Detail oriented
Cautious
Multi-market
Process driven
Risk-averse
Lifecycle focused
Regulatory consultants:
Experienced
Multi-tasker
Analytical
Non-tech savvy
Resourceful
Relationship driven
The (well-funded) startup:
Time-pressed
Scaling
Cost-conscious
Customer Journey Map
To better serve Enterprise: Regulatory Affairs Professionals, we mapped their end-to-end customer journey, from discovery to ongoing usage, surfacing their actions, goals, and pain points. Based on customer research, key updates included integrating Product-Level Requirements, and adding a future Test Manager step, reflecting lifecycle management needs.
Product - Level Requirements
What problem are we solving?
As part of customer interviews, a recurring concern was the risk of human error in manual compliance processes, especially when dealing with high-volume, complex regulatory Requirements. AI-driven extraction of Product-Level Requirements could provide an additional layer of protection for MedTech.
Key requirements:
Accurate Requirement extraction: Enterprise segment requires AI-driven extraction of Product-Level Requirements.
Manage data volume: Requirements (200+) contain a significant data load per relevant Standard (60+).
Validate applicability: For each Standard, roughly 30% of the Requirements are conditional.
Plan differentiation: The interface must clearly distinguish between standard and enterprise-level plans.
What Are Product-Level Requirements?
Product-Level Requirements are specific conditions a device must meet to comply with a Standard. Standards contain multiple Requirements, but not all apply to every device.
Anatomy of a Standard:
Family - Describes the organisation that built, and maintains the Standard e.g. ISO, IEC.
Number - The unique identifier of that Standard within that family e.g. 60601.
Scope - Describes what the Standard talks about e.g. Medical electrical equipment - Part 1: General requirements for basic safety and essential performance.
Clause - Sections of the Standard outlining Requirements:
Requirement - Specifies the criteria to comply with the Standard.
Condition - Specific conditions under which a Requirement applies. States yes/no whether the compliance with these Requirements is a must or optional.
Anatomy of a Standard and Clause.
RegNav AI Extraction
Accurate Requirement extraction from Standards was challenging for the RegNav engine, due to its limitations in processing unstructured data like bulleted lists, tables, and images, resulting in missing Requirements.
Engine extraction, special characters vs original.
Engine extraction, missing Requirement.
Applicability Step
To analyse the Standards context, and improve Requirement condition identification, the Data Science team used Large Language Models (LLMs) to create an 'engine applicability' step
Engine Applicability step diagram.
Kili Annotation Tool
Another step was added to manually expose, and annotate the extracted Requirements conditions, further enriching the results cache, and improving accuracy.
Overall data extraction steps:
Engine: Extracts Standards, Clauses, and Requirements.
Applicability (LLM): Improves Requirement condition identification and classifies applicability.
Kili integration: Transforms extracted Requirements, Conditions into Kili format, and pushes for manual review/annotation.
Kili extractor: Extracts reviewed annotations from Kili, and makes them available to results cache.
Kili, designed for annotating documents for generative AI projects.
Overall AI data extraction approach diagram.
Ideate
Building on the Premium plan (standard plan), I created user flows, focusing on key timeline events (request CP, receive Standards/Requirements), defining the statuses (draft, requested, complete), and the types of communication methods (email, in-app alerts, progress visuals) to update the user.
Mandatory questionnaire concept: The Data Science team indicated that customers must answer conditionality questions for applicable Requirements, with the number of questions decreasing as the results cache improves. I designed a mandatory questionnaire prototype, integrating navigation updates and progress visuals. Completing it provided a downloadable list of applicable Requirements.
Testing revealed that the sheer volume, and lack of context in the questionnaire created an overwhelming experience, hindering progress. Through collaborative discussions with development, we explored integrating the questionnaire with a dynamic online Requirements experience, removing the need for a dedicated questionnaire build, and allowing users to complete it at their own convenience.
This table outlines the plan status for timeline events, and key concept changes, notably the removal of the mandatory questionnaire, and its integration with online Product-Level Requirements.
Timeline events and status table.
Define and Build
Open conditionality questions: I focused on simplifying the user journey, and providing greater context for applicability questions. This was achieved by:
Online Compliance Plan: A dynamic card view of each Standard, and its associated Requirements, prioritising information hierarchy, and useful filters to manage the volume of the data.
Combining questions and Requirements: Allowing users to progress and complete the questions at their own pace, and presenting them in the context of corresponding Requirements.
Status and notifications: Progress indicators, and communication for customer journey awareness.
Streamlined features: Consolidated questionnaire launcher, allowing users to answer known questions, and skip/share those they can't.
Measure
We received positive feedback validating our approach, and proceeded with connecting the full user journey in development. We also felt confident this design will support future improvements, and future initiatives, such as a Test Manager. User testing key takeaways were:
Structure data with numbering.
Provide contextual materials (e.g., images) for conditionality.
Implement custom filtering for Excel-like views.
Reduce question volume (Improve AI results cache).
Open conditionality questions user testing session.
Conclusion
The online Compliance Plan, incorporating Product-Level Requirements, was successfully delivered to the customer. However, due to a company-wide decision to optimise spending, they had to reduce investment in engineering and design, to extend the runway for market fit.
While I was unable to continue testing, and measuring the immediate impact of the online Compliance Plan. I am confident that the comprehensive research, and the design/development foundations we established, will serve as valuable assets for RegNav's future success in achieving market fit.