AI Assistant: Guided Data Import & Workflow Intelligence
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.
AI assistance in a regulated compliance environment isn't about automation. It's about making complex decisions faster without removing the human from them.
01
Context
Regulated enterprise software accumulates data slowly and carefully. Every record matters. Every relationship between records carries compliance implications. When a new platform enters a regulatory affairs team's workflow, the hardest problem isn't the product itself. It's getting years of existing data in.
The brief was to design a one-time importer. A tool users would open once, upload their existing historical data, and never see again.
I disagreed with that framing from the start.
02
The Brief vs. The Design
A one-time importer solves the onboarding problem. It doesn't solve the ongoing problem.
Regulatory affairs teams have years of existing data, submissions, articles, market authorizations tracked in spreadsheets and disconnected documents, that needs to migrate into the platform. But the import moment isn't the only moment users need guidance. Once the historical data is in, new records get created directly in the system. The same questions that arise during migration, what already exists, what conflicts with what, what patterns apply, arise throughout the entire product lifecycle as the team works day to day.
Designing a tool that disappears after migration meant designing for the easiest version of the problem, not the real one.
I pushed for a persistent assistant. One that guides users through the initial migration but remains available throughout the product lifecycle. Dismissible when not needed. Resumable when relevant. Present whenever the user needs guidance, not just on day one.
The stakeholder concern was scope. An assistant that lives beyond onboarding is significantly more complex to build. My response was to design the complete vision as the roadmap and define what ships first as a separate question. Development constraints shouldn't define what the product should be. They define what gets built when.
03
The Core Design Decisions
Human-controlled, not autonomous
The assistant's autonomy is deliberately limited. It interprets, maps, and suggests. Every decision belongs to the user. No record is imported, confirmed, or modified without explicit human review and approval.
This wasn't a technical constraint. It was a design principle. In a regulated environment, an AI that acts without confirmation creates audit risk. Users need to be able to say, and prove, that they reviewed every change. The assistant makes that review efficient, not optional.
Awareness of existing system data
The initial brief treated import as a one-directional flow. Data comes in, gets checked, gets saved. But the platform already contains records. Submissions, articles, market authorizations built over months of active use.
An importer that ignores existing data creates duplicates, conflicts, and silent inconsistencies that surface later as compliance problems. The assistant needed to cross-reference incoming data against what already exists in the system, flagging matches, surfacing conflicts, and offering informed suggestions based on patterns already established in the user's own data.
This was technically more complex. It was also the only honest version of the problem.
Dismissible and resumable
Import isn't always completed in one session. Regulatory teams are interrupted. Records are missing. Decisions need to wait for a colleague. The assistant needed to support partial progress, letting users dismiss it, continue their work, and return to the import at any point without losing what they had already reviewed and confirmed.
Already confirmed records stay confirmed. The remaining work waits. The assistant picks up exactly where the user left off.
04
What the Assistant Does
Import guidance
The assistant guides users through uploading and mapping existing regulatory data into the platform. It interprets the structure of incoming data, proposes how records map to the platform's data model, and asks users to confirm, correct, or adjust each mapping before anything is saved.
Duplicate and conflict detection
Before any record is confirmed, the assistant cross-references it against existing platform data. Exact duplicates are flagged. Partial matches, records that share key attributes but differ in others, are surfaced with the specific differences highlighted. Users decide how to resolve each case individually.
Pattern-based suggestions
Where a user's existing data shows consistent patterns, the same article configurations, the same market groupings, the same submission types, the assistant recognizes those patterns and offers to apply them to similar pending records. Users can accept, modify, or ignore each suggestion.
Question answering
Throughout the import process, users can ask the assistant questions, both from a predefined set of common queries and in open form. The assistant answers based on the platform's data and the context of the current import session.
Future: search and navigation
The roadmap extends the assistant beyond import, into ongoing search, navigation assistance, and proactive guidance for users working within the platform day to day. The import feature is the first expression of a persistent intelligent layer designed to scale across the full product lifecycle.
05
What This Work Required
Designing an AI assistant for a regulated enterprise platform is a different problem than designing a chatbot.
The failure modes are different. A wrong suggestion in a consumer app is an inconvenience. A wrong suggestion in a regulatory compliance workflow can propagate silently through submissions, market authorizations, and audit records before anyone notices. Every interaction needed to be designed with that consequence in mind.
The interaction model needed to balance two competing requirements: moving fast enough to be genuinely useful, and maintaining enough visibility and control that users could trust every output. Too much friction and users abandon the tool. Too little friction and users confirm things they haven't actually reviewed.
Getting that balance right required designing not just the happy path, successful import, clear suggestions, easy confirmation, but the full range of states a user encounters. Partial matches. Unresolvable conflicts. Sessions interrupted mid-import. Records that exist in the incoming data but shouldn't exist in the platform. Each state needed its own clear, honest, actionable response.
This was also the first AI assistant across the entire product group's portfolio. The interaction patterns established here, how the assistant communicates, how it surfaces uncertainty, how it handles conflict, how it hands control back to the user, will serve as the foundation for AI integration across all products in the group.
06
Outcome
The design was presented to company leadership and received approval to move into development. A prototype was used in the first external customer demonstrations, with enterprise clients actively evaluating the feature.
A product manager from a connected enterprise software product within the same group publicly stated that the interaction model is something he envisions adopting to increase usability across otherwise complex enterprise products, naming it as directly applicable to products serving large-scale engineering and regulatory workflows.
The feature is currently in active development planning. Usability testing on the prototype is underway ahead of full implementation.
07
Reflection
The hardest design problem wasn't the import flow itself. It was defining what the assistant should and shouldn't do autonomously.
There's a natural pressure in AI product design to make the system do more, to reduce friction, to automate decisions, to get users to their goal faster. In a consumer context, that pressure often points in the right direction. In a regulated compliance context, it points toward risk.
Every time I considered expanding the assistant's autonomy, letting it confirm low-confidence matches automatically, letting it apply patterns without individual review, I came back to the same question: what happens when it's wrong? In this domain, that question has a real answer. The wrong answer, automated, propagates.
The constraint that every decision requires explicit human confirmation isn't a limitation of this design. It's the design.
08
Tools
Figma, direct collaboration with product, development, and AI engineering teams, regulatory affairs domain research.
Interface designs and a complete prototype walkthrough are available during a live interview session