Prototyp
Turning working AI code into a product experience proofreaders never had
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
User Research
Comparative Analysis
User Flow Mapping
Lo-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
Developed as an internal pitch at a pharma advertising agency, evolving from working AI code into a human-centered product experience to fit the agency's pitch timeline.
The challenge was defining how automation could support proofreaders without disrupting a highly regulated review process
Following feedback after the original pitch's positive reception, the concept scope was narrowed to focus on maximizing impact.
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
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
Turning manual search into a matching tool that surfaces the source
Defining the MVP
Mapping the user flow revealed the full scope of what Prototyp could be, from document upload to matching to editing in a single platform. Comparing Adobe Acrobat, already embedded in the proofreading workflow, and Grammarly, for how it organizes views and surfaces results, 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, the feature was deprioritized because the product was being pitched directly to individual pharma companies. The sidebar was removed to keep the scope tight for the pitch, with the feature flagged for post-MVP consideration once client engagements were established.
Concept Pitch
Turning a platform pitch into a companion, not a replacement
The working prototype was presented 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
After
Stakeholder Feedback
Turning a platform pitch into a companion, not a replacement
Two-System Approach
The team aligned on Prototyp operating as separate but complementary system. Prototyp would own only the matching and review experience. No comments or annotations would live in Prototyp.
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.
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 only reviewing.
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
Post Pitch Update
File Directory
Before
After
Document View
Before
After
Concept Validations
Confirming the AI could earn a place proofreaders would trust
The Core Direction
The AI matching logic, refined throughout the project, 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
Communication is the Foundation for great projects
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
Concept Refinement
The next phase is moving the UI from mid-fidelity wireframes to a defined high-fidelity visual style.
Hi-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.
