Part 3: Feeling the Vibe (Coding), What We Can Claim Right Now

We don’t have a tidy set of results yet, and this part is about why.

When rework was never the problem

The way we work meant we created designs and sent them to engineering, and because so much was tied to the requirements, there weren’t loads of rounds of changes. That sounds like a small operational detail, but it mattered the moment we tried to measure anything. Finding metrics and return on investment was a real challenge. You can’t measure a reduction in rework if rework was never really your problem.

Where we are right now

In all honesty, we’re still working out what the metrics look like. We’re in the early stages of learning and trying to understand what’s going on.

What I’m thinking about is how quickly we can get from an idea to a prototype tested with users. I’m also thinking about how we align that to business metrics, and what the handover between design and engineering looks like. That handover is one gap we haven’t fully tested in the pipeline yet, so it’s next on the list, along with working out what our baseline looks like.

The Bottom Line: You won’t have your baseline ready by the time you need to report progress. Build the tracking framework before you need the numbers, not after someone asks for them.

What success looks like today

For me, a big win is that the design system is in place. The whole team is onboarded on the tooling, and we have a good idea of what works and what doesn’t. It’s very much a work in progress.

Which is the whole point of writing this down now rather than in a year’s time with a tidy set of numbers. The metrics will come. Right now we have a team that can work in a codebase they couldn’t touch six months ago, and that’s worth something even before it shows up on a dashboard.

I recorded my thoughts on this case study out loud, then used Claude to transcribe them and draft them into writing. I reviewed and edited the result, so the ideas, experiences and opinions are all mine.