// Case study / Measurement sign-off
The dashboards were approved before a single one was built.
A seven-dashboard lifecycle marketing measurement framework was rendered with synthetic data so the client could interrogate and sign off on every metric ahead of the Tableau build. The prototype is live, with the client removed.
What happened
A KPI workbook became a reviewable, voteable prototype.
A financial services brand was launching lifecycle marketing journeys for its B2B customer base, with a measurement framework specified as roughly 150 KPI rows in a workbook and a production build planned in Tableau. Rather than take the workbook to sign-off, the proposed dashboards were built as a React and ECharts prototype running on seeded synthetic data at programme scale, and that prototype became the review instrument.
Two review rounds later the framework stood at 207 metrics across seven dashboards, every one of them rendered and voted on, and nine build prerequisites — the data decisions the Tableau build could not start without — had been logged before any BI work began.
Situation
Locked names, open construction, and a build waiting on agreement.
Metric names were fixed verbatim to the programme documents, so renaming anything for clarity was out of scope. The open questions were construction and calculation: which views merited their own dashboard, which should combine or split, and what each equation actually was. A workbook could not answer those questions in a way reviewers could react to, and a Tableau build that discovered the answers in production would have been the expensive way to find out.
Task
Get sign-off on the framework in a form the build team could implement.
The deliverable was an agreed specification, not a demo: every metric defined, every equation visible, every dashboard-level construction decision recorded, and the result exported as a file the build team could diff rather than meeting notes someone would have to transcribe.
Workbook150-row KPI framework
Names locked to the programme documents; construction and calculation still open.
PrototypeSeven dashboards, synthetic data
Seeded engine at programme scale: plausible enough to argue about, obviously not a data product.
Methodology panelEquation worked live
Right-click any metric: plain explanation, the formula computed with the on-screen numbers, definition, source system.
Vote and exportMarkdown sign-off matrix
Approve / needs change / question per metric, plus a construction verdict per dashboard, exported as a diffable file.
PrerequisitesNine build decisions logged
Grain and join key, segment snapshot depth, holdout design, journey overlap counting, and five scoped items.
A seeded generator produced numbers realistic enough to test a definition against and fake enough that nobody mistook the site for a pipeline. No live connection existed at any point.
The panel converted “we agree on the KPI name” into “we agree on the calculation.” Definition conflicts surfaced in the review session rather than in QA.
Each dashboard carried an explicit prompt: does this view merit its own dashboard, combine with another, or split? With naming locked, that was the real open decision.
Before any affordance shipped, the Tableau feature it mapped to was named: a goal line is a reference line; a sankey has no native equivalent and was replaced by a highlight table.
Action
The registry, not the screens, was the single source of truth.
Every metric lived in one registry — name, plain-language explanation, formal definition, equation, source system, and provenance — and the dashboards, the methodology panels, the exported CSV, and the framework workbook were all generated from it. A change agreed in review propagated to every artefact rather than being re-typed into each.
Between review rounds an in-app changelog recorded what had moved and which reviewer comment had moved it, and metrics added from feedback carried a provenance chip in their panel. Metrics that could only be modelled with placeholder logic were labelled as illustrative, so the worked-equation promise stayed honest.
Client names and reviewer identities were stripped for the public edition. The prototype runs on the same synthetic engine and is live at portfoliodashboard.fredericlabadie.com; the source is on GitHub.
Outcome
Every metric reviewed, every construction question answered.
- 207 metrics across seven dashboards, 207 of 207 rendered, inspectable, and voted on by the end of round two.
- Two review rounds, seven tagged releases, each with an in-app changelog tying revisions to the feedback that drove them.
- One construction decision made in the room: the combined reactivation view split into separate Needs Attention and Dormant dashboards after round-two feedback, each with its own retention, churn, and reactivation metrics.
- Nine build prerequisites surfaced before the Tableau build — an undefined grain and join key, quarterly segment snapshots rendered on a monthly chart, an unspecified holdout for the lift KPIs, journey-overlap counting, and five narrower items — each of which would otherwise have been found in production.
- Zero client data at any stage. The public edition is the same code with the client removed, which is only possible because the synthetic engine was the design from day one.
Design lesson
The sign-off tooling does not carry into the production tool, by design.
Every chart form in the prototype had a confirmed Tableau equivalent. The methodology panel and the per-metric vote loop had none, and did not need one: their job ended at sign-off. Chart-native equivalence and warehouse buildability turned out to be separate gates, which is why the prerequisites list exists as an artefact of its own.