How mass actions reduced the processing time of enforcement proceedings by ~14%
RnDsoft · Product Designer · 1 year
Back to home
"Vzyskatel" — B2B SaaS for automating work with the Federal Bailiff Service (FSSP)
Goals
  • Reduce the time required to complete key tasks through mass actions
  • Rework navigation and interface logic to match real user scenarios
  • Create a unified design system for synchronization with development

Result
  • Mass actions and reworked navigation reduced the processing time of enforcement proceedings by ~14% and decreased the error rate by ~9%
  • Design system component reuse increased by ~35%, development speed — by ~20%
More on the Problems:
  • Lack of mass stage assignment. This is a critical feature for a service positioned as a tool for automation and mass actions. Users assigned stages manually, one by one, which slowed down work and increased the risk of errors.
  • Navigation problems. Sections were structured by technical principle rather than user workflows. Integrations were scattered, and the hierarchy did not reflect real tasks.
  • Underutilization of existing features due to a complex interface. For example, notifications were rarely used, and the system sent too many system notifications that required no action. Users could not distinguish important notifications from secondary ones.
Solutions
Mass Stage Assignment
  • What I did: implemented mass stage assignment for enforcement proceedings after selecting the required cases. Added "Selected cases" and "Documents in queue" elements, so the user can always see how many documents are waiting to be sent.
  • Why: considered a modal window but rejected it — it covered the table, and the user lost the context of selected cases. The dropdown kept the table visible.
  • Result: User task completion time decreased by ~14%, error rate by ~9% (approximate values based on internal service analytics and duration measurements in in-depth interviews, CustDev, sample: 12 respondents).
Navigation Redesign

  • What I did:
  1. Switched from a top menu (like on a regular website) to a left sidebar.
  2. Moved filters into a separate button — they are no longer all displayed on screen at once.
  3. Moved settings to a separate section — they used to be in the user profile (historically).
  4. Highlighted mass mailings as a separate menu item.
  5. Added an information panel: how many documents an employee needs to process and how many are already on their way to the FSSP.
  • Why: there was a requirement to show more enforcement proceedings in the table on screen. The top menu and expanded filters took up space. The sidebar and hidden filters freed up space for data. Mass mailings are an important part of the service — internally they are a separate entity with their own table. The user needs to see information about them: how many documents were sent, how many are pending, how many have errors.
  • Result: more cases fit on screen, key sections are in predictable places, and workload information is visible.
Status System Redesign
  • What I did: consolidated fragmented statuses. Before: document sending status, FSSP status, "in progress with employee" status, user status + separately the mass mailing state. After: for a document — FSSP status and work stage; for mass mailings — one status (mailing state), since they are moved to a separate page.
  • Why: four parallel statuses for a single document created confusion — the user did not understand which one was primary and what to focus on. Separating by entity (document / mailing) and reducing the number of statuses eliminated the overlap.
  • Result: the status model became flat and predictable. Less cognitive load when reading the table.
Notifications
  • What I did: removed system notifications (except critical ones) and introduced second-level navigation — tabs for categorization based on required actions.
  • Why: the problem was not quantity but categorization. Users could not distinguish important from secondary and ignored all notifications altogether, missing the ones that required action. Tabs divided the flow into clear groups.
  • Result: the user finds the needed notification faster and is not distracted by system noise.
Design System
  • How I realized changes were needed:
  • More

  • Goal:
  1. Increase development and design speed.
  2. Refactor code and design with a focus on consistency and uniformity of the interface.

  • What I did: Created a unified design system based on an atomic approach. All elements are assembled into components, with states and interaction mechanics accounted for. Limited variability and began synchronizing design with code (paired with a developer).

  • Why this way: The problem was not individual elements but the lack of a system. Every new page was built from scratch. The designer redrew the table, the developer coded it again (or copied an existing one with errors). Buttons, filters, and cards that were identical in meaning looked different across sections. The atomic approach allowed breaking the interface into reusable components and fixing their states, instead of negotiating from scratch every time.

  • How I tracked it:
  1. Component reuse metric = number of used components / total number of components (worked with a developer who recalculated the used components).
  2. Time to implement typical pages (tracked in Jira).
  • Result:
  1. Component reuse increased by ~35%.
  2. Development speed by ~20%.
  3. Received positive feedback from the team. Developer: "Well, at least now the tables are the same." Analyst: "See, now the buttons are the same size — before there were 4 different styles on one screen."
  4. Designer's work speed increased: I did not run analytics, but empirically the figure is high.
  5. Design system maintenance time did not increase significantly.
Conclusions
What problems I encountered:
  • Legacy interface. Some solutions were tied to old logic, not only in design but also in code. Not everything could be reworked at once.
  • Coordination with PM and PO. Every decision had to be justified: why a dropdown and not a modal, why a sidebar and not a top menu. It slowed down the process but made decisions more deliberate.
  • Not everything could be measured. Metrics were not recorded before the start, some were restored after the fact. A/B tests are difficult in such a product: few users. Had to rely on mixed data: analytics + CustDev.
  • Design system maintenance. It was important not to fall into perfectionism and to do enough for developers to start using the components. Not to spend resources on polishing what does not affect speed.
Back to home
This site was made on Tilda — a website builder that helps to create a website without any code
Create a website
How to remove this block? About platform Submit a complaint