Measuring what matters in production

In my day-to-day work, the production flow generates all kinds of data: how long each delivery takes, how many errors show up in QA, how many projects get approved on the first pass.

The problem isn't a lack of data, it's that it rarely turns into something you can glance at and actually use to make decisions.

I wanted to build a simple tool, with no dependency on any reporting software, that anyone in a DTP or localization workflow could use to track their own work: log each project's data and automatically see how it evolves month over month.

Choosing the right KPIs, not every possible one. I could have tracked dozens of metrics. I picked four that answered distinct, complementary questions: speed (turnaround), reliability (on-time delivery), quality (error rate), and review efficiency (first-pass approval). Every other KPI I thought of ended up being a variation of these four.

Illustrative example data, matching what ships in the downloadable template.

Normalizing so numbers can actually be compared. Counting raw errors says nothing if one month had double the volume of another. That's why error rate is calculated per 100 pages, not as an absolute number, so a heavy-volume month doesn't look artificially worse than a light one.

Separating data entry from analysis. The file has one sheet where projects get logged one by one, and a dashboard sheet that calculates itself from that data. That way whoever uses it never has to touch or understand the formulas, just log what they delivered.

Designing it for someone else to use, not just me. Same as with the standardization template, the goal was for someone who'd never seen it before to open it, understand which cells to fill in (marked in blue), and start using it without me having to explain it.

• Four KPIs, not twenty. More metrics isn't more useful information if nobody looks at them.
• Normalize by volume. Without that, comparing different months doesn't make sense.
• Separate data entry from visualization. It reduces the margin for user error and stops anyone from accidentally breaking a formula.
• Share it as a free toolkit, not just a case study. I wanted it to be something people could actually download and use, not just read about.

Building this tool made me think differently about my own work: doing things well isn't enough, you have to be able to show it, with data, in a way anyone on the team (or in a hiring process) can understand in seconds.

A good metrics system is defined as much by what it measures as by what it decides to leave out.