Insights Central Hub

TIMELINE
Jun 2024 – Oct 2024
ROLE
Product Designer

The Situation

Client which is a business unit inside a tech conglomerate had previously released an internal Productivity Insights Dashboard, but adoption was near zero. Managers, meanwhile, lacked a quick way to gauge team health or drill into performance trends. Our mission: make the dashboard truly useful by surfacing only the “need-to-know” insights that immediately grab both developers’ and managers’ attention.

“An engineer's day over here 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

Undefined Needs at Scale
Even product owners admitted they had no clue what would be needed for this product to be useful.
Zero Initial Adoption
Engineers saw analytics as a nice-to-have, not a need-to-have, so they ignored the old tool.
Attention Scarcity
Developers only engage with tools that show instant value; managers wanted high-level summaries and actionable insights.

“The only way we can achieve this is if we were able find out the things that are "immediately interesting" towards the engineers, about which I have no idea.”
—Product Owner

The Vision

An insights dashboard that becomes an integral part of the development workflow, providing useful, actionable insights for both developers and managers. In short a tool that engineers would actually want to use.

Designing the Experience

1. Finding the Right Use Cases:

I started by stating the obvious, that the only way we can find out what people really needs is we go and talk to them. Fortunately, client-side PICs were very willing and provided help reaching out to engineers and managers to understand their needs. We had long conversations with 20+ engineers and 10+ managers trying to figure out what they would "need" and what would be "immediately interesting" to them.

All of the people we talked to shared the same sentimental that what we were trying to achieve was impossible, but were also very willing to help us out, sharing what they feel are missing from their daily workflow.

I also explicitly mentioned that they should not worry about the feasibility of the ideas they shared, and that we would figure out the technical side later. This was a very important point, as technical mindsets of engineers tend to go into details before speaking out.

At the end of the day, to all of our surprise, we actually got quite a lot to work with. So we immediately moved on to put them into use cases so that I can move forward.

2. Synthesizing Requirements into Use Cases

I analyzed all the use cases and distilled them into:

Developer Stories: post-commit analytics, pre-commit risk indicators, real-time code pipeline status.
Manager Stories: team velocity stats, SLA compliance, feature delivery statistics, upcoming sprint readiness.

Each use case was ID'ed and prefixed (e.g., ICH-001, ICH-002...) to streamline backlog management across multiple squads.

3. Defining Information Architecture

We split navigation into two primary views:

Manager:
- Tab 1: Overall Metrics & Recommendations
- Tab 2: Component & Feature Stats
Developer:
- Tab 1: Overall Metrics & Recommendations (Post-Commit Insights)
- Tab 2: Work-In-Progress (Pre-Commit Insights)

4. Design & Validation

I went atomically, from each use cases towards the bigger picture, to ensure that I don't miss any crucial details while keeping everything tied together in the most natural hierarchy possible. I also tried to replicate other tools that engineers are already using, to make sure that the product is easy to use and the engineers would feel at home immediately. The detailed steps that I follow:

Analyze raw data of related use cases to figure out best display and visualization stategy, using Grafana, Excel Sheet and PowerBI.__
Sketched wireframes to test layouts, hierarchy and navigation.
UI Design with actual data.
Two-days cycle with PICs to validate the designs.