2022–2023
Monitoring and Follow-up Unit Dashboard
A platform designed so senior officials and data officers could work with the same data, through different interfaces.
Product Designer
Enterprise / B2B / Data Visualization / Government
- Role-based dashboard architecture
- Multi-agency reporting workflow
- 5 user roles supported

Before this platform, national reporting workflows depended on spreadsheets, email threads, and PDF reviews across multiple agencies.
The new system supported both high-level monitoring and detailed operational workflows through role-based interfaces designed for different responsibilities.
Designing for Multiple Roles
The platform needed to support very different users: data officers entering raw figures, analysts reviewing submissions, department leads approving updates, and senior officials monitoring national performance.
The challenge was designing one system with different interfaces, hierarchies, and workflows for each role.
Fragmented Reporting Workflows
Each agency used its own files, schedules, and reporting formats. Reviews moved through spreadsheets, email chains, and offline documents.
The redesign focused on making workflows traceable, responsibilities visible, and reporting easier to manage across agencies and approval stages.
Role and Ownership
I worked as a Product Designer in a cross-functional team with a design lead, project manager, analysts, economists, and domain experts.
My work focused on translating complex reporting and approval requirements into clear interface structures, responsive layouts, and reusable Figma components.
I contributed to:
Workflow and approval screens
Role-based interfaces across multiple user types
Responsive layouts for desktop, tablet, and mobile
A scalable Figma component system with light and dark themes
Dashboard layouts, tables, filters, side panels, and settings screens
Tailored Views for Every Role
A data officer entering quarterly figures and a senior official reviewing national performance should not navigate the same interface.
The system used role-specific information architecture, hierarchy, and workflows built around different responsibilities.
Insight: Same data underneath, different surfaces, different defaults.


Main Dashboard
National targets, sector priorities, and project progress in one view.


Priority Sector Performance
Sector-level breakdown across manufacturing, tourism, agriculture, and more.


Program Overview
Projects within a program, with milestones and KPIs.


Project Details
Timelines, funding, milestones, and supporting entities per project.


Indicator Analysis
Performance over time with historical data drill-down.


Council Decisions
Unresolved decisions tracked by status and meeting session.


Executive View
High-level strategic overview for senior officials.
Workflow Design
The platform supported configurable approval chains with different roles, deadlines, rejection paths, and review stages.
The challenge was making complex workflow logic understandable for non-technical administrators.
Data entry
Validation
Approval
Data Officer
Input initial data.
SRO
Further analysis and data input.
MFU Lead
Data review and potential acceptance or denial.
Executive Director
Final approval step.
Data Officer
Quarterly figures entered for national indicators — structured for the review chain ahead.
SRO
Sector context, analysis notes, and supporting data added before the next review stage.
MFU Lead
Accept, return with comments, or escalate — every action logged for the audit trail.
Executive Director
Sign-off locks the data and triggers the update across connected views.
Senior Official
National targets, sector performance, and project status — without operational noise.










Insight: Admins needed to understand: who participates in the workflow, what each role can do, where rejected data returns, and when tasks move automatically.
Auto-move between stages
Tasks can transition automatically when deadlines are missed.
Flexible rejection paths
Rejected data can go back one step or restart the workflow.
Audit trails and action history
Every action is logged for accountability and transparency.
Customizable approval roles
Support for different approval hierarchies.

Configurable workflow steps
Each role can enter, review, accept, or deny data.


Data Acceptance Dashboard
Operator dashboard showing which indicators need updating, their status, and upcoming deadlines — the primary view for SRO and MFU data workers.


Colleagues Responsible
Assign reviewers per indicator and define their workflow roles.


Acceptance Schedules
Set review intervals and validation dates per indicator.


Acceptance Order
Order reviewers, set deadlines, and configure transitions.
Settings
The settings area handled user roles, permissions, data hubs, and workflow configuration.
The goal was to provide enough flexibility for organizational change without overwhelming everyday users.


Pages Management
Manage page access, names, and role permissions.


Data Hub
Oversee sectors, programs, and data entry workflows.


Edit Data Instance
Configure sector metadata, ownership, acceptance rules, datasets, milestones, and supporting entities.


User Roles
Configure permissions for pages, entities, and data.
Building a Scalable System
Requirements evolved constantly as analysts and domain experts refined workflows, approval logic, and reporting structures.
The challenge was keeping tables, filters, review states, and layout patterns consistent as the system grew in complexity.
What I Took From This Project
Design for the system, not just the screen. The most important work was defining workflows, permissions, review states, and reusable interaction patterns behind the interface.
Different roles need different information architecture. A senior official and a data officer working with the same data require different hierarchy, context, and levels of detail.
Constraints clarify decisions. Government workflows, approval chains, and dense operational data forced more disciplined and structured design decisions.














