Performance Discussion Form Dashboard

When I first joined the project, the scope was already set. The four widgets had been defined, and the design request was straightforward: “Design a dashboard with four widgets to visualize important PDF data.”

​

With a pressing timeline and a clearly defined scope, the team prioritized moving forward with the existing framework and dashboard direction. I also explored opportunities to move the experience to the newer React framework and conduct deeper research into the data and user needs, but these were ultimately outside the scope of this phase. The team moved forward with the initial MVP by adding the defined widgets directly above the existing data table.

Before delivering the project to developers, I documented the design suggestions and risks I identified during this rapid design phase:

​

1. Old framework: The existing framework limited our options and design flexibility for widgets and data visualizations. We could provide users with more ways to interact with the data, but the framework restricted what we could do.

​

2. Disjointed analytics and data table: The analytics felt disconnected from the existing data table, making these two important elements feel unrelated when placed on the same screen.

​

3. Redundant data display: There was a risk of multiple widgets telling a similar story, providing more data without adding meaningful information for users.

​

4. Unclear and ambiguous status definitions: The complex status and step system could be confusing without further clarification.

The project came back to design as part of a system-wide framework update on the development side. The new ticket added only one line to the original request: “Update design to React.” I saw this as an opportunity to revisit some of the risks we had identified in Phase One and take a more thoughtful approach to the redesign.

​

I proposed a structured project plan and a more thorough design timeline. But before redesigning anything, we started by validating what we had learned from Phase One.

Most of the positive feedback was about finally having something new and more visually engaging on the page.

​

But when people talked about the actual widgets, the feedback was much more mixed. The information we chose to show didn’t always match what they cared about or needed to do.

​

Going into the research, I knew the dashboard had to serve different levels of users and balance both live and historical data. I assumed the main difference between these users would be how much data they needed to see.

​

That wasn’t really the case. The bigger difference was how they used the data. Different users came to the same dashboard looking for very different things.

A department-wide count may mean very little to a manager responsible for six people. A single pending discussion may barely register for someone overseeing an entire region.

That distinction became the foundation of the redesign.

Once I understood the two roles, another problem became clear:

Live workflow data and historical analytics were competing for the same space.

My first dashboard direction placed both data types in a single shared structure.

ACTIONABLE INFORMATION

Current discussions stay directly connected to the status table and answer questions about what needs attention now.

Selecting a summary value filters the records below, allowing users to move directly from signal → action.

​

HISTORICAL ANALYTICS

Trend-based reporting lives in a separate analytics card with one shared time range.

Because this information is valuable but less urgent, the card can collapse so current work remains visible by default.

Final Solution

The final direction keeps all data widgets on one page, with the flexibility to expand or collapse information based on what users need at the moment. This allows the dashboard to adapt to different priorities without separating the experience across multiple pages.

It also creates a clearer distinction between actionable and analytical data, making the information easier to understand and reducing competition between the two.

The status widget connects directly to the data table, allowing users to quickly filter actionable items while creating a clear visual connection between the summary and the records behind it.

One of the biggest challenges in this project was deciding what story the data should tell.

Through interviews with different types of users and conversations with stakeholders, I found that the first design had too much redundant information. Several widgets were essentially answering the same question in different ways.

​

For the new direction, I wanted each widget to have a clear purpose and support a specific user need. I reviewed every widget from the original dashboard and refined the titles and settings of the remaining widgets to make their purpose clearer.

On closer review, those were actually two different concepts.

​

STATUS Where is this discussion in its lifecycle?

​

ACTION WARNING Is something happening that requires attention?

So I separated them.

​

THE LIFECYCLE

Draft → Employee Approval → Manager Approval → In Monitoring

​

Items requiring attention — such as Waiting on Me, Monitoring Overdue, or an invalid workflow — are surfaced separately rather than treated as lifecycle states.

Because approval order can vary depending on configuration, the label alone still cannot communicate progress reliably. So I paired each approval state with a step counter:

Manager Approval · Step 2 of 4

The redesigned experience now:

• Separates actionable workflow data from historical analytics
• Gives frontline managers clearer visibility into what needs attention
• Gives leaders stronger ways to identify patterns across teams
• Introduces a consistent lifecycle and action model
• Uses trends and outliers to turn raw counts into meaningful signals

Unique and Reusable System Pattern

The status and category model was identified as reusable in other areas of the platform with similar action-versus-history patterns.

The in-card widget filtering is also documented as reference for widget-table interaction

CURRENT STATUS

R edesigned dashboard is now the top-priority initiative for the next PDF module development cycle .

Reviewed and approved by

​

Client Side Users

Design Manager

Design Team Leader

Product Department Director

Development Supervisor

Development Team and Leader

Design Team Peers

​

The redesigned direction was reviewed with key product stakeholders and executive leadership team and tested again with senior managers who participated in the earlier research.

Feedback was especially positive around:
Data visualization, action vs. history separation and dashboard structure

The review helped confirm that the redesign was moving in the right direction — both for the people using the dashboard and for the broader product system.

Gap and Opportunity

There are still gaps and proposals that didn’t fit within the scope of the Phase Two MVP. I’ve documented the related findings from my research, and future iterations could explore more granular user permissions, extended drill-down capabilities, more robust widget redirection, greater flexibility and customization, AI-powered reporting, and stronger connectivity across the system.

This project taught me not to get too attached to a solution, even when it feels certain. The design process wasn’t linear—we moved between research, design, testing, and iteration, constantly returning to the root problem and asking: Are we still telling the right story?

​

My biggest aha moment was realizing that we had two types of data serving different needs at different moments. It wasn’t enough for me as the designer to understand that distinction. The experience needed to make it obvious to the user.

​

Once that clicked, decisions around information architecture, hierarchy, and content grouping became much clearer. It changed how I think about organizing complex information and reminded me that asking the right question is often more important than jumping to a solution.

​

I also learned a lot from working closely with product partners. PMs often hold deep product knowledge, while design can help surface that knowledge by asking the right questions and challenging assumptions together. I’m grateful that my product partners stayed open to constructive feedback and worked through multiple rounds of iteration with me. That collaboration was one of the most valuable parts of this project.