Feature Development — Team Challenge 2.0

After several years in production across 5 client apps, it was time for a significant overhaul. I led the redesign as the primary designer, and took on project management responsibilities for the first time on a project of this scale. The pressure to update came from two directions at once.

Internally, leadership flagged that a number of Team Challenge's secondary features had fallen into disuse — the interface had accumulated dead weight that was cluttering the experience without adding value. Externally, clients were asking for something more fundamental: they wanted users to be able to join a challenge after it had already started. The original version locked team formation to the pre-competition window, which meant anyone who missed the signup period was simply excluded — a friction point that was visibly suppressing participation.

The brief, in short, was to make Team Challenge feel less like a rigid competition and more like something users could step into at any point.

Before touching any designs, my co-designer and I built a comprehensive user flow chart — mapping every possible path a user could take through the feature, from discovery to completion.

This turned out to be more revealing than expected. Because much of the original design documentation no longer existed, the flowchart became our primary tool for understanding what we actually had. It surfaced legacy design decisions that no longer made sense, exposed gaps in the experience that hadn't been formally identified, and gave us a structured way to prioritise which parts of the feature needed the most attention. Only after we had that full picture did we begin redesigning — component by component, in order of impact.

Team Challenge 2.0 was large enough that shipping it all at once wasn't an option. We broke it into 2–3 sequential releases, each of which had to go live without disrupting the experience for users already in active competitions.

The design coordination was manageable. The project management side was a steeper learning curve.

As someone stepping into a PM role for the first time at this scale, I needed to understand what each release touched: which changes were frontend only, which required backend work, which involved the back office. Without that clarity, sequencing the phases correctly and communicating the plan to engineering would have been guesswork.

I closed that gap by working closely with the engineering team from the start, and establishing a short daily briefing to keep everyone aligned as the releases progressed. It wasn't a complex system, but the consistency mattered — it meant issues surfaced quickly and decisions could be made without losing momentum.

Team Challenge 2.0 shipped across all 5 apps, reaching thousands of users. The response from clients was consistently positive — and the clearest signal came not from feedback forms but from renewal decisions and participation trends. Clients continued to subscribe year after year, and challenge participation numbers climbed steadily.

For a feature that had been running for years, that kind of sustained and growing engagement is a meaningful result.

This project marked a turning point in how I understood the relationship between design and delivery. Redesigning a feature is one thing — coordinating a phased rollout of that redesign across multiple apps, without breaking anything for existing users, is something else entirely.

The daily engineering briefings were a small habit with an outsized effect. Clear, frequent communication didn't just keep the project on track — it built the kind of trust that made it easier to raise problems early, before they became delays.

If I were doing this again, I'd push harder at the start to establish clearer success metrics with the client — specific participation targets or engagement benchmarks we could track against. The positive signals were real, but having defined measures would have made it easier to demonstrate impact and inform the next iteration.