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.

Role

Product Designer

Scope

Enterprise / B2B / Data Visualization / Government

Key impact
  • Role-based dashboard architecture
  • Multi-agency reporting workflow
  • 5 user roles supported
Multi-agencyreporting workflow
5user roles supported
4-stageConfigurable approval workflow
3Platforms: desktop, tablet, mobile

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.

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.

01 / 5

Data Officer

Quarterly figures entered for national indicators — structured for the review chain ahead.

02 / 5

SRO

Sector context, analysis notes, and supporting data added before the next review stage.

03 / 5

MFU Lead

Accept, return with comments, or escalate — every action logged for the audit trail.

04 / 5

Executive Director

Sign-off locks the data and triggers the update across connected views.

05 / 5

Senior Official

National targets, sector performance, and project status — without operational noise.

Data Officer ViewData Officer View
SRO ViewSRO View
MFU Lead ViewMFU Lead View
Executive Director ViewExecutive Director View
Senior Official ViewSenior Official View

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.

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.

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.