Project overview

Sole designer on the AML MVP. I owned the onboarding and import flow end to end, from the user flow to the final UI and copy. The import flow took about 6 weeks, including two rounds of testing.

The problem: the first screen decides whether the product gets used

Youverify was branching into AML with a transaction monitoring MVP aimed at compliance teams, including junior compliance experts, who struggle with complex legacy tools. Before any of the triage features matter, a new client has to get their data in.

In discovery calls, compliance leads said the other AML tools: importing data meant raising a ticket with their own engineering team and waiting.

The business needed pilot clients to see their own customers flagged in their first session. A demo with sample data did not convince compliance leads; seeing their own customers did. Every day spent waiting on an import was a day the pilot could stall.

What shaped the design

• Our users were compliance experts, not engineers. Junior compliance experts were a core audience, and my competitive analysis found incumbents like ComplyAdvantage complex for junior users. For the import, that meant no database field names and no error messages only an engineer could read. Every step had to make sense to someone who knows what a risk rating is but has never written a query.
• Client data arrives in their own format. In 6 sample exports shared by pilot clients, no two files used the same column names. Customer ID appeared as Cust_ID, Cust_No and customer_id; surname as Surname and Last Name; risk as Risk Grade and risk_rating. Every file also had a few rows with missing or malformed values.
• Getting started had to be optional, not blocking. Writing monitoring rules needs a clear view of the client's risk appetite, which junior users rarely had on day one. If rules came first, the account stayed empty. Default rules, signed off by our Compliance SME, let teams see real alerts first and tune later.

These led to two principles for the flow: every step shows progress, and every decision point has contextual help.

Decision 1: A two-step checklist, with sensible defaults

I broke onboarding into a short Get Started checklist with a progress indicator: import user data, then configure rules. Each step offers a fast path and a flexible one: import a CSV or add customers manually; use the default rules or configure your own.

In the first round of testing, 5 compliance analysts saw an early version that opened on the rules builder. 3 of 5 stopped there and asked what the rules should be. Moving import first and making default rules the primary option meant all 5 reached a populated dashboard in the second round. Two steps was the minimum: one for data, one for rules. Everything else, like team invites, moved out of onboarding.

Decision 2: Limits and a template first, so files arrive in the right shape

The import opens with the limits stated up front, 10 MB and 20,000 customers per file, a drop zone that says column names don't need to match, and a template whose headers can be copied or downloaded. Users know what a good file looks like before they upload.

The limits came from engineering. Rows were checked in the browser before upload, and above about 20,000 rows older laptops slowed enough that users thought the page had frozen. 10 MB covered a 20,000-row file with every column filled.

A file over the limit gets an instruction instead of a rejection: how many customers it has, and how many files to split it into.

Decision 3: Auto-matching columns instead of demanding a perfect file

Clients will not always use our template. Instead of rejecting files with different column names, the system matches known names to Youverify's 14 customer fields. Each row shows the user's column, a sample value, the field it maps to and a status, so the user confirms rather than configures. Only columns the system can't place need a decision: map it to a field, keep it as a custom field, or don't import it.

The alternative was a strict template that rejected any file with different headers. It was simpler to build, but all 6 sample client exports would have been rejected on the first try. With auto-matching, the same files needed at most one or two decisions each. Sample values were added after testing, when two analysts mapped a column to the wrong field because they could only see its header.

Decision 4: Review every row before anything is saved

With real exports, a few rows are almost always wrong: a missing surname, a date that doesn't exist, a BVN with too few digits. The first version validated the whole file and failed it if anything was wrong, so 8 bad rows held back 1,196 good ones.

I added a Review step between matching and import. Every row is checked, and the screen shows which rows fail, in which cell, and why. The user then chooses: fix the file and upload it again, or continue with the rows that passed. Skipped rows are counted in the final summary so nothing disappears silently, and BVNs stay masked throughout.

Designing the failure paths

I mapped the whole journey before designing screens, and caught each problem at the earliest step that can explain it: file problems at upload, column problems at matching, data problems at review. Only a server problem can happen at import.

That last case needed the most care. If a save times out halfway, a retry must not create duplicate customers. The import is all or nothing, so the error can honestly say no customers were added, keep the file and matches, and offer a one-click retry with a reference number support can trace.

The result

• Over the first 6 weeks of the pilot, 7 of 8 client teams imported their data on their own. The eighth had a 140,000-row file, which our team loaded for them. The median time from first login to a live dashboard was 14 minutes, down from 3 to 5 working days when engineers loaded data by hand.
• In the second round of testing, all 5 compliance analysts completed the import without help, in a median of 7 minutes. The most common comment was that sample values made it obvious when a match was wrong.

What I'd do differently

I would test with real client files from the first week. Early prototypes used our own clean template, which hid the column naming and data quality problems until later. I would also design an API or scheduled import alongside CSV sooner, since larger clients wanted their data to stay in sync instead of uploading a file each month.