Dashboard Redesign

The Starting Point

A company-wide initiative launched with a clear deliverable: design 12 new dashboard widgets by year-end. The OKR was set. Executive expectations were aligned. The pressure was on to execute.

But when I entered the project, the scale of the problem became clear. Dashboards launched empty by default — admins or users had to manually add and configure everything themselves. Until they did, there was nothing to see. Without a way for admins to efficiently set up and push dashboards to their users, even the best-designed widgets would sit unused. The visible problem was a missing feature set. The real problem was that the system lacked the setup infrastructure to deliver value from day one.

The work that followed grew from an OKR into a system: a Dashboard Manager, a scalable admin workflow, and a widget library backed by over 180 customer votes across four product ideas.

Role & Scope

I led UX design from the discovery phase through concept validation and executive alignment — establishing the design vision, facilitating the sprint, defining the widget concept framework, and setting the patterns that guided the team through release. Once the foundation was established and leadership was aligned, I transitioned to embed UX on an established product team that had been operating without a dedicated UX presence, where I brought the same research-led approach to an entirely different class of user problem. A second designer carried this work through pixel-perfect handoff and release with my support available throughout. The core patterns I established remained largely intact at launch.

User Research

Research was led by our Product Manager; I participated as a strategic observer and active collaborator — taking notes, asking follow-up questions in real time, helping reframe questions to surface user needs rather than validate assumptions, and identifying the themes and excerpts that would later shape how we communicated the problem to leadership. Three distinct user types emerged.

Research Synthesis

I synthesized findings across all 15 participants using a rainbow sheet — mapping themes against individual participants to surface patterns. The ranked output made the priorities undeniable: admin setup and impersonation topped the list by a wide margin, validating the decision to expand scope.

The Real Cost of Setup

Before this project, there were no pre-built widgets, no dashboard library, and no way to push dashboards to users by role or group. If an admin needed 20 employees to have the same dashboard, the process was entirely manual — repeated from scratch for every single person.

Making the Pain Visible to Leadership

A synthesis document alone wouldn't move an OKR. I needed executives to feel the problem, not just read about it. I carefully selected excerpts from our research sessions and edited them into a highlight video — district admins describing their daily reality in their own words. Our Product Manager shared the video with the executive team. Three pain points echoed across every participant:

The Core Insight

Admins are not just users of the dashboard; they are the critical enablers of every other user's experience. If admins can't efficiently configure and push dashboards at scale, no end user ever reaches the data value the product is capable of delivering. Solving the admin workflow wasn't a scope expansion — it was the opportunity to make all 12 widgets actually matter.

Why a Sprint

Stakeholders agreed on the OKR but not on the solution. Without a structured session, the team risked months of iterating on the wrong framing. I co-facilitated a 3-day Design Sprint 2.0 to bring product, engineering, and leadership into a shared problem-solving space and to generate a prototype worth testing against real users.

The artifact below represents the key outputs: a shared long-term goal, sprint questions to constrain scope, user maps for both admin paths, concepts voted on to prototype, and lightning demo takeaways gathered from competitive products.

Research & Validation Timeline

User research spanned four months and ran in phases — stakeholders first, then customers, then a design sprint to translate what we'd learned into something testable. Formal validation with Spring User Groups ran in March and April.

Defining What 12 Widgets Should Actually Be

The OKR called for 12 widgets, but no one had defined what that meant. I drove that definition. Working with Product Line Managers across the student and business sides of the product, I facilitated whiteboarding sessions to identify what would genuinely be useful for district administrators and staff. I then wireframed initial concepts and brought them to a stakeholder group that included the sales team — who had a strong read on customer demand and what was being requested in the field.

A key principle guided all of it: the chart type should match what the data needs to communicate. Using four data story categories, I advocated for intentional chart selection rather than defaulting to whatever looked good. I also held firm against 3D charts — a pattern in our existing product — because 3D formatting distorts data values and makes accurate reading nearly impossible.

Through multiple sessions with both student and business product line managers and sales stakeholders — visualizing concepts in real time, gathering feedback, refining — we landed on the core widget framework from which everything else was built. From there, three junior designers worked on focused design tasks under my direction. Through that collaboration, Group By emerged as a feature: the ability to slice the same dataset across multiple meaningful dimensions without rebuilding the chart.

Widget Use Cases

The 12 widgets were scoped to real user needs: action items that needed surface-level visibility, charts for operational data, quick utilities for everyday tasks, and activity feeds.

Bar Chart: Student Enrollment

A bar chart is the right tool for comparing values across categories — in this case, enrollment counts across entities, grade levels, and more. The Student Enrollment widget lets users toggle between grouped and stacked bar views, apply quick filters, and navigate to a full backing screen for data-dense exploration. Selecting any bar opens a contextual navigation menu linked directly to the records behind that data point.

Pie Chart: Portal Engagement

A pie chart communicates simple share of a total — when there are two or a small number of parts to compare. The Portal Engagement widget uses this format to show the ratio of logged-in to not-logged-in users: an at-a-glance adoption metric that prompts action without requiring interpretation. It's filterable by display type, segmenting by Family Access or other role-based views.

Chart Features in Action: Discipline Incidents

The Discipline Incidents widget shows how the chart interaction system works together. Each feature was designed to let users move from a summary view to the records behind it — without losing context at any step.

Selecting a bar opens a contextual menu with options to navigate to a filtered list screen or drill into a specific data subset. A tooltip on hover surfaces the breakdown and totals for that segment in context.

Tooltip and Contextual Navigation

Drill-Down: Moving Through the Data

Selecting a data segment doesn't just show a tooltip — it re-renders the chart itself. The user drills into a specific entity and the chart re-renders around that subset, with breadcrumb navigation showing exactly where in the data hierarchy they are. Each level is independently explorable, with the same Group By, filter, and tooltip interactions available throughout.

Configuration: Admin Control Before Publishing

Before any widget reaches a user's dashboard, admins configure it. The configuration screen lets them set a display title, toggle hover effects and value labels, and choose tile size from a visual grid picker. A live preview panel on the right updates in real time — admins see exactly how the widget will appear before committing.

Measured Outcomes

The core UX patterns I established were carried through to release, and post-launch satisfaction data confirmed the approach — you can read how it shipped in the product's own words.

Continued Investment

The success of this visualization system created momentum. New widgets are in active research and early testing — a direct continuation of the design patterns and interaction model established in this project. The work didn't end at release. It became the foundation for ongoing product investment in K–12 data visualization.