C-MORE DASHBOARD

A dashboard that needed an interpreter

Business users relied on the product team to assemble their charts. Editing meant dragging indicators into fixed slots and looking at grey placeholders until you saved. Internal terms such as “Highest Hierarchy Company” made sense only if you already knew the database.

Before

Choose slots and indicators. Save to see the chart. Ask the product team when the schema gets confusing.

The redesign

Choose what you want to compare. See the chart as you edit. Let the system work out the right shape.

What I owned

I led the redesign from research and the data model through interaction design, data visualisation, working prototypes, and engineering handover. Between June and August 2026, I worked through roughly twenty review rounds with the head of AI, the software manager, and a reviewer focused on chart interpretability.

01 / Start with a question

“How is this changing?” needs a line chart. “How do these companies compare?” needs bars. I organised the builder around those questions, so users could choose their data without first choosing a chart type. The indicator picker shows units and data types up front, helping prevent incompatible selections.

Search by name or reporting code; see the unit before choosing an indicator.

02 / Make the selection tell the truth

My first version tracked selected entities and hierarchy depth separately. The summary could say “+10” while the chart showed one bar. Keeping the two in sync was becoming a feature of its own. I removed the separate depth state. Selecting a parent means one rollup; selecting its children means separate series. The tree and network view share that same selection.

The selected entities determine the chart. There is no second depth setting to reconcile.

03 / Don’t offer a misleading total

An “Individual / Combined” toggle let people add three of five divisions and read the result as a whole. The chart looked plausible, but the total was incomplete. I made breakdowns depend on a complete set of direct children and an indicator that can be summed. Remove a child, and the chart becomes a comparison instead.

A breakdown is shown only when the parts can honestly represent the whole.

The small demo was the easy version

I built a second synthetic dataset with 48 entities, supplier clusters approaching a thousand nodes, and long legal names. It exposed problems that tidy mockups missed: colliding labels, overwhelming selectors, and controls outside the visible chart. Those reviews shaped explicit series caps, grouped suppliers, label rules, and hover behaviour. Any remainder is shown as a declared group rather than silently dropped.

Supplier comparisons keep ownership and hierarchy visible even with deeper, denser data.

What the work delivered

The redesign became a working prototype reviewed over three months, followed by a behaviour spec, data contract, design tokens, and graph rules for engineering. This case study documents the prototype and handover. Division and supplier values are synthetic concept data; real rollups depend on the ingested organisation and value-chain data. Production adoption and business impact are not established here.

Try the reviewed prototype →

What I’m taking into the next project

When a fix gets elaborate, I ask whether the thing I’m fixing needs to exist at all.

Removing the extra selection state and aggregation toggle did more for clarity than another layer of controls.

For a closer look: chart behaviour

The underlying model is entity × indicator × time × value. Hold entity and indicator fixed to show change over time; hold time and indicator fixed to compare entities. Company identity uses hue; structural depth uses lightness. Internal operations and external suppliers receive distinct treatment. Palette choices were checked for contrast and colour-vision separation. The Compare view brings two reporting periods into one diverging chart with before/after values and a visible scale. Direction is labelled without assuming that every increase is good. The handover includes behaviour rules, data contracts, tokens, dependencies, and verified document references. The prototype’s full dataset can be explored by adding ?data=full to its URL.