Prototyp
Turning an AI algorithm with no interface into a review tool proofreaders could trust
I designed the document review experience for a working AI algorithm to streamline claim verification, surface matched sources, and cut manual searching during pharma proofreading workflows.
Built with
Role
Product Designer (UX/UI)
Context
Internal pitch — Pharma Advertising Agency
Methods
Secondary Research
Comparative Analysis
User Flow Mapping
Mid-Fi Prototyping
Team
Developer
Agency Leadership (multiple)
Overview
Streamlining claim checks proofreaders would normally do by hand
Prototyp is an AI-powered document review companion for pharmaceutical proofreaders and editors. Users verify claims and match new content against old to reach approval avoiding manual searching. By using AI assistance, users compare documents faster to reach sign-off, receiving matched content based on their claims.
The Impact
I joined an internal pitch at a pharma advertising agency where a developer had built a working AI matching algorithm with no UX or UI. I owned the product experience end to end, from research and user flows to a clickable prototype, on the agency's pitch timeline.
The challenge was defining how automation could support proofreaders without disrupting a highly regulated review process
The pitch was well received and earned a referral to a second company. I then narrowed the concept based on stakeholder feedback, refocusing it on document matching.
Problem
How might we free proofreaders and editors from manual search so they can focus on the judgment pharma review actually requires?
Hypothesis
If we integrate AI directly into the existing proofreading workflow, we can reduce the time spent manually searching historical documents without disrupting the human review process.
Research
Insight #1: Existing Tools Were Not Built for This
I gathered these insights through comparative analysis of existing tools and conversations with a teammate who knew the reviewer workflow firsthand. Proofreaders and editors use project management and document editing tools like Workfront that were designed for general workflows. None of the tools in their existing process were built to handle the specific demands of pharmaceutical claim verification.
Insight #2: The Manual Search Was the Biggest Time Cost
The current process required pulling previous brand campaigns individually and manually cross referencing language to determine if new claims would pass regulatory approval. The volume of documents involved made this the most time consuming and error prone part of the entire workflow.
Insight #3: AI Integration Had to Feel Like a Natural Extension
For adoption to work, the AI could not disrupt the existing workflow. Prototyp needed to slot into the process at the exact point where manual searching happened, replacing that step without requiring users to change how they worked around it.
User Flow
User Flow (Current)
Design Guidelines
Minimize Disruption
Fit into the existing process, not around it
Build Trust Through Transparency
Show users why a match was surfaced, not just that one was found
Design Decisions
Replacing manual search with a tool that surfaces the source
Defining the MVP
I mapped the user flow, which revealed the full scope of what Prototyp could be, from document upload to matching to editing in a single platform. I compared Adobe Acrobat, already embedded in the proofreading workflow, and Grammarly, for how it organizes views and surfaces results, which gave the UI a foundation that felt like a natural extension of what users already knew.
Initial User Flow (Using Prototyp)
Iterations
Design Trade-Off
During early concepting, the sidebar was scoped to support multi-brand navigation and recent task recall within a single client account. Following internal feedback, I deprioritized the feature because the product was being pitched directly to individual pharma companies. I removed the sidebar to keep the scope tight for the pitch, with the feature flagged for post-MVP consideration once client engagements were established.
Concept Pitch
I presented the clickable prototype I designed to a pharmaceutical executive as part of an internal pitch, resulting in positive feedback and a referral to pitch the concept to another company. Following the presentation, a stakeholder recommended narrowing the scope. The original all in one platform vision would focus on what Prototyp did best, automating the document matching process. Document editing would remain in existing tools, repositioning Prototyp as a companion rather than a replacement.
User Flow
Before Pitch
After Pitch
Stakeholder Feedback
Repositioning a platform pitch as a companion, not a replacement
Two-System Approach
The team aligned on Prototyp operating as a separate but complementary system. Prototyp would own only the matching and review experience. No comments or annotations would live in Prototyp. I removed the editing toolbar from the document view and the comment count from the directory so the interface reflected that split.
User Priorities
A critical insight from the session was how reviewers actually approach a document. The primary questions are always what’s new and what’s different. This became the foundation for how matched claims and claims drift were surfaced for the interface. I restructured the claims panel so each claim sits under its source ID, letting reviewers scan for what changed without opening each match.
Scoping the Match View
Feedback on the match experience indicated that reviewers needed a split screen to compare documents side by side with historical claims, a zoom tool, and the ability to drag across the screen. Nothing beyond that. The feature set was kept deliberately minimal to support focused reviewing only. I consolidated zoom and page controls into a single bar and added a hand tool for dragging, cutting everything else from the view.
Scoping the Data Model
Content and claims data was specific to each individual asset rather than aggregated across a job. The job code was established as the primary identifier, with edit functionality built into Prototyp to account for naming discrepancies.
Final Designs
Cutting the interface down to matching and review
File Directory
Before
After
Document View
Before
After
Concept Validations
Confirming the AI could earn a place proofreaders would trust
The Core Direction
The developer's AI matching logic, paired with the review experience I designed, correctly surfaced historical claims against new documents. This validated the core direction: AI-assisted verification could sit inside the existing review process without replacing human judgment.
The Need
The stakeholder confirmed that nothing comparable to Prototyp existed, and that it would be effective at solving the problem it was built for.
Key Takeaway
Knowing where automation should stop was the design problem
Designing for a regulated industry taught me that the hardest UX problem wasn't the interface. It was knowing where automation should stop and human judgment should begin. That question shaped the biggest decisions, from the original all-in-one vision to the scope narrowed after the pitch. Getting that balance right wasn't a constraint on the design. It was the design problem.
Next Steps
Taking the concept to high fidelity
The project ended at mid-fidelity. To carry the concept further, I took the UI to a defined high-fidelity visual style on my own.
High-Fidelity Design
After exiting the project, I created a high-fidelity version on my own, drawing inspiration from modern SaaS applications built to manage large volumes of information.
Visual References
Since Prototyp sits in the data management SaaS space, I looked at how established products, Notion, Mercury, and Airtable, structure their directory layouts. All three converged on a similar pattern, which signaled it was an expected convention for this kind of tool, not just a stylistic choice. That pattern also lined up closely with Adobe Acrobat, a tool proofreaders already use daily, so adopting it meant less relearning and more immediate familiarity for Prototyp's actual users.
