Toms Varpins
01
Overview
Redesigning a system that rejected 82% of submissions
Role
Sole product designer — research, service mapping, interaction design, and user testing
Team
Product Manager, Engineering Manager, analysts, eight developers, and government employees
Company
Register of Enterprises · Government
Timeline
10 months, 2022
Submission document overview after data validation
The system launched and Latvia’s business registry now runs end-to-end digitally.
02
Problem
82%
Of business registrations in Latvia failed on the first try, costing companies weeks.
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.
Of first submissions failed
82%
Of “corrected” resubmissions failed again
57%
A slow, manual process
Submission 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.
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.
Taken together, this created constant uncertainty for businesses, who never knew when their desired change would actually take effect.
03
Process
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.
Sharing department workflows and defining what the product does and does not.
Keeping decisions tied to the process
Stakeholders who hadn’t joined the workshops treated design decisions as aesthetic choices rather than process changes. I started sharing iterations before each review, which kept conversations focused on how the system behaved instead of how it looked.
The workshop regulars, who understood the reasoning behind each decision, became informal advocates and sometimes stepped in to reframe feedback in process terms.
I created information flow diagrams that traced a submission from creation through validation to the final legal change.
The diagrams became the reference spec
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 turned workshop outputs into a single map of the submission lifecycle, which became the reference point for every design decision.
04
Backbone
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.
Each submission moved 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.
05
Flows
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.
“Oh, like in my accounting software!”
Comment from a user during testing
—
06
Guidance
Preventing common mistakes
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.
Generated forms with clearly marked input fields and real-time validation
Every submission is validated against the full set of business rules before it can proceed. If something is wrong, the user knows it immediately.
Mapping inputs to business rules required participation from 4 departments.
This surfaces the same kind of errors that caused 82% of rejections in the old system.
Progress is never lost
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.
Edit and resubmit without re-entering every field
07
Reviewers
15
What used to take up to 15 days can now be understood at a glance.
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.
Helping reviewers decide faster
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.
Red means critical issues and the submission is returned; yellow means partial mismatches and only specific parts need revision; green means no issues.
Familiarity as a feature
I based the verdict interface on the Word documents reviewers were already comfortable with, so it felt familiar from day one and would require less time for training.
08
Testing
12
Participants across two rounds of remote user testing, six in each.
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.
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.
Tasks successfully completed
96%
Tasks completed without assistance
6/10
Participants completing tasks without any asssistance
5/12
Testing with the people who rely on it
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 the submission status, as well as more complex cases like delegating access or submitting changes for a subsidiary.
Issues appeared in the more complex tasks, like delegating access and making submissions for subsidiary companies. I reworked both flows based on these findings.
09
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.
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.
Show 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.
Diagrams as shared reference
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.