Who’s the client

More than 90% of the medications on the market are accessible to all of us because of Medidata. They serve tens of millions of patients all over the world.

They have 50+ separate products, each solving its own problem — payments, document management, medical images, and more.

Problem to solve

We had at least 9 products that were using completely different, often hard-coded, solutions for previewing documents and images.

So I had to unify it.

This is how old solutions looked like

As said, it was at least 9 different products — and each one used a different solution to a similar problem.

A legacy release-form viewer with Redact & Edit controls
Release form viewer
A legacy viewer for scanned tickets, with only a Cancel action
Scanned image viewer
A legacy .docx viewer with an Open edit mode action
Document viewer
A legacy medical-imaging viewer with a sign-off flow and side forms
Imaging + parallel forms
Four of the existing solutions — each a separate product, each with its own chrome, controls, and behaviour for the same underlying need.

What were my actions

  1. Problem approached & formulated
  2. Collected some of the use-cases
  3. Interview with the IDS Lead (to see if this was a problem to be solved)
  4. Collected even more use-cases
  5. Found similar solutions in other tools globally
  6. Designed & iterated with the IDS Lead
  7. Tested everything with users, for each product that needed the solution
  8. Presented & applied feedback
  9. Supported development

The problem wasn’t that teams built bad solutions. It’s that every team had to build a complete solution from scratch, for the same need.

Collecting existing use-cases

Before designing anything, I audited every place in the platform where a file needed to be viewed. Most of the use-cases were: reviewing contracts, reviewing medical images, countersigning consent documents, previewing dataset schemas, and similar.

I then divided all the use-cases into three groups:

  1. User needs to check a file without interrupting what they’re doing.
  2. User needs to open a file while simultaneously completing a task — filling a form, confirming answers, leaving a query.
  3. File opening triggers a multi-step flow.
A board sorting every use-case by function: Create/Upload, Preview, View, Comment/Meta data
Here I sorted all the use-cases by their function.

Analysing external platforms

I then analysed multiple platforms: Google Drive, Notion, Figma, DocuSign, Dropbox, Box, Linear, GitHub, Cerner, Epic, and others.

Most either opened files in new tabs (breaking context entirely) or used modals — constrained, and incompatible with the parallel-task use-case. None had a clean answer for the regulated, multi-product environment we were working in.

A teardown of how Google Drive and Google Docs handle previewing, viewing, metadata and comments
How others do it — a teardown of comparable patterns.

What I found

Navigation hierarchy

The existing navigation hierarchy had four levels: parent pages, child pages, side panels, and modals. A file viewer doesn’t fit cleanly into any of them — too heavy for a modal, too temporary for a page.

The insight

The insight was to stop thinking about this as a UI component and start thinking about it as a navigation object — one that can be invoked from anywhere in the system and closed without affecting the user’s current place in the workflow.

We didn’t need a better document viewer component. We needed a new type of surface — one that could hold any content, open from anywhere, and be closed without side effects.

Two modes, one pattern

If the pattern was a navigation layer and not a file viewer, then the content inside it didn’t have to be a document. It could be anything a designer needed to place there — a custom workflow, a dataset mapper, a countersign flow — while using the same underlying navigation model as the file viewer.

So I came up with two variants for the component:

  1. Media viewer — documents and images, with built-in controls.
  2. Custom content — a blank canvas inside the pattern shell, for product teams to build into.
Media viewer mode — numbered component zones, with the four scrolling modes (vertical, page, horizontal, wrapped) below
Media viewer mode — the component zones, plus the four scrolling modes: vertical, page, horizontal, and wrapped.
Custom content mode — the shared shell with title, status, captions and a custom control, around a blank content area
Custom content mode — identical shell, blank interior for teams to build into.

The pattern can be invoked from anywhere in the system: from an overview page, a child-object page, a side panel, or from inside a modal window. Opening it never navigates the user away from their current context.

Then, I made a decision tree

A pattern without clear constraints becomes a crutch. The rules below came from testing the pattern against each of the nine use-cases — not written upfront, but earned.

When to use
Quick reference without disruption
User needs to consult a file while staying in their current task — context stays intact.
File + parallel task
User needs to view a document and complete an action at the same time — filling a form, confirming answers, raising a query.
Fast actions on the file
Print, download, or annotate, available immediately inside the viewer — no extra navigation.
Custom flow, same nav behaviour
Any multi-step workflow that needs to open above the current context and close without side effects. Use custom content mode.
When not to use
Complex file editing
If the user needs to make substantive edits, open a dedicated editing tool. The viewer is for viewing.
Long multi-step workflows
If the flow exceeds 3–4 steps or needs its own sub-navigation, a dedicated page or section fits better.
The file is the destination
If the file itself is the destination — not a reference — a full page view is more appropriate than the viewer.

Hardest decision

The easy path was to build a better document viewer. I argued instead for a new navigation object — a named layer in the platform’s hierarchy that could open from anywhere and close without disrupting the user’s place. It was a bigger commitment and a harder sell, and it’s what turned a viewer into something the whole platform could reuse.

Outcomes

1 solution for 10+ products
replacing the fragmented, hard-coded viewers that teams had each built from scratch
4+ new products
adopted the pattern after it was released