NOTA.Vizor
A tax monitoring platform. Large companies use it to share data and reports with Russia’s Federal Tax Service, run internal controls, and connect to the Nalog-3 system.
- Global CIO 2023 — Best Project for a Transition to Tax Monitoring
- Ranked #1 — IaaSSaaSPaaS.ru’s 2023 tax monitoring solutions ranking
- Role
- Sole Product Designer
- Period
- May 2022–Mar 2024
- Team
- Cross-functional, 30+ people
- Scope
- 500+ screens
Context
Who Uses the Product and How
Under Russia’s tax monitoring regime, the Federal Tax Service gets remote access to a company’s data. Inspectors review information and send requests online; the company responds and submits documents in the same system.
The primary users are tax accountants and financial controllers at large companies. They work with registers containing millions of rows, dozens of report types, and requirements defined by law.
Role
Owned the Product End to End
When I joined, the product was a collection of rough screens and disconnected UI elements. For two years, I was the only designer responsible for the entire product — from requirements and user flows to handoff and implementation review.
Working with the product owner, analysts, and subject-matter experts, I turned tax requirements into clear user flows. I reviewed decisions with the team first, then presented them to clients.
Alongside the product work, I built and rolled out a design system from scratch. That work is covered in a separate case study.
Challenges
What Made the Product Complex
- Legacy UI with no shared rules
The existing screens used different components and patterns. With every new feature, I had to decide which approach to follow without breaking familiar workflows for current users.
- The rules were fixed by law
Terminology, report structures, and form content were defined by regulation. I could simplify how people interacted with the system, but not the documents or the underlying tax logic.
- Stakeholders saw the same problem differently
Requirements came from the product owner, subject-matter experts, and other stakeholders. They often conflicted or ignored technical constraints. I surfaced those conflicts and helped the team decide what users needed and what was feasible to build.
- Data volume shaped the design
Complex filtering, registers with millions of rows, and background processing pushed the system’s limits. We reviewed design decisions with the frontend and backend teams before committing to them.
- Existing filters did not support real work
Sorting and search were not enough. An accountant needed to combine a dozen parameters, save the setup, and return to the same data days later. The product had no pattern for that workflow.
Process
How I Turned Requirements into UI
Over two years, I worked across every major product area: the data portal, reporting, internal control, and Nalog-3 integration. The tasks varied, but the decision-making process stayed consistent.
Requirements often arrived in the language of regulation rather than as user scenarios. I first clarified who was taking the action, when it happened in the reporting cycle, and how much data they were working with.
Next, I separated non-negotiable legal requirements from technical constraints and existing workflows. I prepared two or three rough options and reviewed them with the product owner and engineers before moving into high-fidelity design.
Once the team aligned on a solution, I presented it to clients. After release, support questions and feedback from accountants working with real data informed the next iteration.
Outcome
What Changed
Tables, forms, filters, and approval workflows began to follow the same rules. The design system I built alongside the product work formalized those decisions and gave the product a foundation for continued growth.
The project that moved Pochta Bank to tax monitoring with NOTA.Vizor received a Global CIO 2023 award.