Turning a compliance bottleneck into a governed, self-correcting workflow. Designed by Abhishek Dobriyal · Product Designer
ResearchIQ is a data quality and compliance platform built for AstraZeneca's oncology post-marketing research (PMR) program. It gives vendor research agencies a governed way to submit primary market research data, and gives AstraZeneca reviewers a single workspace to validate, flag, and sign off on that data before it reaches the business. This is the story of how it was designed, the decisions behind it, and the difference it made.
Why this needed a designer, not just a form
No shared source of truth
Vendors and reviewers worked off different copies of the same file, with corrections tracked in email threads rather than in the data itself.
Quality checks happened too late
Issues surfaced after a reviewer had already spent time reading the file, not at the point of submission where a vendor could fix them quickly.
No audit trail
Decisions to override a flag, reject a file, or approve with caveats were not recorded anywhere a compliance team could later review.
I worked on this as the sole product designer, embedded with the AstraZeneca reviewer team and the Ipsos-side vendor stakeholders across a long design cycle. The build moved in weekly point-by-point iterations, often from direct client calls and transcribed feedback sessions, which meant design decisions had to hold up against real operational detail almost immediately: wave numbering conventions, specific rule IDs reviewers already used informally, the exact status a vendor is and is not allowed to see.
That pace shaped how I worked. I was not designing from a static spec and handing off a polished file at the end. I was running a continuous design review with the people who would use the tool daily, which meant every surface had to survive contact with a messy, real workflow, not just a tidy Figma version of one.
How I approached the problem
Mapping two incentives before drawing a single screen
Before any UI work, I mapped the existing vendor-to-reviewer handoff as it actually happened: email threads, manually cross-referenced spreadsheets, decisions nobody recorded. That mapping surfaced the real design problem, which was not "build a file upload tool" but "give two users with opposite incentives a shared, visible definition of good data." Framing it that way is what led to the single biggest architectural call on the project: one data model, two permission-aware views of it, so a file a vendor submits is byte-for-byte the file a reviewer opens. That decision made the eventual audit trail trustworthy by construction rather than by policy.
Status taxonomy as a usability finding, not a labeling choice
Early in the build, "Auto-Approved" was visible to vendors, and a client call surfaced it as a trust problem: a vendor was reading an internal reviewer mechanism as a final, authoritative state. I treated that the way I would treat any usability finding from a test session, as evidence the current model was wrong, not evidence the label needed softening. I redesigned the status taxonomy so vendors only ever see "In Review" or "Approved," while reviewers keep the fuller operational picture ("In Queue for Auto-Approval," "Auto-Approved," "Rejected"). Each status is now scoped to the audience it is honest to show, which is a usability outcome dressed up as information architecture.
A component system that absorbs new requirements instead of fighting them
Every new capability, the Rule Library, the PII masking flow, the inline-edit pattern, was prototyped first as a variation on an existing component: the status pill, the stat card, the decision-row pattern, the modal shell. That was a deliberate constraint, not a shortcut. Reviewers had already built muscle memory for how a flag card or an action button behaved, so a new capability that looked and acted like something they already knew needed no separate onboarding, and it meant late-breaking, compliance-driven requirements could be absorbed inside sprint cycles rather than triggering a redesign.
Prioritizing the failure states over the happy path
Once the core flows were stable, I deliberately weighted remaining design effort toward the moments something goes wrong rather than polishing what already worked: a rejected file, a flagged row, a file carrying personally identifiable data. In a regulated workflow, the reject reason, the override justification, and the nudge-vendor message are the interactions that actually carry legal and compliance weight, so they got the same scrutiny most teams reserve for a primary conversion flow.
Two portals, one governed workflow
Where agency partners submit and correct study data
Built for vendor research agencies, such as Ipsos, the Vendor Portal is where a wave of market research data enters the system. It is intentionally narrow in scope: a vendor can submit, see exactly what a reviewer flagged, fix it, and resubmit. It never exposes internal reviewer-only mechanics.
Guided new submission
Starting a submission walks a vendor through brand, indication, wave, and reporting cadence, pre-populated wherever the context already determines the answer. Early iterations asked vendors to pick from several dropdowns, including a "Tumor" field that duplicated "Indication." I removed the redundant field and auto-populated the brand once selected, cutting the form to the choices that actually vary wave to wave.
Reporting cadence now supports Monthly, Quarterly, Adhoc, and Annual, added point by point as the brand team's real reporting patterns came up in review calls, rather than guessed upfront.
Transparent quality scoring
Every file gets a quality score the moment it is processed, visible on the same card the vendor uses to track status. The score is not a black box: opening a flagged file shows exactly which rows and which rule triggered the flag, in the same visual language a reviewer sees, so a vendor is fixing a specific, named problem rather than guessing.
PII detection at the point of upload
When a file contains personally identifiable fields (HCP names, patient names, addresses, dates of birth), the system detects it the moment the file finishes uploading, before any quality check runs. The vendor is asked directly: proceed and anonymize, or reject and re-upload. Choosing to proceed replaces the PII columns, HCP Name, HCP Address, Patient Name, Patient DOB, Patient Address, with consistent alphanumeric identifiers such as HCP-ABC123, applied at the column level so the same person maps to the same ID throughout the file.
This flow went through several rounds of refinement after a client call made the compliance stakes explicit: the anonymized file still needed to behave like any other submission with real quality issues, not a sanitized demo file, and the warning needed enough visual urgency, a blinking, rippling warning icon, that a vendor could not miss it while skimming.
Honest status, always
A vendor only ever sees "In Review" or "Approved." Internal reviewer states, "Auto-Approved" and "In Queue for Auto-Approval," are filtered out of every vendor-facing table, including the submissions list and the dashboard's recent activity. This was a targeted, surgical fix: the filtering touches only vendor-side render functions, leaving the shared data model and every reviewer screen untouched.
Where AstraZeneca reviewers validate, decide, and sign off
The Reviewer Portal is the operational center of the platform: a queue of submissions organized by wave, a rule-driven flagging system, and decision tools, override, nudge, reject, that write directly into an auditable record. Everything a reviewer does here is visible back to the vendor in the right, scoped form.
Wave-organized submission queue
Submissions are grouped by wave, the unit reviewers actually think in, with live counts for what is waiting, what is high severity, and what auto-approved. A toggle switches between "All Submissions" and "Overdue Submissions" without leaving the page, and filters for vendor, tumor area, indication, study type, status, and severity sit directly above the table rather than behind a separate screen.
Flags as a resolvable queue, not a static report
Opening a submission puts the data grid on the left and a live flags panel on the right. Each flag names the rule that triggered it (for example BR-001, "segment values must total 100"), states the problem in plain language, and offers two actions: Override, with a mandatory written reason, or Nudge Vendor, which sends a scoped request back without rejecting the whole file. This panel went through the most iteration of any surface in the product, including removing severity color coding that had started to compete visually with the row highlighting it was meant to support.
Inline correction, mirrored to the vendor
A reviewer can click directly into a flagged cell and correct it in place, the same click-to-edit interaction a vendor uses on their own side. This closed a real workflow gap: previously, a reviewer who spotted an obvious fix had no way to apply it without bouncing the whole file back to the vendor and waiting for a full resubmission cycle.
Insights built for a specific reporting conversation
The Insights tab organizes KPIs by study, PET Study and ATU Study, each with a four-across card grid and a matching set of five-vendor trend lines directly beneath it, mirroring how the client's own internal reporting deck was structured. A single Monthly and Quarterly filter governs every card and chart on the page at once. One metric, intentionally, carries a subtle magenta pulse and a ripple-blink marker, a deliberately restrained way of saying "this needs a look" without adding a button that invites action the data does not yet support.
Rule Library as shared ground truth
Every rule that can trigger a flag is documented in one browsable library, so a reviewer justifying an override, or a vendor trying to understand why a file was returned, is working from the same defined rule rather than a reviewer's personal judgment call.
Three calls that shaped the product
Should vendors ever see "Auto-Approved"?
Auto-Approved started out visible everywhere, including the vendor's own submissions list. It read, to a vendor, as a final, trustworthy state.
I scoped "Auto-Approved" and "In Queue for Auto-Approval" as reviewer-only. A vendor's file in that state simply reads "In Review," because from the vendor's side, it still is.
The vendor portal never implies a decision has been finalized before AstraZeneca has actually finished validating it. Trust in the status label went from implied to accurate.
Where should a PII-masked file actually "live"?
An early version popped a PII warning as a dead-end modal, with no clear answer to "where does the anonymized file go after I click Proceed?"
I made the masked file open as a normal, fully functional submission, identical in the vendor and reviewer view, down to the same quality issues any other in-review file carries, keyed to one shared record both portals open.
PII handling stopped being a special case bolted onto the workflow and became just another submission state, reviewed with the same rigor as everything else.
How much severity signaling does a flag panel need?
Color-coded severity on both the flag cards and the data grid rows created two competing visual systems fighting for the reviewer's attention on the same screen.
I collapsed the grid highlighting to a single consistent maroon, and let severity live only in the flag panel's written detail, not in a second parallel color system.
A reviewer's eye now has exactly one place to assess severity instead of reconciling two color languages, which was flagged directly in client feedback as a measurable reduction in review fatigue.
What the design was worth
The clearest win is procedural rather than purely visual: a decision that used to live in someone's inbox now lives in the product, attached to the file it concerns, permanently. That alone converts a hard-to-audit email trail into a queryable compliance record, which matters more to a pharmaceutical client than any single interface choice.
The modelled time estimate assumes a prior average of roughly 25 to 35 minutes of manual cross-referencing per flagged file, against a current flow where the relevant rule, the flagged rows, and the resolution options are all visible in one panel without leaving the submission. Applied across a typical monthly wave volume across five vendor lines, that is a meaningful recovery of reviewer hours, though AstraZeneca has not yet run a formal time-and-motion study to confirm the figure.
The signed-off design
What I'd carry into the next one
The most valuable design work on this project was rarely visual. It was deciding what a status word is allowed to mean to which audience, and building enough structural discipline into the component system that a late, specific, compliance-driven requirement, like PII masking, could be absorbed without inventing a second design language. A platform that handles regulated pharmaceutical data has to be legible to an auditor as much as to a daily user, and that constraint sharpened almost every decision above.
If I were starting the next phase, I would push earlier for a formal time-and-motion baseline before the tool existed, so the impact section above could report a measured number rather than a modelled one. The direction of the result is not in question. The precision of it is the next thing worth earning.
