Submission Management
Confidential Client — Enterprise RegTech, Life Sciences Sector
Role: Sole Product Designer | Type: 0-to-1 Feature Design
Due to a strict NDA, proprietary UI designs cannot be shared publicly. This case study focuses on the design decisions, interaction logic, and strategic vision behind the feature. Interface designs and a prototype walkthrough are available during a live interview session.
A regulatory submission isn't a single action. It's a process with dozens of states, dozens of countries, and zero margin for error.
08
01
Proof of Concept
The first version had one purpose: an internal C-level presentation to decide whether to continue funding the product. The design needed to demonstrate a viable concept, not a complete system.
The flow was intentionally minimal. Users could create a submission, select a country and submission type, add articles, give it a name, and start. Once started, the submission showed four predefined workflow steps: Preparation, Submission, Decision, and Release, with the ability to add tasks manually to each step and mark them complete. Simple, demonstrable, enough to show the concept worked.
It did. The product received approval to continue.
.png)
02
MVP and Workflow Templates
The MVP introduced the problem the proof of concept had deferred: regulatory submissions follow recognizable patterns, and asking every team to build their workflow from scratch for every submission was the wrong answer. It wastes time, introduces inconsistency, and creates no institutional memory across a portfolio of hundreds of submissions running in parallel.
I sourced domain knowledge directly, working with experienced regulatory affairs consultants to map what real submission workflows look like across different complexity levels. This produced three ready-to-use templates:
Simple: two steps, minimal tasks, designed for low-risk or minimally regulated markets where the regulatory pathway is straightforward.
Standard: the most common pattern, covering mid-complexity submissions with a full preparation, submission, review, and decision cycle.
Enhanced: a sophisticated multi-step process for highly regulated markets where submissions require extensive documentation, authority interactions, and multi-phase decision cycles.
Each template is fully previewable before selection, users see all steps and tasks before committing. From the preview they can switch templates, customize freely by renaming, removing, or adding steps and tasks, or bypass templates entirely and start from a blank structure.
One design decision in the template system required sustained pushback to implement correctly. The rule is once a submission starts, steps lock as compliance records. Tasks within each step remain flexible throughout the submission lifecycle.
This distinction is not arbitrary. Steps define what the submission did; they are the legal structure of the process. Tasks define how the work is organized; they are the working tool. A compliance body auditing a submission needs to see that the required phases happened in the correct sequence. They do not regulate how a team internally organizes their daily tasks within each phase. Locking steps while keeping tasks flexible reflects how regulatory compliance actually works, not just how software is typically built.
Getting this implemented correctly required active involvement through multiple QA cycles. Template columns were initially built to scroll as a single page, I pushed back until each step column scrolled independently so the step header remains visible as tasks scroll within it. A rename button on step and task labels was removed on the assumption that users would discover inline editing, I pushed back until it was restored because an affordance that requires discovery is not an affordance. When a new step was added at the right edge of the template, there was no auto-scroll to reveal it, I pushed back until the interface showed users what they had just created. These are not cosmetic details. They are the difference between a feature that gets used and one that gets abandoned after the first attempt.
03
Document Management and Conflict Resolution
The team raised one question about document handling: what happens if two uploaded files have the same name?
I started designing for that case and kept going. Documents in this system can be attached at two levels: directly to a submission or to a specific task within a workflow step.
A single document can be linked to multiple tasks. Linking, unlinking, and adding task connections can be managed after upload from a dedicated document tab, not only at the moment of attachment. The full problem space turned out to be significantly larger than the question that started it.
Six distinct conflict scenarios can occur across a bulk upload: two files in the same batch share a name, two files share content but have different names, an uploaded file has the same name as one already in the submission, an uploaded file has the same content as one already attached and linked to a task, an uploaded file has the same content as one already attached but not linked to any task, and combinations of the above across a large batch.
The wrong answer was holding the entire upload hostage until every conflict was resolved. A regulatory team uploading fifteen documents for a complex submission should not have to resolve one naming conflict before any of the other fourteen files can be saved.
The solution was a per-row resolution interface. After upload, documents separate into clean rows and conflicting rows. Each conflicting row shows its specific issue and its specific resolution options.
A duplicate name within the batch offers renaming, removing, or attaching both anyway. A file that already exists in the submission and is linked to a task offers use the existing file with a tooltip explaining that the existing file will be linked to the new task rather than creating a duplicate, skip, or attach a copy. A file that already exists, but the current upload has no task context, removes Use Existing option, because there is no task to link it to in this upload; the choice is to skip or attach a copy.
As each conflict resolves, its row collapses to a resolved state. The primary CTA updates dynamically "skip issues and attach N files" where N reflects the user's current decisions in real time. If all files have conflicts and none are ready to save, the CTA becomes "resolve issues to continue," making clear that there is nothing to skip past.
The document tab gives users a structured view of every document in the submission: file name, linked tasks, file type, and attached date, each functioning as both a filter and sort. From this tab users can manage task links at any point in the submission lifecycle: adding tasks a document should be linked to, removing existing links, or linking a document that was originally attached at the submission level to specific tasks as the workflow develops. This makes document management an ongoing activity rather than a one-time upload decision.
The principle throughout: the conflict is with specific files, not the entire upload. Do not restrict users beyond what the actual problem requires.
Document Conflict Resolution
How the system handles each scenario
Scenario 1
Two files in the same upload share the same name
Options
Scenario 2
Two files in the same upload share the same content but have different names
Options
Scenario 3
Uploaded file has the same name as a file already in the submission
Options
Scenario 4
Uploaded file has the same content as an existing file that is linked to a task
Options
*Existing file will be linked to the new task instead of creating a duplicate
Scenario 5
Uploaded file has the same content as an existing file that is not linked to any task.
Options
*"Use existing file" is not available. There is no task to link it to in this upload
Scenario 6
Multiple conflicts across the same batch
Options
Each conflicting file is handled individually per the scenarios above.
The primary action updates dynamically.
Where N reflects resolved decisions in real time.
If nothing is ready to save, the button is"Resolve issues to continue."
04
Multi-Country Submission and Conflict Detection
Single-country submissions are straightforward. Enterprise regulatory work is not. A submission covering twenty-seven markets simultaneously introduces a category of problems that single-country design cannot anticipate.
04.1
Country selection and saved configurations
Multi-country submission begins with country and submission type selection. Once a country set is confirmed, users can save it as a named configuration for reuse. The name is required; a saved selection without a name is useless because the next time a user opens that list, they have no way of knowing what it contains without opening each one. The name is the interface.
When a saved selection exists, the create submission flow surfaces it immediately. Users can select a saved configuration; review the included countries with active checkboxes, meaning countries can be deselected for this specific submission without modifying the saved configuration itself; and proceed. The saved selection is referenced, not owned. A submission does not modify the configuration it was built from.
.png)
First use
.png)
Returning use
04.2
Conflict detection at scale
Before a multi-country submission can start, the system checks every selected country against active submissions for the same article set and submission type. The escalation logic reflects the actual complexity of what can be found:
One country has a conflict with one existing submission: a banner identifies the country and offers three options
Multiple countries share a conflict with one submission: the banner identifies the number of affected countries, a "view countries" option expands the full list, and the same three options apply.
Multiple countries have conflicts across multiple different submissions: the banner states the number of conflicts found.
A "view conflicts" button opens a resolution popup, the same structural pattern as the document conflict interface, listing each conflict as its own expandable row showing which countries and which submissions are involved. Each row has its own resolution options.
Two global buttons, keep all and remove all, serve as escape hatches for cases where the decision is clear across the board.
In every scenario, the "Start Submission" button remains disabled until every conflict has received a conscious decision.
The system does not block; it informs and requires acknowledgment. A regulatory professional who keeps a conflicting country does so knowingly, not accidentally.
05
Market Authorization and Post-Release Compliance
When all workflow steps are complete, users confirm a market authorization, the point at which a submission becomes a legal regulatory record. This is where the compliance stakes are highest and where the design had to make the most careful decisions about what users can control and what the system must enforce.
05.1
Split market authorization
Not all countries in a submission reach authorization at the same time. Rather than forcing teams to split submissions manually or wait for every market to align before releasing any, the system handles partial authorization automatically.
To support the reality that market authorization forms are rarely completed in a single session, users can save a draft at any point. A draft preserves all entered fields without creating compliance records; countries in a draft state remain in progress alongside countries not yet started.
When 22 of 27 countries receive authorization, those 22 are released immediately. The submission stays in progress for the remaining 5; some may have drafts in progress, others not yet started.
Users see up to three actions depending on the state of remaining countries: view the confirmed market authorization, view any saved drafts, and complete the submission for countries not yet started.
Once the remaining countries are confirmed, a single market authorization exists with three views: a general tab showing what is mutual across all 27 countries, a tab for the first group showing their specific articles and additional documents, and a tab for the remaining countries showing what is specific to those markets. The structure reflects the actual regulatory reality: one authorization, multiple country-specific variations, rather than forcing the data into a flat format that loses that distinction.
If the remaining countries never reach authorization and need to be removed entirely, removing the last country without a market authorization triggers a specific confirmation: this will finalize and release the submission. The consequence surfaces before the action, not after.
Every country in a submission must reach market authorization before the submission fully releases.
.png)
05.2
Post-release editing with selective change confirmation
Released market authorizations can be edited. This is not a design choice, it is a regulatory reality. Documents get updated. Countries get removed. Fields need correction. Locking released records would make the system unusable in practice.
What the system does instead is make every post-release change traceable and deliberate.
When a user edits a released authorization, they reach a review screen listing every change as a separate item with a checkbox. The checkbox mechanic only appears when there are two or more changes; a single change needs only confirm or cancel. But when a user has made four changes and wants to save only three, the alternatives without checkboxes are poor: discard everything and start over, or navigate back through the form to manually undo one change. The checkboxes provide a third option: deselect the change to exclude and save the rest.
Each change also surfaces its consequence before confirmation. Removing a country from a released authorization shows a specific message: this will move the submission back to in progress for that country, while the remaining countries stay released on the dashboard. The user sees exactly what their edit will produce before committing.
After saving, the change is recorded permanently: the user's full name, the date, the specific changes made, and a mandatory justification note. This record cannot be edited or removed. Post-release editing is possible precisely because the audit trail makes it safe.
06
What This Work Required
The brief was to take an existing UI kit and a product concept and turn it into a working enterprise compliance system. No interaction logic, no flow rules, and no compliance constraints were defined. Just components and a description of what the product needed to do.
What the product needed was someone who could hold the full state space of a global compliance workflow, every combination of countries, documents, submission states, workflow stages, conflict scenarios, and post-release edits and design for all of it without building a system that felt like a compliance burden.
None of the logic documented here was handed to me in a specification. The draft lifecycle that prevents accidental data loss, the conflict detection that escalates based on complexity rather than applying a single blunt rule; the document resolution system that emerged from one question about duplicate filenames; and the split market authorization that handles what most teams do not anticipate until they encounter it—these came from identifying what the product actually needed and designing for it before anyone knew to ask.
The goal throughout was the same: surface complexity clearly, give users meaningful control at every decision point, and make the system's rules legible without making users feel managed by them.
07
Reflection
One thing I'd approach differently: knowing when to hold the line during QA and when accepting a deviation creates compounding problems later.
Early in the product I documented a popup height and CTA system: fixed dimensions, fixed CTA position, and scrollable content within a defined container. The implementation went the opposite direction. I accepted it under release time pressure, expecting it to be corrected after launch. It wasn't. Because it wasn't corrected, subsequent popups were built the same way. What started as one accepted deviation became the established pattern across the product.
The consequence isn't just one wrong component. New features inherit the wrong pattern. When something gets corrected, the fix doesn't always hold, the next feature built on the same foundation reverts. The result is a continuous correction loop: auditing what was built correctly, what was partially done, what was never done, and what was fixed but broken again by the next implementation.
The lesson: Some implementation decisions are load-bearing; they establish patterns that propagate across the entire product. Accepting a deviation in a foundational component isn't saving time. It's borrowing it.
08
Tools
Figma, regulatory affairs domain research, direct collaboration with consultants and development teams, and sustained design QA against live engineering builds.