What Worked
The sequence of tokens → base components → complex patterns, one documentation template for every component, a staged rollout, and regular demos with the full team.
Design System Refactor
How I replaced manual screen-by-screen design with one system of tokens, components, and rules. Frontend engineers and QA could work directly from the specs without asking for clarification on every state.
- Role
- Sole Product Designer
- Period
- Jan–Jul 2023
- Library
- 40+ components
- Coverage
- 100% of product screens
Context
A Product with 500+ Screens
NOTA.Vizor is 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. The full product background is covered in the previous case study.
Role
Initiated and Led the Refactor
I proposed the design system, designed it from scratch, and carried it through rollout. I did this alongside ongoing product work, with no dedicated project time and no second designer.
The work followed four stages: tokens and styles → base components → legacy-screen refactoring → product rollout.
Challenges
The Three Most Demanding Problems
- A custom library with no off-the-shelf UI framework
The frontend team built the production component library directly from my specs. With no Ant Design or Vue UI kit underneath, the documentation had to cover behavior, states, and edge cases precisely.
- Tables were the most complex component
The table component had to support multiple row densities, column alignment, sorting, row and cell states, and inline editing. I broke that behavior into configurable properties so each table variant could be assembled instead of redrawn for every screen.
- Navigation panels took multiple iterations
The left and right panels behaved differently depending on the screen. Some requirements became clear only when the components were tested in real workflows. I refined the specs over several iterations until they worked consistently for both design and frontend development.
Standards
Token Names Describe Intent
Each token name followed the same structure, using up to four parts. Simple names stayed short; state and hierarchy were added only when needed.
Instead of choosing “the third gray,” the team used semantic names: text-primary for body
copy and headings, text-tertiary for placeholders and help text, and text-danger for
errors and destructive actions.
Library
40+ Components, One Documentation Format
The core library included Button, Input, Select, Multiselect, Table, Modal, Alert, Pagination, and Tabs. I also documented recurring patterns for tables and forms: empty states, inline editing, validation, and error messages.
Each component included its purpose, properties, states, edge cases, and do/don’t examples. Frontend engineers and QA could work from the specs without repeatedly coming back to design for clarification.
Process
Tested on Real Screens
I did not design the library in isolation. I tested each new layer on real product screens. That exposed problems that were invisible in a standalone component: insufficient contrast, spacing that broke in context, and missing edge cases.
When an issue was systemic, I returned to the tokens or base components, fixed it there, and tested it again in complex workflows. The frontend team reviewed each stage, so problems did not accumulate until the end.
The rollout moved from lower-risk elements to more complex ones: styles, buttons, and inputs first; tables, filters, and forms next. The product owner approved the overall direction, while ongoing changes were reviewed with the frontend team in demos and design reviews.
Results
How the Workflow Changed
These figures are team estimates based on production work during the rollout, not the results of a controlled study.
−40%
Screen design time.Preconfigured components replaced manual redrawing.
Design speed
−70%
UI defects per release.Shared component states reduced accidental inconsistencies.
UI quality
3–4 → 1–2
Design review rounds per task.Design, product, and engineering worked from the same rules.
Communication
<5%
Non-standard components in new work.New components were limited to experiments and genuinely unique scenarios.
Standardization
Retrospective
What I Would Change
I would bring complex patterns into the process earlier, especially tables and the right-side panel. Their real behavior surfaced late and added unnecessary iterations.