SafeInsights, Rice University
Designing a 0→1 research proposal system for multi-stakeholder collaboration, spanning initial proposal, code submission, agreements, review, and outputs.
Status: Live
Designing a 0→1 research proposal system for multi-stakeholder collaboration, spanning initial proposal, code submission, agreements, review, and outputs.
SafeInsights is a secure research platform that lets researchers analyze sensitive data in a controlled environment while maintaining strict privacy and compliance standards.
When I joined this project, there was no defined workflow for how researchers and data partners should collaborate, no shared process, no clear expectations, and no precedent to build from.
I led the end-to-end design of a multi-step, multi-user proposal and review system, turning that ambiguity into a structured, iterative workflow built for both technical and non-technical stakeholders.
Three problems. One platform built from scratch.
Researchers studying K-12 outcomes couldn't access the data they needed. SafeInsights was built to close that gap, but as a 0→1 product, there was no playbook to borrow from. Every part of the system, what to submit, how to evaluate it, how to build on it, had to be figured out through trial and error.
K-12 research data is valuable, but nearly inaccessible.
Legal barriers like FERPA kept researchers from accessing sensitive K-12 datasets, even when data partners were willing to share.
A platform to bridge this didn't exist yet, so there was no defined process for submission, evaluation, or communicating a decision.
Researchers had no clear path to submit or iterate on their proposals.
Researchers are used to writing code against data they can see. Here, they had to propose and code against a dataset they'd never access directly.
No signal for what an approvable proposal looked like, and no guidance on how to write code from sample data.
Data partners had to evaluate requests without a shared framework or shared expertise.
Data partners were also new to this. Each was independently figuring out what to set up and what to require for approval, with staff at varying levels of technical expertise.
No standardized evaluation framework. The real challenge was building guardrails and frameworks that worked across partners, not just evaluating SafeInsights designs and interactions.
Redesigning the proposal workflow as an iterative, multi-user system.
Building trust before collaboration begins.
- Researcher's professional profiles is submitted as a part of proposal submission to data partners.
- Platform, study, and individual-level agreements make accountability explicit for every stakeholder.
Breaking the proposal into guided, non-linear steps.
- Split the process into four steps for researchers (set up study, submit proposal, submit code, verify outputs), mirrored by three matching review steps for data partners.
- Action banners show exactly what's blocking progress and what to do next.
- Researchers can loop back to their code anytime, with every past output, reviewer feedback, and resubmission note on one page to guide the next version.
An outputs history that pairs every result with its reviewer feedback and resubmission notes, all on one page.
Collaborative feedback and iteration system.
- Reviewers write one shared decision together in real time, with live presence and autosave, so the Research Lab gets a single, unified response.
- Researchers resubmit with a note that answers the feedback, and each round is saved as a new version.
- Feedback and resubmission notes stack into one version history, so both sides can see how the work evolved until the banner confirms approval.
AI-assisted code creation and evaluation.
- Claude is integrated directly into the IDE, so researchers of any skill level can get help writing and debugging code
- A preloaded sample dataset lets researchers test their code safely before submitting
- AI-generated summaries and automated security scans let data partners review code quickly and confidently
(AI summary + security scan + checklist)
So how did we get here?
How I approached designing a system that didn't exist
Researchers were new to a secured dataset model, one where data is never directly shared with them. Data partners weren't a uniform group either: each had its own evaluation criteria, staff expertise, and capacity.
The challenge was designing a flexible system that could hold variation on both sides, surfacing mental models gradually, keeping engineering sustainable through phased releases, and earning clarity before designing for complexity.
- Research Lab: multiple researchers, one project admin as accountable decision maker.
- Data Partner: independent partners, each with their own processes and capabilities to support research.
- SafeInsights: building the platform and ecosystem to support this secured, large-scale research.
- Step 1: Proposal submission: intent, datasets, coding language, profiles
- Step 2: Data use agreements: review and sign
- Step 3: IRB approval: ethical review signed off
- Step 4: Code submission: run against sample dataset
- Step 5: Evaluating results: output reviewed, iterate or close
Steps define the user journey. Phases define how we built it.
Not defined upfront. Earned through the work.
What we learned from concept and usability testing sessions.
How I researched
I prototyped the concepts and wrote the research questions ahead of testing. A team including a PM, researcher, and senior designer developed the moderation script and handled recruitment.
I sat in on 8 open-ended usability sessions with 4 researchers and 4 data partner staff, each lasting 90 minutes and deliberately unstructured to capture what people surfaced unprompted. I then led affinity mapping and wrote up the findings that shaped the next round of design.
Once we began implementing changes, we ran internal testing across system validation, QA, and usability to ensure the solutions held up end to end before moving forward.
Usability testing session.
Affinity mapping the insights to identify patterns.
Key insights
Trust is critical, but the burden of proving it needs to be shared.
Data partners named trust as their #1 factor for working with a researcher, but didn't want to verify it themselves. They relied on institutional signals: IRB approval, affiliations, resume, past history.
The proposal workflow wasn't linear, but the early design suggested it was.
Participants rejected the progress bar, not because it was confusing, but because it didn't reflect reality. Proposals loop back and forth, and steps overlap.
Both sides wanted control over collaboration, but defined it differently.
Reviewers wanted clear control over who could view and resolve feedback. Researchers wanted clarity on what was asked and by whom. Many data partners collaborate internally before sharing one response.
Technical capability was uneven on both sides.
Researchers had varying coding expertise. Reviewers were domain experts, not engineers, and weren't fully equipped to evaluate code for safety and alignment.
How each solution evolved
Trust was the top factor in a data partner's decision to work with a researcher, but partners didn't want to spend time verifying researchers themselves. Four interlocking trust signals solved this, each removing a different kind of uncertainty.
Researcher profile
Credentials, affiliations, and history surfaced as a popover directly within the review page, so trust signals travelled with the proposal instead of sitting in a separate section.
IRB protocol
An Umbrella IRB gave data partners a familiar ethics checkpoint while letting in-scope studies skip a separate institutional approval.
Roles & permissions
Administrator and Contributor roles made accountability visible through navigation itself, your access showed your role.
Evaluation checklist
A binary Yes/No checklist, visible to both sides throughout, replaced subjective review with a shared standard.
Five steps, multiple stages each, two user types experiencing it differently. The challenge was communicating that structure clearly without overwhelming a first-time user.
Study table & progress tracker
V01: Separate stage/status columns. Clear per-row, but no sense of the full lifecycle.
V02: Added an expandable timeline. More detail, but cognitive load rose and back-and-forth stayed invisible.
V03: Combined stage/status into one label, added a five-step visual tracker plus a status banner at every stage.
Without structured feedback, the whole proposal lifecycle broke down. The system needed to handle quick clarifications and complex reviews, and scale to multiple reviewers working asynchronously.
From inline comments to multi-reviewer threads
V01: Inline, anchored comments, Google Docs style. Precise, but built for one reviewer only.
V02: Consolidated panel with three decision options. Faster, still single-reviewer.
V03: Multi-reviewer internal thread. Deliberation stays internal, researcher gets one clear reply.
Researchers needed to write and submit code, reviewers needed to evaluate it, and both experiences had to stay connected without becoming one overloaded screen. Of the four solution areas, this one went through the most rounds of testing: two full usability studies across two design directions before reaching a final state.
Testing the original design
The original flow offered two paths, launch the IDE, or upload files directly, split across a path-selection screen and a code management screen. We tested it with real researchers to see where it broke down.
Exploring the fix, internally
Two directions were explored internally before testing again: a "2 options" layout with progressive disclosure, and a "3 options" layout that separated the paths further and added a recommendation. Both increased the sense of a long, effortful process, and neither addressed a real business need: the product wanted researchers to lean toward the IDE, not just be offered it as an equal choice.
A second round of internal exploration compared two more targeted directions head to head.
An explicit upfront choice between "Write and test in the IDE" and "Upload your files," with the IDE card's capability list surfaced before the researcher clicks anything.
Tradeoff: required more reading before any action, and previewed a decision (what to do after uploading) that didn't need to be made yet.
One screen handling both the IDE and upload paths, no upfront branching, researcher lands directly on a file management view and takes action immediately.
Tradeoff: simpler and lower cognitive load, but the IDE's value became almost invisible, buried in a small info banner easy to miss entirely.
We went with the unified approach for its lower cognitive load, but patched its main weakness directly: added visible context calling out the IDE's example data and starter code upfront, so the option researchers were being steered toward wouldn't get lost in a quiet banner.
Testing the refined design
The refined design was tested again in a second usability study, this time checking whether researchers understood the IDE flow, the main file template, the separation between the IDE and the platform, and what happens if a colleague has already claimed the IDE.
Final Solution
End-to-end flows designed, tested with users, and shipped.
Four solution areas — refined, tested, and built in collaboration with engineering.
- Establishing Trust Researcher profiles surfaced in context as a popover, Umbrella IRB reducing approval friction, role-based permissions visible through navigation, and a shared evaluation checklist setting expectations on both sides
- Proposal Workflow Simplified dashboard combining stage and status through language, a five-step progress tracker with visual icons and colour, and status message banners at every stage telling users where they are and what comes next
- Collaborative Feedback Multi-reviewer internal thread with individual leanings, one designated reviewer synthesising collective feedback into a single consolidated response shared with the research lab
- AI-Assisted Code Integrated IDE with AI code generation for researchers, and inline code with AI summary, automated security scan, and structured Yes/No evaluation checklist for reviewers
What I learned
Designing SafeInsights from the ground up taught me things that no brief could have anticipated. Here are the three that will stay with me.
Ambiguity is an invitation, not a problem
Vague briefs created space for design to shape the product, not just execute on it. Asking the right questions early became one of my most valuable tools.
Designing a system means designing for variation
Flexibility and consistency had to coexist across two very different user types. That tension sharpened my thinking at every decision point.
The product reflects how it was built
The most coherent parts of SafeInsights were designed in close collaboration with engineering, product, and legal — when those conversations happened early, it showed.
Three things I'd do differently from day one.
Every complex product reveals its gaps under pressure. These are the decisions I'd make earlier — not because anything went wrong, but because making them sooner would have sharpened the work at every stage after.
-
01Set up accessibility guidelines earlier in the processFormalizing accessibility from the start would have avoided retrofitting components later and ensured consistency across the system from the first build.
-
02Involve stakeholders earlier to uncover edge casesResubmission paths, multi-reviewer conflicts, and IRB exceptions all surfaced late. Earlier mapping sessions would have exposed these scenarios sooner and reduced mid-build complexity.
-
03Document design decisions as they happen, not afterA lightweight decision log maintained throughout would have improved alignment, faster handoffs, and long-term scalability.
