Central Database
Central Database
First UX redesign in 20 years for a government platform that processes social payments for hundreds of thousands of citizens.
Role: UX/UI Designer (second designer on the project)
Product type: Government enterprise system
Platform: Web (desktop)
Country: Kazakhstan
Year: Jan-Mar, 2025
All interface screenshots have been translated from Russian
(the original product language) into English for portfolio purposes.
Context & My Role
Kazakhstan's state social payments operator had been running on a system that had barely changed since 2002. Over 20+ years, it was updated twice — but only on the technical side, with no design involvement. In 2025, a third update began: for the first time, with a focus on UX. The initiative came from the company's VP, who wanted to build an interface that would stand the test of time.
Kazakhstan's state social payments operator had been running on a system that had barely changed since 2002. Over 20+ years, it was updated twice — but only on the technical side, with no design involvement. In 2025, a third update began: for the first time, with a focus on UX. The initiative came from the company's VP, who wanted to build an interface that would stand the test of time.
I joined the project as the second designer. The design system and visual language had already been established by the lead designer. My responsibility was to design four key modules from scratch within that system: SIC (Social Identification Card), Audit, Payment Generation, and Return Processing.
I worked closely with product managers and developers — receiving technical specifications, clarifying details in calls, and iterating on designs based on team feedback.
I joined the project as the second designer. The design system and visual language had already been established by the lead designer. My responsibility was to design four key modules from scratch within that system: SIC (Social Identification Card), Audit, Payment Generation, and Return Processing.
I worked closely with product managers and developers — receiving technical specifications, clarifying details in calls, and iterating on designs based on team feedback.
The Problem
Why It Mattered
The CBD is the system through which government operators at public service centers and relevant agencies process benefits and social payments for hundreds of thousands of citizens. An operator mistake means a delayed payment for a real person.
The old interface was built on a "one function, one page" logic. Over the years, the system had accumulated hundreds of screens with duplicated logic, inconsistent patterns, and outdated forms. Operators had to navigate between dozens of loosely connected sections to complete a single task.
The CBD is the system through which government operators at public service centers and relevant agencies process benefits and social payments for hundreds of thousands of citizens. An operator mistake means a delayed payment for a real person.
The old interface was built on a "one function, one page" logic. Over the years, the system had accumulated hundreds of screens with duplicated logic, inconsistent patterns, and outdated forms. Operators had to navigate between dozens of loosely connected sections to complete a single task.
Users
Government employees: operators at public service centers (CSC) and staff at relevant agencies. Experienced, daily users — who had grown accustomed to inefficiency as the norm.
Government employees: operators at public service centers (CSC) and staff at relevant agencies. Experienced, daily users — who had grown accustomed to inefficiency as the norm.
How do you design complex operational modules that feel intuitive
to experienced government operators — while fitting into a unified design system built to scale for years ahead?
How do you design complex operational modules that feel intuitive
to experienced government operators — while fitting into a unified design system built to scale for years ahead?
Research & Analysis
There was no formal user research on this project — a constraint of the context (government client). I actively compensated for this through other methods.
There was no formal user research on this project — a constraint of the context (government client). I actively compensated for this through other methods.
Specs as research
Government specs contain detailed business logic — roles, scenarios, edge cases.
I read them as a researcher, finding contradictions and hidden pain points.
Government specs contain detailed business logic — roles, scenarios, edge cases.
I read them as a researcher, finding contradictions and hidden pain points.
Working sessions
For every complex screen I ran through questions with PMs
and devs: who sees this, what happens in each state, how is it done today.
For every complex screen I ran through questions with PMs
and devs: who sees this, what happens in each state, how is it done today.
Existing interface audit
Before each module
I studied how similar functions worked
in the old system —
to understand user expectations.
Before each module
I studied how similar functions worked in the old system —
to understand user expectations.
Key insights that shaped the design:
Key insights that shaped
the design:
Operators work fast and scan, they don't read — the interface needs to deliver the answer at a glance
Many actions share the same structure but differ in context — unified patterns are needed, not unique screens
Critical actions (deregistering a SIC, deleting an ID) require explicit confirmation — the cost of error is high
Operators work fast and scan, they don't read — the interface needs to deliver the answer at a glance
Many actions share the same structure but differ in context — unified patterns are needed, not unique screens
Critical actions (deregistering a SIC, deleting an ID) require explicit confirmation — the cost of error is high
Process: Four Modules
SIC Module — Citizen Social Card Lifecycle
The core challenge: each state required a different set of available actions and a different level of confirmation — while all states needed to feel like part of the same system.
The core challenge: each state required a different set of available actions and a different level of confirmation — while all states needed to feel like part of the same system.
SIC (Social Identification Card) is a citizen's record in the system, linked to their national ID (IIN). The module covers the full lifecycle: registration, editing, deregistration upon death, emigration abroad, ID deletion, and ID restoration.
I structured the module around IIN search as the entry point — one field, one click,
and the operator sees the full citizen profile with all available actions. Destructive operations (death registration, deletion) require a separate confirmation step
with an explicit description of consequences.
SIC (Social Identification Card) is a citizen's record in the system, linked to their national ID (IIN). The module covers the full lifecycle: registration, editing, deregistration upon death, emigration abroad, ID deletion, and ID restoration.
I structured the module around IIN search as the entry point — one field, one click, and the operator sees the full citizen profile with all available actions. Destructive operations (death registration, deletion) require a separate confirmation step with an explicit description of consequences.
Citizen profile
SIC Registration
Audit Module
The core challenge: a high volume of data, combined with the need to quickly locate a specific event among thousands of records.
The core challenge: a high volume of data, combined with the need to quickly locate a specific event among thousands of records.
A module for tracking all system changes — who changed what and when.
Audit is a control and investigation tool, not a daily working screen.
I focused on a filter system: by date, user, event type, and object.
The results table was built on "most important visible immediately" — date, action, executor — without opening each record. Details expand on click.
A module for tracking all system changes — who changed what and when. Audit is a control and investigation tool, not a daily working screen.
I focused on a filter system: by date, user, event type, and object.
The results table was built on "most important visible immediately" — date, action, executor — without opening each record. Details expand on click.
Recipient search
Recipient search
Citizen card
List of children whose date of death dose not match the risk date
Payment Generation
Core challenge: multi-step process with dependent fields and business rules that change by benefit type
Core challenge: multi-step process with dependent fields and business rules that change by benefit type
The heart of the system — operators generate payments for citizens.
I designed a step-by-step flow with a clear progress indicator. Each step validates independently. Before submission, a summary screen allows returning and editing.
The heart of the system — operators generate payments for citizens.
I designed a step-by-step flow with a clear progress indicator. Each step validates independently. Before submission, a summary screen allows returning and editing.
Return Processing
Core challenge: a return is not "cancel a payment" — it's a multi-stage process with statuses, documents, and responsible parties
Core challenge: a return is not "cancel a payment" — it's a multi-stage process with statuses, documents, and responsible parties
I visualised the return lifecycle as a status sequence — the operator always sees which stage each case is at and what needs to be done next. This reduced cognitive load and minimised the risk of missing a step.
I visualised the return lifecycle as a status sequence — the operator always sees which stage each case is at and what needs to be done next. This reduced cognitive load and minimised the risk of missing a step.
Design Decisions
Single entry point via national ID
Across all modules involving a specific citizen, IIN search is the first screen. No need to remember which section holds which function.
Across all modules involving a specific citizen, IIN search is the first screen. No need to remember which section holds which function.
Status-driven architecture
One screen with dynamically changing available actions depending on record status — instead of a separate page per state.
One screen with dynamically changing available actions depending on record status — instead of a separate page per state.
Explicit hierarchy
for destructive actions
Irreversible actions sit behind an additional confirmation with a description of consequences. Standard for high-cost-of-error systems.
Irreversible actions sit behind an additional confirmation with a description of consequences. Standard for high-cost-of-error systems.
Tables as primary data pattern
Government operators work with high data volumes. Dense tables with smart filters over card-based interfaces — matching actual user context.
Government operators work with high data volumes. Dense tables with smart filters over card-based interfaces — matching actual user context.
Outcomes
What shipped: 4 core modules (SIC, Audit, Payment Generation,
Return Processing) — designed from scratch within an established design system and delivered to development within a 3-month timeline.
Who it serves: Government operators at public service centers across Kazakhstan, processing social payments for hundreds of thousands
of citizens.
Observed impact: Designs passed review with product and technical stakeholders without fundamental revisions — unusual for a government project of this scale. For the first time in the system's 20+ year history,
UX principles drove the design process.
What I'd do differently: Involved in a later stage, I inherited constraints
I couldn't change. Next time I'd push for at least one round of operator shadowing before wireframing — even 2 hours would have changed several micro-decisions.
What shipped: 4 core modules (SIC, Audit, Payment Generation,
Return Processing) — designed from scratch within an established design system and delivered to development within a 3-month timeline.
Who it serves: Government operators at public service centers across Kazakhstan, processing social payments for hundreds of thousands
of citizens.
Observed impact: Designs passed review with product and technical stakeholders without fundamental revisions — unusual for a government project of this scale. For the first time in the system's 20+ year history,
UX principles drove the design process.
What I'd do differently: Involved in a later stage, I inherited constraints
I couldn't change. Next time I'd push for at least one round of operator shadowing before wireframing — even 2 hours would have changed several micro-decisions.
