Smart IRB Portal
Team & Roles
My Responsibilities
Collaborating with cross-functional teams (stakeholders, business analysts, devleopers) to ensure regulatory compliance and accessibility.
Conducting primary and secondary research to understand the needs of researchers, IRB officials, and institutions.
Designing intuitive workflows to simplify reliance agreements and creating wireframes, prototypes, and high-fidelity UI designs for the reliance interactions.
Enhancing user engagement by refining navigation, content structure, and interactions.
Client
Project Overview
SMART IRB (Streamlined, Multisite, Accelerated Review of Trials) is a platform designed to simplify and accelerate the Institutional Review Board (IRB) review process for multisite human research studies. It provides a flexible framework for institutions to rely on a single IRB for ethical review, reducing administrative burden and ensuring compliance with federal regulations.
16 Months
1000+ Screens
Web Application
Tools
— Problem Statement —
“The team at Harvard Catalyst receives a lot of emails asking for help in this process. Axle has been brought on to address the following problem, how might we streamline the process and reduce the amount of support tickets the Harvard Catalyst support team receives? ”
Scope
There were two systems the SMART IRB agreement relied on for two functions–Joinder, through which institutions entered institutional information and signed the SMART IRB Agreement, and the Online Reliance System (ORS), through which IRB reliance arrangements under the SMART IRB Agreement were documented on a study-by-study basis.
My objective was to improve the user interface and user experience by designing a more efficient, flexible, and user-friendly platform, thereby facilitating the use of a single IRB (sIRB) for multi-site research.
Objectives
Our new interface provides the following incentives for Smart IRB users to adopt the new system as a centralized solution for all things Smart IRB:
Coordinate and Communicate: For the reliance requests, users involved in the study can coordinate and communicate with users from other institutions. This feature addresses users having to go through the process of finding the right person from another institution, their contact information, and coordinating over endless email threads.
Digital Signatures: All forms and signatures will be handled digitally and stored within the platform.
Request History Log: There is a history log of all major changes allowing users to follow along through the process or trace back changes.
Reliance Request Data: All documents, study details, personnel information, etc can be found under the reliance request, instead of being scattered across different email threads and cloud/local storage solutions. It eases the sharing process for requesting revisions, sharing/updating documents, and obtaining signatures in a timely manner.
Users
Researchers – Principal investigators and research teams who need IRB approval for multisite studies.
IRB Officials & Administrators – IRB staff managing reliance agreements, coordinating reviews, and ensuring compliance.
Institutional Officials – Compliance officers and administrators overseeing research ethics and regulatory adherence.
Persona: IRB Administrator
Persona: Principal Investigator
Persona: Director of Research Compliance
The Solution
old vs. new designs
Old Reliance Request Screens
New Design System
A peak showing the logo, colors, typography & buttons
Interactive Prototype: Submitting a reliance request
The Process
so many iterations
This case study provides a high-level overview of the design process. A detailed presentation, elaborating on the project's design steps and considerations, is available upon request. It covers the next steps as the reliance request created in the prototype above goes through the hands of different users and changes in states until approval.
A sneak peak into the iterations of reliance request
V1: New Reliance Request workflow was originally a slideout pane with 5 tabs.
V2: Full page for reliance request. Table view to accomodate multiples sites. Button to add new site. Continue Button. Condensed site navigation & accordion secondary navigation.
More before/after iterations of reliance request
New Add Sites Screen: The new request activity page has a different secondary menu that accommodates the activities that take place once the request is submitted.
Old Reliance Dashboard: The old dash only supported edit and delete for quick actions to the reliance request.
New Reliance Dashboard: The new dash has an icon that drops down into a list of quick actions a user can take. The list of actions includes add sites, edit protocol number, edit NCT number withdraw request, and add to favorites.
Old Request Activity: The page has a table listing all sites and their reliance status.
New Request Activity: The new request activity page gives a visual overview of the status of all sites involved in the study. The sites table allows users to view/download determination letters for sites that are successfully "relying" and also directly message point of contacts for the sites to follow up on their reliance status. I also added a request history of changes made to the request after request creation, allowing users to easily stay informed regarding the request.
Old Request Summary: The flow the Institution's PI see's for the submitted request is the same as the flow for submitting a new request. This created an unnecessary amount clicks needed to review the request, with the details spread out across 6+ screens.
New Request Summary: 6+ pages were condensed into 3 pages that all fall under study details. The pages were grouped into request summary (providing all the study details), supporting documents (all attachments), and sites & activities.
Old Add Sites Screen: The secondary navigation was the same for creating a reliance request and the process that takes place after submission.
Impact
Cohesive Portal: Previously there were separate interfaces for institutions and investigators. The new portal includes both on the left side, allowing a more cohesive experience that doesn’t involve separate account creation.
Centralized Tool: Previously users had to communicate about reliance requests externally via email. Now there is a discussion feature allowing communication within the portal and a request history feature allowing users to track discussions/changes around the reliance request.
Admin: An institution’s admin user can grant certain permissions to individuals that are a part of their institution. This allows them to designate users to approve requests on their behalf if they are more hands-off.
aesthetic & minimalist design: Compared to the old bare bones design, the new portal has a cohesive design system and interface.
Clear call to actions: There are clear call to actions for a user to create a new request, save, exit, upload, etc.
Reliance Dashboard: Previously the dashboard was a table of institutions with some relevant information. The new dashboard allows users to take actions on the requests in the table and open them.
Takeaways
Goverment redtape sucks: It was impossible to do vital user research and testing activities. User research is crucial in understanding the target audience's needs, behaviors, and pain points. I was limited to information shared by the client and insights derived as a part of the peanut gallery from the focus groups the client conducted.
Iterative Design Process: There were so many iterations in the design, following my presentations to the client and their feedback and changes to the requirements.
People are visual creatures: The requirements gathering and designing process went hand in hand for the new features the client didn’t even know they wanted.
Cross-Collaboration is key: Throughout the project I had close and consistent contact with the business analyst in getting up to speed on the subject matter and refining the designs to address the requirements. The developers were also in the loop with each design iteration so the designs don’t spiral out into something unfeasible.