LTN — Nicotine Product Registration Portal

In 2023, Sweden enacted legislation requiring all tobacco-free nicotine products — pouches, sprays, gums — to be registered with the Public Health Agency before going to market. The law took effect January 1st. Before it, no registration process existed.

The registrants ranged from a one-person vape shop importing a single product to corporations like Phillip Morris with entire product families. One portal, one flow, one registration form — for all of them. Every registration had to include every ingredient, its CAS number, and its ratio in the product. The platform would cross-reference each ingredient against a database of toxic compounds and flag any product with illegal substances or nicotine doses above the legal limit.

We couldn't do user research with the actual registrants. The regulatory relationship between the public health agency and the tobacco industry made that impossible. The legal text and the agency's lawyers were our primary design input.

UX/UI Designer at LH+P, embedded with the The Public Health Agency of Sweden team. I was the only designer across the full project — working from legal text rather than user research, designing for an audience I couldn't talk to, and navigating the internal dynamics that sat underneath the surface design problems.

The team was small: me, a few developers, a product lead, QA, and the operations team. Being the only designer meant every decision needed a rationale that worked for multiple audiences — the companies submitting products, the agency staff managing them, and the legal team validating compliance.

With no direct access to the actual registrants, I did two things. First, I read the law — closely, with the agency's lawyers — to understand exactly what a valid registration had to contain and what would disqualify one. Second, I worked with the operations staff who processed submissions manually. They were the closest proxy I had to the registrant experience, and they knew every edge case in the existing paper process.

The central tension: operations needed to feel in control, but the model couldn't scale if every submission needed personal approval. The answer was an asynchronous sign-off protocol — submissions go through automated validation and proceed unless operations flags them. They're still in the loop; they're just not a required gate for every clean submission.

This reframe was key. Instead of "automation will handle it," the message became: "you review what matters, the system handles what's clear." That distinction made the difference between resistance and adoption.

For the legal content problem, I worked in close parallel with the legal team — building design and copy review cycles into the sprint structure rather than treating them as sequential. That kept both moving without either blocking the other.

For the duplicate product issue — companies often register slight variants of the same product — I designed a "duplicate and edit" registration flow, which eliminated the biggest time cost for frequent submitters and significantly reduced the volume of error-prone manual re-entry.

With the asynchronous sign-off model unlocked and the duplicate flow scoped, I built across four areas simultaneously — the company-facing registration flow, the agency-facing review dashboard, the status system visible to both, and the compliance content framework that ran through everything.

Without access to actual registrants, I tested with two groups who were available: the operations team and the development team. Separate sessions, different mental models — "how do I process and approve submissions" versus "does the form collect what the law requires." It wasn't ideal. It was what was possible.

Key finding from operations sessions: the asynchronous sign-off model needed clearer language explaining what "automatic approval" actually meant in practice. Participants wanted to know exactly when they'd be notified and what level of review they were still doing. That informed a dedicated onboarding step for agency staff on first use.

The duplicate registration flow tested well — the operations team noted it would significantly reduce the back-and-forth they currently dealt with for variant products. That validated it as the right call.

All design built to government visual standards — official colours, typography, and accessibility requirements. The system had to work across two distinct contexts: the public-facing registration portal (company users, potentially any browser, variable technical literacy) and the internal agency dashboard (operations staff, controlled environment, expert users).

Designing for both in the same system required clear shared foundations — component structure, spacing, colour — while allowing the two contexts to diverge where it made sense. The internal dashboard could carry more information density than the public-facing portal.