Organisational Analytics Dashboard

IBM (GTS, now Kyndryl) · 2.5 years · Sole designer, web platform · End-to-end product design

Impact

• Replaced Excel-in-meetings. The dashboard became the default surface for organisational performance reviews and executive conversations. Before it, the same data lived in static spreadsheets passed around over email.
• Adopted across the GTS organisation, from team leads to global executives.
• 2.5 years of continuous evolution. The product grew from one team's analytics to the whole organisation's, and the structure held.

No hard metrics here. The work is far enough back, and the data internal enough, that I can't share specific numbers.

Context

IBM GTS had a problem typical of large enterprise IT-services organisations: information sprawled across multiple aging portals and lived primarily in Excel sheets that travelled by email. Executive meetings spent half their time interpreting numbers that should have been readable at a glance.

The brief: build a single dashboard that pulled all organisational analytics into one place, with a modern look, that scaled across every data source GTS produced. It started as a hybrid mobile app, was reborn as web-only, and grew from one team's analytics surface to the surface for the entire organisation.

Three designers had worked on the earlier mobile phase. I came on for the web platform, and over time became the sole designer on it.

What I owned

I joined as a junior designer and became the sole designer on the web platform. What I owned by the end:

• The web platform end-to-end. Information architecture, data viz patterns, page templates, the filter model. Everything a user touched on the web product.
• Direct stakeholder relationships. No PM in the middle. I ran sprint kickoffs with the client lead, distilled requirements, and shipped against them sprint after sprint.
• The data visualisation layer. Dozens of data sources, hundreds of metrics, one library (D3) we were constrained to. Picking the right chart for each data shape, within D3's available patterns, was most of the job.
• Filtering and information architecture. With this much data, the filter model decided whether the platform stayed usable or became another Excel. I owned that structure.

How the work was shaped

A few things defined how this project ran:

• Sprint-based and client-direct. Every sprint started with a brainstorming session with the client lead. Requirements were specific and the client had a clear picture of what they wanted. My job was to structure and visualise, not to define the product.
• Constrained to D3. We used the charts available in the D3 library, so I designed within that palette rather than around it. It kept the build shippable.
• Built for a scope that kept growing. The dashboard's job expanded constantly: new teams, new metrics, new chart types. The biggest thing I took from the project was designing so new content could drop in without rebuilding the structure each time.

Cross-functional

• Stakeholders. Direct line to the client lead. Sprint kickoffs, requirements distillation, mid-sprint check-ins. With no PM layer, requirements lived or died on the strength of the design conversation.
• Engineering. Constrained by the D3 library and the pre-set component system. Worked closely with Eng on what was practical to build in each sprint.

What I'd do differently

I'd understand the whys more. This was an execution-heavy phase of my career. I was structuring and visualising what the client asked for, sprint by sprint, without pushing on why each thing mattered or whether it was the right thing to build.

With the experience I have now, I'd strategise it: question the requirements, dig into what decisions the dashboard was actually meant to support, and shape the product rather than just structure it. The execution skills I built here are the foundation everything since has stood on. But I'd bring strategy to it from day one.