Productivity Insights Dashboard

September 25, 2024 (1y ago)

Insights Central Hub

TIMELINE
Jun 2024 – Oct 2024
ROLE
Product Designer


The Situation

A business unit within a tech conglomerate had launched an internal Productivity Insights Dashboard. Adoption flatlined at 5%. Engineers, who live entirely within their IDE, saw analytics as a distraction, not a tool. Managers lacked quick visibility into team health or delivery risks. Our mission: make data indispensable by surfacing only "need-to-know" insights that immediately grab attention and drive action.

An engineer's day starts and ends with the IDE. They have no need, and would never open another window, for nothing useful to them.
—Product Owner


The Problem


The Vision

An insights dashboard that becomes integral to the development workflow, providing actionable, contextual intelligence for both developers and managers. A tool engineers would actually want to use because it saves them time and prevents mistakes, not because they were told to.


Designing the Experience

1. Uncovering Latent Needs

I started with the obvious: we had to talk to users. Client PICs connected me with 20+ engineers and 10+ managers. The initial response was skeptical, everyone agreed the goal was "probably impossible," but they were willing to help.

Critical research tactic: I explicitly told engineers to ignore feasibility. "Don't worry about whether it's possible, just tell me what you wish you knew while coding." This unlocked honest insights; their technical minds usually self-censor into "how" before articulating "what."

Key discoveries:

The surprise: Once engineers articulated their needs without filtering for feasibility, we discovered most requests were already achievable with existing internal tools and libraries. The "impossible" problem was actually a communication barrier, not a technical one.

2. Synthesizing Requirements into Use Cases

I distilled findings into two distinct mental models:

Developer Stories:

Manager Stories:

Each use case received an ID (ICH-001, ICH-002...) to streamline backlog management across multiple squads and maintain traceability from insight to feature.

3. Defining Information Architecture

We rejected a single "flexible" interface, engineers and managers have incompatible mental models. Instead, we built two distinct experiences under one navigation:

Manager View:

Developer View:

This prevented the "compromised middle" where neither audience feels served.

4. Key Design Decisions

Before visual design, we established four principles that shaped every screen:

Progressive Disclosure Architecture
Engineers resisted context-switching. The "Work-in-Progress" view analyzes uncommitted code locally, surfacing risk indicators without server transmission, addressing usability, security, and latency concerns simultaneously.

Narrative-First Data Presentation
Raw metrics failed in testing; engineers skipped charts. Auto-generated natural language summaries ("Your statistics reflect...") interpret data automatically, reducing cognitive load and preventing misinterpretation.

Actionable Over Informational
Every insight connects to specific action with quantified impact. "63% code coverage" becomes "Improvable to 82% with 5 recommended test scripts", transforming awareness into execution and ensuring the tool drives behavior change, not just data consumption.

Dual Mental Models
Splitting Manager/Developer views prevented design-by-committee compromises. Managers get strategic narrative; developers get tactical code-level intelligence. Neither audience is forced to translate the other's language.

5. Design & Validation

I worked atomically from use cases upward, ensuring no crucial details were lost while maintaining natural hierarchy. Visual language decisions were deliberate: we replicated patterns from Grafana (for testing familiarity) and IDE linting tools (for immediate recognition), but transformed the utility from "information display" to "actionable intelligence."

Four-phase validation cycle:


Final Solutions & UI

A. Manager View: Overall Metrics & Recommendations

For managers who need team health in 30 seconds

Manager Overview

Design rationale:

B. Manager View: Component & Feature Delivery Stats

When drilling into specific delivery risks

Manager Details

Design rationale:

C. Developer View: Post-Commit Insights

For developers reviewing their impact

Dev PostCommit

Design rationale:

D. Developer View: Work-in-Progress (Pre-Commit Insights)

The game-changer: preventing problems before they happen

Dev PreCommit

Design rationale:


Results & Outcomes

Within the first month of launch: