Role-based backend for 600+ government staff
Backend platform for the Ministry of Finance's Uniform Invoice Lottery Redemption App—role-based access and reporting for 600+ staff, faster invoice management and fewer errors.
Timeline
Jul 2025 – Sep 2025 (3 months)
Role
Lead UX/UI Designer
Project type
Backend admin platform · Government service (MoF)
Focus
RBAC, reporting, version workflows · Ship-ready UI
Supporting 600+ government staff with role-based access—one reliable backend for MoF lottery operations.
Summary
600+
Role-based access control
I designed a role-based permission system that aligned responsibilities across departments. By hiding inaccessible features and limiting high-impact actions to specific roles, the platform enabled teams to work independently while preventing conflicts that could affect public-facing content.
Reporting
CSV
Self-service dashboards
I redesigned reporting into an actionable dashboard with weekly and monthly views, time-based filters, and CSV export. Staff could prepare reports independently for meetings and audits, reducing reliance on engineers and speeding up operational workflows.
System logic
Ship
UI decisions under constraints
Working closely with engineers, I designed backend flows that balanced flexibility and stability—such as version control with mandatory update settings and build-code mapping—so critical updates could be enforced quickly without risking system inconsistency.
After the public lottery app shipped, MoF needed a single backend for announcements, promos, push rules, reporting, and app versions—used by 600+ people who expect the same familiarity as other government systems.
Example of corresponding screens
Staff compose notification content in the backend, set publish timing, and schedule delivery in advance. End users receive push notifications, then open the in-app notification center and message details—aligned with those backend rules.
How I aligned design with engineering
- 01
Turning abstract permission debates into concrete scope
The first major challenge was enabling multiple departments to collaborate within one system while respecting each other's responsibilities. That challenge became the foundation for designing role-based access control.
- 02
Hide, don't disable
For promotion pinning, non-HQ roles had high-impact controls hidden entirely rather than greyed out — cleaner for civil servants, fewer support tickets, and a single enforcement path for the backend.
- 03
UI never overpromises the API
Reporting filters, copy, and defaults were aligned with what the API could actually guarantee — so the interface never offered a data slice the service couldn't deliver.
I defined a clear set of principles for access: which roles could see which features, and how permissions should differ. If a role had no access to a feature, that feature simply did not appear in their sidebar.
