Register of Enterprises
82% of business register submissions in Latvia were rejected on the first try. Each rejection meant weeks of delay before a company’s legal change took effect. I led the design of a new digital registration system that replaced paper and guesswork with real-time guidance and validation.
Government
10 months
2022
At a glance
Timeline and scope: 10-month project to design Latvia’s first end-to-end digital business registration system.
Role: Sole product designer, responsible for research, service mapping, interaction design, and collaboration with engineering through handoff.
Outcomes: Replaced a paper-based process with a guided system that validates in real time and supports both public users and internal reviewers.
Designed flows for business owners and accountants managing dozens of companies, and gave government staff a shared model and tools to review, collaborate, and issue verdicts faster.
Team setup
As the sole designer, I worked with a Product Manager, Engineering Manager, analysts, and a team of eight developers. I partnered directly with multiple government departments to map their processes from application to legal change, then carried the work from discovery through hand-off.
82% of first submissions failed
Before this project, every interaction with Latvia’s Register of Enterprises meant printing forms, understanding the law, and delivering documents in person. What should have taken hours often took weeks.
Which documents do I need?
This was the most common support question. People wrote long explanations of their situation only to receive links to the “right” forms, which often triggered more questions instead of answers.
How do I fill out these forms?
The second most common support question. If you couldn’t afford an accountant, you were on your own. The forms assumed legal and accounting knowledge most small business owners simply didn’t have.
A slow, manual process
Reviews that could have been done in a few hours sometimes stretched into weeks. Submissions were delivered on paper, handled by multiple people, and checked in disconnected internal systems.
A system that punished honest mistakes
Submissions were rejected for small issues: a missing field, a typo, or a document the user didn’t know was required. The system never made these expectations clear, yet 82% of first submissions were rejected, and 57% of “corrected” resubmissions failed again.
Taken together, this created constant uncertainty for businesses, who never knew when their desired change would actually take effect.
Building a shared understanding
Each department understood their step of the process, but no one had mapped the full journey from application to legal change.
I ran workshops where each department documented their process step by step. They exposed undocumented requirements, contradictions between departments, and issues specific to individual teams, and gave employees a clearer end-to-end view of the process.
I turned workshop outputs into a single map of the submission lifecycle, which became the reference point for every design decision.
Submission as the backbone
I chose the submission as the organizing principle because every department interacted with submissions but viewed them through a different lens: one cared about completeness, another about legal validity, another about status and deadlines.
A submission became the digital equivalent of all documents needed for a specific legal change, moving through five stages: Received → Queued → Accepted → In review → Verdict issued.
This created a shared language and let non-technical people contribute their perspective without getting lost in technical details.
Accountants were not an edge case
Most people submitted for a single business; accountants managed dozens. These were fundamentally different jobs with different consequences, so they needed separate flows.
Accountants selected an entity at login, while single-entity users skipped that step. Once selected, the entity name stayed visible in a sticky secondary navigation so people always knew which business they were acting on.
Switching entities was a deliberate action, like closing one book and opening another. That small detail mattered when one mistake could apply a legal change to the wrong company. An accountant mentioned: “Oh, like in my accounting software!”
Breaking the submission into three phases
The submission process was the core of the system, but it was too complex to design as a single flow.
I split it into three phases: gathering and filling documents, handling payment, and signing documents. Each phase had its own constraints, edge cases, and responsible teams. That separation made discussions more focused and gave the right people space to resolve the details they knew best.
From guesswork to guidance
People used to guess which services and documents they needed and only discovered mistakes weeks later.
Selecting a service now generates the correct documents automatically, removing the guesswork behind the most common support question: “Which documents do I need?” Multiple services can be combined in a single submission, and incompatible combinations are filtered out before they cause a rejection.
Instead of downloading static Word documents, users complete generated forms with clearly marked input fields. Fields like company name and registration number are pre-filled from government records, and I advocated for auto-save so people can safely return to their submissions later.
Every submission is validated against the full set of business rules before it can proceed. If something is wrong, the user knows it immediately, surfacing the same kind of errors that caused 82% of rejections in the old system.
When a submission is rejected, progress isn’t lost: people can edit and resubmit without re-entering every field, which matters for the 57% of “corrected” resubmissions who previously had to start from scratch.
Helping reviewers decide faster
Reviewers had to read through every submission manually to spot issues. Now the system categorises outcomes by severity so they can focus on what needs judgment.
Red means critical issues and the submission is returned; yellow means partial mismatches and only specific parts need revision; green means no issues.
I based the verdict interface on the Word documents reviewers were already comfortable with, so it felt familiar from day one. The system lets multiple reviewers work on the same submission, find the relevant law in a searchable database, and send verdicts to multiple recipients using different delivery methods from a single action.
What used to take up to 15 days can now be understood at a glance.
Keeping decisions tied to the process
During monthly walkthroughs, I noticed that stakeholders who hadn’t joined the workshops treated design decisions as aesthetic choices rather than process changes.
The workshop regulars, who understood the reasoning behind each decision, became informal advocates and sometimes stepped in to reframe feedback in process terms.
To address this, I started sharing iterations before each review, which kept conversations focused on how the system behaved instead of how it looked.
The Engineering Manager attended most workshops, but the engineers building the system only joined once implementation started. By then, the new processes had diverged significantly from existing documentation.
I created information flow diagrams that traced a submission from creation through validation to the final legal change. These diagrams became the team’s shared reference and the basis for decisions in areas the initial specs didn’t cover.
Testing with the people who rely on it
I ran two rounds of remote user testing with six participants each: government employees and small business owners in the first round, accountants and legal experts in the second.
All participants worked through ten scenarios centered on changing a company’s shareholder structure. This covered core flows like finding an entity, filling and submitting documents, and checking status, as well as more complex cases like delegating access or submitting for a subsidiary.
The core workflows worked well on first use: most participants completed them without assistance, and the majority of tasks were completed correctly across all users.
The issues appeared in the more complex tasks, especially granting access and making submissions for subsidiary companies. I reworked both flows based on these findings.
In total, 5 of 12 participants completed all tasks without help, and 6 of 10 tasks were completed perfectly by everyone.
Reflections
The system launched and Latvia’s business registry now runs end-to-end digitally.
The paper-based process that rejected 82% of submissions now validates in real time and guides users toward successful completion instead of punishing predictable mistakes.
The same system supports both external users and internal reviewers, from the first submission through to the final legal change.
If I were doing this again, I would map the gaps between departments earlier.
The diagrams I created weren’t beautiful, but they were what everyone organized around, and having them sooner would have aligned teams earlier and reduced rework.
I would also start showing designs earlier. I had been told that if government workers see something, they expect it to happen, so I delayed screens until I had gathered more information. In practice, the working group was so collaborative that once I began iterating quickly on designs, our progress accelerated.
This project shifted how I approach complex, high-stakes systems: I now try to get to a shared model faster, treat internal workflows as first-class users of the design, and put rough screens in front of stakeholders sooner so we can discover gaps together instead of on paper.