Zahid Al Muhasibi
Digital Product Research & Design
Research
Desktop
Designing Action-Driven Dashboards
Redesigning reporting experiences to help teams identify priorities, risks, and operational signals faster.
Redesigning reporting experiences to help teams identify priorities, risks, and operational signals faster.
View Full Research Documentation
01 Context & Challenge
Context
This project focuses on redesigning an internal Project Management Office (PMO) system used by Bandung Techno Park to manage project documentation, monitor project progress, track financial performance, and support evaluation activities across multiple ongoing projects.
The primary users include project committees, administrators, and operational teams responsible for monitoring project health and ensuring project activities stay aligned with business objectives.
In this environment, the interface serves more than a reporting function. It directly influences how efficiently users can assess project status, identify risks, and make operational decisions. Existing research and stakeholder interviews revealed that while the system contained the necessary information, the experience often failed to support how users actually worked and made decisions.
The Problem
The existing PMO system suffered from several usability and information architecture issues.
Project information was available, but users struggled to quickly identify what required attention. Dashboard content felt cluttered, project assessments still relied on manual processes, and important information was often buried among secondary data. Stakeholders also reported that the interface felt inefficient and did not adequately support their daily workflows.
As a result:
Users spent excessive time searching for relevant information.
Critical project and financial signals were difficult to interpret.
Decision-making relied heavily on manual verification.
The dashboard functioned more as a reporting tool than a decision-support tool.
UI Needs & Constraints
Several recurring patterns emerged throughout the research process:
Users don't miss information. They miss important signals.
Most critical project and financial information already existed within the system. However, users frequently overlooked it because the interface did not clearly communicate relevance or priority.Risk recognition is more important than data availability.
The challenge was not providing more information. The challenge was helping users recognize which information mattered first.Monitoring environments require rapid interpretation.
Users often managed multiple projects simultaneously. Long scanning times and repeated verification increased cognitive effort and reduced operational efficiency.
Framing the Core Challenge
At its core, this project was not about adding new functionality.
The challenge was redesigning the experience so users could recognize project risks, understand financial health, and identify priorities more quickly without increasing cognitive load.
The goal became:
How might we help users recognize emerging project risks before they become operational problems?
Design Lens
This redesign was guided by a simple principle:
Dashboards should not merely display information. They should help users understand where attention is needed.
In operational systems, users rarely suffer from a lack of data. Instead, they struggle to determine which information deserves action and which information can safely be ignored.
“The best designs help people focus on what matters most at the moment it matters.” — Inspired by Nielsen Norman Group usability principles
This perspective shifted the design effort away from feature expansion and toward signal visibility, prioritization, and decision support.
01 Context & Challenge
Context
This project focuses on redesigning an internal Project Management Office (PMO) system used by Bandung Techno Park to manage project documentation, monitor project progress, track financial performance, and support evaluation activities across multiple ongoing projects.
The primary users include project committees, administrators, and operational teams responsible for monitoring project health and ensuring project activities stay aligned with business objectives.
In this environment, the interface serves more than a reporting function. It directly influences how efficiently users can assess project status, identify risks, and make operational decisions. Existing research and stakeholder interviews revealed that while the system contained the necessary information, the experience often failed to support how users actually worked and made decisions.
The Problem
The existing PMO system suffered from several usability and information architecture issues.
Project information was available, but users struggled to quickly identify what required attention. Dashboard content felt cluttered, project assessments still relied on manual processes, and important information was often buried among secondary data. Stakeholders also reported that the interface felt inefficient and did not adequately support their daily workflows.
As a result:
Users spent excessive time searching for relevant information.
Critical project and financial signals were difficult to interpret.
Decision-making relied heavily on manual verification.
The dashboard functioned more as a reporting tool than a decision-support tool.
UI Needs & Constraints
Several recurring patterns emerged throughout the research process:
Users don't miss information. They miss important signals.
Most critical project and financial information already existed within the system. However, users frequently overlooked it because the interface did not clearly communicate relevance or priority.Risk recognition is more important than data availability.
The challenge was not providing more information. The challenge was helping users recognize which information mattered first.Monitoring environments require rapid interpretation.
Users often managed multiple projects simultaneously. Long scanning times and repeated verification increased cognitive effort and reduced operational efficiency.
Framing the Core Challenge
At its core, this project was not about adding new functionality.
The challenge was redesigning the experience so users could recognize project risks, understand financial health, and identify priorities more quickly without increasing cognitive load.
The goal became:
How might we help users recognize emerging project risks before they become operational problems?
Design Lens
This redesign was guided by a simple principle:
Dashboards should not merely display information. They should help users understand where attention is needed.
In operational systems, users rarely suffer from a lack of data. Instead, they struggle to determine which information deserves action and which information can safely be ignored.
“The best designs help people focus on what matters most at the moment it matters.” — Inspired by Nielsen Norman Group usability principles
This perspective shifted the design effort away from feature expansion and toward signal visibility, prioritization, and decision support.
01 Context & Challenge
Context
This project focuses on redesigning an internal Project Management Office (PMO) system used by Bandung Techno Park to manage project documentation, monitor project progress, track financial performance, and support evaluation activities across multiple ongoing projects.
The primary users include project committees, administrators, and operational teams responsible for monitoring project health and ensuring project activities stay aligned with business objectives.
In this environment, the interface serves more than a reporting function. It directly influences how efficiently users can assess project status, identify risks, and make operational decisions. Existing research and stakeholder interviews revealed that while the system contained the necessary information, the experience often failed to support how users actually worked and made decisions.
The Problem
The existing PMO system suffered from several usability and information architecture issues.
Project information was available, but users struggled to quickly identify what required attention. Dashboard content felt cluttered, project assessments still relied on manual processes, and important information was often buried among secondary data. Stakeholders also reported that the interface felt inefficient and did not adequately support their daily workflows.
As a result:
Users spent excessive time searching for relevant information.
Critical project and financial signals were difficult to interpret.
Decision-making relied heavily on manual verification.
The dashboard functioned more as a reporting tool than a decision-support tool.
UI Needs & Constraints
Several recurring patterns emerged throughout the research process:
Users don't miss information. They miss important signals.
Most critical project and financial information already existed within the system. However, users frequently overlooked it because the interface did not clearly communicate relevance or priority.Risk recognition is more important than data availability.
The challenge was not providing more information. The challenge was helping users recognize which information mattered first.Monitoring environments require rapid interpretation.
Users often managed multiple projects simultaneously. Long scanning times and repeated verification increased cognitive effort and reduced operational efficiency.
Framing the Core Challenge
At its core, this project was not about adding new functionality.
The challenge was redesigning the experience so users could recognize project risks, understand financial health, and identify priorities more quickly without increasing cognitive load.
The goal became:
How might we help users recognize emerging project risks before they become operational problems?
Design Lens
This redesign was guided by a simple principle:
Dashboards should not merely display information. They should help users understand where attention is needed.
In operational systems, users rarely suffer from a lack of data. Instead, they struggle to determine which information deserves action and which information can safely be ignored.
“The best designs help people focus on what matters most at the moment it matters.” — Inspired by Nielsen Norman Group usability principles
This perspective shifted the design effort away from feature expansion and toward signal visibility, prioritization, and decision support.
01 Context & Challenge
Context
This project focuses on redesigning an internal Project Management Office (PMO) system used by Bandung Techno Park to manage project documentation, monitor project progress, track financial performance, and support evaluation activities across multiple ongoing projects.
The primary users include project committees, administrators, and operational teams responsible for monitoring project health and ensuring project activities stay aligned with business objectives.
In this environment, the interface serves more than a reporting function. It directly influences how efficiently users can assess project status, identify risks, and make operational decisions. Existing research and stakeholder interviews revealed that while the system contained the necessary information, the experience often failed to support how users actually worked and made decisions.
The Problem
The existing PMO system suffered from several usability and information architecture issues.
Project information was available, but users struggled to quickly identify what required attention. Dashboard content felt cluttered, project assessments still relied on manual processes, and important information was often buried among secondary data. Stakeholders also reported that the interface felt inefficient and did not adequately support their daily workflows.
As a result:
Users spent excessive time searching for relevant information.
Critical project and financial signals were difficult to interpret.
Decision-making relied heavily on manual verification.
The dashboard functioned more as a reporting tool than a decision-support tool.
UI Needs & Constraints
Several recurring patterns emerged throughout the research process:
Users don't miss information. They miss important signals.
Most critical project and financial information already existed within the system. However, users frequently overlooked it because the interface did not clearly communicate relevance or priority.Risk recognition is more important than data availability.
The challenge was not providing more information. The challenge was helping users recognize which information mattered first.Monitoring environments require rapid interpretation.
Users often managed multiple projects simultaneously. Long scanning times and repeated verification increased cognitive effort and reduced operational efficiency.
Framing the Core Challenge
At its core, this project was not about adding new functionality.
The challenge was redesigning the experience so users could recognize project risks, understand financial health, and identify priorities more quickly without increasing cognitive load.
The goal became:
How might we help users recognize emerging project risks before they become operational problems?
Design Lens
This redesign was guided by a simple principle:
Dashboards should not merely display information. They should help users understand where attention is needed.
In operational systems, users rarely suffer from a lack of data. Instead, they struggle to determine which information deserves action and which information can safely be ignored.
“The best designs help people focus on what matters most at the moment it matters.” — Inspired by Nielsen Norman Group usability principles
This perspective shifted the design effort away from feature expansion and toward signal visibility, prioritization, and decision support.
02 Problem Framing & Analysis
Key Insight
During usability testing and stakeholder interviews, a consistent pattern emerged.
Users could usually find the information they needed.
What they struggled with was understanding its significance quickly enough to act confidently.
Project risks, delayed milestones, and financial concerns often became visible only after users intentionally searched for them. Important signals existed, but they lacked sufficient emphasis.
Users rarely miss information. They miss important signals hidden within information.
This insight became the foundation for the redesign.
Instead of asking how more data could be presented, the project focused on helping users recognize what deserves attention earlier in the decision-making process.
Data & Process Behind the Insights
To better understand user behavior, the project followed a Design Thinking process consisting of stakeholder interviews, problem definition, ideation, prototyping, and usability testing.
1
Task-based usability testing
2
Observation & verification
3
Qualitative feedback
The objective was not only to identify usability issues but also to understand how users interpreted project and financial information during real operational tasks.
Why This Matters?
In project environments, delayed recognition often leads to delayed action.
When users cannot quickly identify project risks or financial concerns, they spend more time validating information and less time responding to issues.
Over time, this reduces efficiency, increases operational friction, and weakens confidence in the system as a decision-support tool.
02 Problem Framing & Analysis
Key Insight
During usability testing and stakeholder interviews, a consistent pattern emerged.
Users could usually find the information they needed.
What they struggled with was understanding its significance quickly enough to act confidently.
Project risks, delayed milestones, and financial concerns often became visible only after users intentionally searched for them. Important signals existed, but they lacked sufficient emphasis.
Users rarely miss information. They miss important signals hidden within information.
This insight became the foundation for the redesign.
Instead of asking how more data could be presented, the project focused on helping users recognize what deserves attention earlier in the decision-making process.
Data & Process Behind the Insights
To better understand user behavior, the project followed a Design Thinking process consisting of stakeholder interviews, problem definition, ideation, prototyping, and usability testing.
1
Task-based usability testing
2
Observation & verification
3
Qualitative feedback
The objective was not only to identify usability issues but also to understand how users interpreted project and financial information during real operational tasks.
Why This Matters?
In project environments, delayed recognition often leads to delayed action.
When users cannot quickly identify project risks or financial concerns, they spend more time validating information and less time responding to issues.
Over time, this reduces efficiency, increases operational friction, and weakens confidence in the system as a decision-support tool.
02 Problem Framing & Analysis
Key Insight
During usability testing and stakeholder interviews, a consistent pattern emerged.
Users could usually find the information they needed.
What they struggled with was understanding its significance quickly enough to act confidently.
Project risks, delayed milestones, and financial concerns often became visible only after users intentionally searched for them. Important signals existed, but they lacked sufficient emphasis.
Users rarely miss information. They miss important signals hidden within information.
This insight became the foundation for the redesign.
Instead of asking how more data could be presented, the project focused on helping users recognize what deserves attention earlier in the decision-making process.
Data & Process Behind the Insights
To better understand user behavior, the project followed a Design Thinking process consisting of stakeholder interviews, problem definition, ideation, prototyping, and usability testing.
1
Task-based usability testing
2
Observation & verification
3
Qualitative feedback
The objective was not only to identify usability issues but also to understand how users interpreted project and financial information during real operational tasks.
Why This Matters?
In project environments, delayed recognition often leads to delayed action.
When users cannot quickly identify project risks or financial concerns, they spend more time validating information and less time responding to issues.
Over time, this reduces efficiency, increases operational friction, and weakens confidence in the system as a decision-support tool.
02 Problem Framing & Analysis
03 Executing the Vision
Design Implementation
The redesign focused on transforming the dashboard from a passive reporting interface into a decision-support system.
Instead of treating all information equally, the experience was redesigned to help users:
Detect risk earlier
Interpret project health faster
Prioritize attention more effectively
Act with greater confidence
The following two cases demonstrate how these principles were translated into interface decisions.
Case 1: Making Project Risk Visible Before Deadlines Are Missed
Project delays rarely occur because of a single missed task.
More often, they emerge gradually through incomplete milestones, undefined deadlines, and unresolved project phases.
The milestone overview was redesigned to make these early warning signals easier to identify before they evolved into larger operational issues.
Implementation Decisions:
Phase-based project structure
Project work is grouped into meaningful phases (Initiation, Binding, S-Curve, UAT, BAST, Billing), allowing users to assess progress at a glance without scanning individual items.Explicit completion and incompletion states
Each phase clearly communicates its status (Complete, Incomplete), removing ambiguity around “almost done” work.Progress indicators tied to accountability, not activity
Progress percentages reflect actual completion, not mere task interaction, preventing false confidence.Visibility of missing or undefined deadlines
Items without deadlines (“Not Set Yet”) are intentionally visible, signaling risk instead of hiding uncertainty.
Design Rationale
The goal was not simply to display project status.
The goal was to help users identify potential project risks before deadlines were affected.
By making incomplete phases and unresolved milestones more visible, the interface encourages earlier intervention and more proactive project management.
Good dashboards don't wait for failure to become obvious. They make emerging risk visible while action is still possible.
Case 2: Making Financial Health Easier to Interpret
Project dashboard as a financial reality check. If the milestone view answers “Are we If milestone tracking answers:
"Are projects progressing as expected?"
Financial monitoring answers:
"Are projects still operating within healthy boundaries?"
Many project systems treat financial information as historical reporting. As a result, users often discover financial concerns only after deviations become significant.
This redesign reframed financial information as an early-warning mechanism rather than a retrospective report.
Implementation Decisions:
Budget summarized into a single, interpretable signal
Instead of forcing users to parse multiple numbers, budget health is condensed into a clear ratio between spending and remaining balance.Visual contrast to signal risk, not progress
The spending indicator uses contrasting colors to emphasize exposure, not achievement — intentionally avoiding “progress feels good” bias.Curve-S comparison between target vs realization
Progress is shown against expectation, not in isolation, helping users detect deviation early rather than celebrating movement.Immediate action affordance at the point of risk
“Input Progress” is placed directly within the risk context, reducing friction between awareness and corrective action.
Design Rationale
Financial issues rarely become critical overnight.
They usually emerge through small deviations that go unnoticed until corrective options become limited.
The redesign helps users recognize these deviations earlier while they still have the ability to intervene.
Financial data becomes valuable when it helps people predict outcomes, not just review history.
03 Executing the Vision
Design Implementation
The redesign focused on transforming the dashboard from a passive reporting interface into a decision-support system.
Instead of treating all information equally, the experience was redesigned to help users:
Detect risk earlier
Interpret project health faster
Prioritize attention more effectively
Act with greater confidence
The following two cases demonstrate how these principles were translated into interface decisions.
Case 1: Making Project Risk Visible Before Deadlines Are Missed
Project delays rarely occur because of a single missed task.
More often, they emerge gradually through incomplete milestones, undefined deadlines, and unresolved project phases.
The milestone overview was redesigned to make these early warning signals easier to identify before they evolved into larger operational issues.
Implementation Decisions:
Phase-based project structure
Project work is grouped into meaningful phases (Initiation, Binding, S-Curve, UAT, BAST, Billing), allowing users to assess progress at a glance without scanning individual items.Explicit completion and incompletion states
Each phase clearly communicates its status (Complete, Incomplete), removing ambiguity around “almost done” work.Progress indicators tied to accountability, not activity
Progress percentages reflect actual completion, not mere task interaction, preventing false confidence.Visibility of missing or undefined deadlines
Items without deadlines (“Not Set Yet”) are intentionally visible, signaling risk instead of hiding uncertainty.
Design Rationale
The goal was not simply to display project status.
The goal was to help users identify potential project risks before deadlines were affected.
By making incomplete phases and unresolved milestones more visible, the interface encourages earlier intervention and more proactive project management.
Good dashboards don't wait for failure to become obvious. They make emerging risk visible while action is still possible.
Case 2: Making Financial Health Easier to Interpret
Project dashboard as a financial reality check. If the milestone view answers “Are we If milestone tracking answers:
"Are projects progressing as expected?"
Financial monitoring answers:
"Are projects still operating within healthy boundaries?"
Many project systems treat financial information as historical reporting. As a result, users often discover financial concerns only after deviations become significant.
This redesign reframed financial information as an early-warning mechanism rather than a retrospective report.
Implementation Decisions:
Budget summarized into a single, interpretable signal
Instead of forcing users to parse multiple numbers, budget health is condensed into a clear ratio between spending and remaining balance.Visual contrast to signal risk, not progress
The spending indicator uses contrasting colors to emphasize exposure, not achievement — intentionally avoiding “progress feels good” bias.Curve-S comparison between target vs realization
Progress is shown against expectation, not in isolation, helping users detect deviation early rather than celebrating movement.Immediate action affordance at the point of risk
“Input Progress” is placed directly within the risk context, reducing friction between awareness and corrective action.
Design Rationale
Financial issues rarely become critical overnight.
They usually emerge through small deviations that go unnoticed until corrective options become limited.
The redesign helps users recognize these deviations earlier while they still have the ability to intervene.
Financial data becomes valuable when it helps people predict outcomes, not just review history.
03 Executing the Vision
Design Implementation
The redesign focused on transforming the dashboard from a passive reporting interface into a decision-support system.
Instead of treating all information equally, the experience was redesigned to help users:
Detect risk earlier
Interpret project health faster
Prioritize attention more effectively
Act with greater confidence
The following two cases demonstrate how these principles were translated into interface decisions.
Case 1: Making Project Risk Visible Before Deadlines Are Missed
Project delays rarely occur because of a single missed task.
More often, they emerge gradually through incomplete milestones, undefined deadlines, and unresolved project phases.
The milestone overview was redesigned to make these early warning signals easier to identify before they evolved into larger operational issues.
Implementation Decisions:
Phase-based project structure
Project work is grouped into meaningful phases (Initiation, Binding, S-Curve, UAT, BAST, Billing), allowing users to assess progress at a glance without scanning individual items.Explicit completion and incompletion states
Each phase clearly communicates its status (Complete, Incomplete), removing ambiguity around “almost done” work.Progress indicators tied to accountability, not activity
Progress percentages reflect actual completion, not mere task interaction, preventing false confidence.Visibility of missing or undefined deadlines
Items without deadlines (“Not Set Yet”) are intentionally visible, signaling risk instead of hiding uncertainty.
Design Rationale
The goal was not simply to display project status.
The goal was to help users identify potential project risks before deadlines were affected.
By making incomplete phases and unresolved milestones more visible, the interface encourages earlier intervention and more proactive project management.
Good dashboards don't wait for failure to become obvious. They make emerging risk visible while action is still possible.
Case 2: Making Financial Health Easier to Interpret
Project dashboard as a financial reality check. If the milestone view answers “Are we If milestone tracking answers:
"Are projects progressing as expected?"
Financial monitoring answers:
"Are projects still operating within healthy boundaries?"
Many project systems treat financial information as historical reporting. As a result, users often discover financial concerns only after deviations become significant.
This redesign reframed financial information as an early-warning mechanism rather than a retrospective report.
Implementation Decisions:
Budget summarized into a single, interpretable signal
Instead of forcing users to parse multiple numbers, budget health is condensed into a clear ratio between spending and remaining balance.Visual contrast to signal risk, not progress
The spending indicator uses contrasting colors to emphasize exposure, not achievement — intentionally avoiding “progress feels good” bias.Curve-S comparison between target vs realization
Progress is shown against expectation, not in isolation, helping users detect deviation early rather than celebrating movement.Immediate action affordance at the point of risk
“Input Progress” is placed directly within the risk context, reducing friction between awareness and corrective action.
Design Rationale
Financial issues rarely become critical overnight.
They usually emerge through small deviations that go unnoticed until corrective options become limited.
The redesign helps users recognize these deviations earlier while they still have the ability to intervene.
Financial data becomes valuable when it helps people predict outcomes, not just review history.
03 Executing the Vision
Design Implementation
The redesign focused on transforming the dashboard from a passive reporting interface into a decision-support system.
Instead of treating all information equally, the experience was redesigned to help users:
Detect risk earlier
Interpret project health faster
Prioritize attention more effectively
Act with greater confidence
The following two cases demonstrate how these principles were translated into interface decisions.
Case 1: Making Project Risk Visible Before Deadlines Are Missed
Project delays rarely occur because of a single missed task.
More often, they emerge gradually through incomplete milestones, undefined deadlines, and unresolved project phases.
The milestone overview was redesigned to make these early warning signals easier to identify before they evolved into larger operational issues.
Implementation Decisions:
Phase-based project structure
Project work is grouped into meaningful phases (Initiation, Binding, S-Curve, UAT, BAST, Billing), allowing users to assess progress at a glance without scanning individual items.Explicit completion and incompletion states
Each phase clearly communicates its status (Complete, Incomplete), removing ambiguity around “almost done” work.Progress indicators tied to accountability, not activity
Progress percentages reflect actual completion, not mere task interaction, preventing false confidence.Visibility of missing or undefined deadlines
Items without deadlines (“Not Set Yet”) are intentionally visible, signaling risk instead of hiding uncertainty.
Design Rationale
The goal was not simply to display project status.
The goal was to help users identify potential project risks before deadlines were affected.
By making incomplete phases and unresolved milestones more visible, the interface encourages earlier intervention and more proactive project management.
Good dashboards don't wait for failure to become obvious. They make emerging risk visible while action is still possible.
Case 2: Making Financial Health Easier to Interpret
Project dashboard as a financial reality check. If the milestone view answers “Are we If milestone tracking answers:
"Are projects progressing as expected?"
Financial monitoring answers:
"Are projects still operating within healthy boundaries?"
Many project systems treat financial information as historical reporting. As a result, users often discover financial concerns only after deviations become significant.
This redesign reframed financial information as an early-warning mechanism rather than a retrospective report.
Implementation Decisions:
Budget summarized into a single, interpretable signal
Instead of forcing users to parse multiple numbers, budget health is condensed into a clear ratio between spending and remaining balance.Visual contrast to signal risk, not progress
The spending indicator uses contrasting colors to emphasize exposure, not achievement — intentionally avoiding “progress feels good” bias.Curve-S comparison between target vs realization
Progress is shown against expectation, not in isolation, helping users detect deviation early rather than celebrating movement.Immediate action affordance at the point of risk
“Input Progress” is placed directly within the risk context, reducing friction between awareness and corrective action.
Design Rationale
Financial issues rarely become critical overnight.
They usually emerge through small deviations that go unnoticed until corrective options become limited.
The redesign helps users recognize these deviations earlier while they still have the ability to intervene.
Financial data becomes valuable when it helps people predict outcomes, not just review history.