Zwift, its site, & the Companion App lack some shared basics

Please forgive me for possibly harping on a familiar theme. I’m a lapsed-and-returned Zwift rider, more fully engaged this cold-winter time around. I’ve just happened to go looking at today’s events on the Zwift public site, as opposed to the application itself or the companion app.

In the Companion app, we can see the day’s events. Those listings include that nice thumbnail map of the route for each event. What prompted me to come here is, the public site has a similar listing of events that doesn’t seem to include the routes they’re on! That seems like a truly strange omission to me. I can see that you’re going to do a workout about climbing, but I can’t see which hill will be involved?

The inconsistency here reminds me, of course, of badges and my completed routes not being visible anywhere but in the application itself. So strange. There’s a basic kit of information that should be shared across these ways of looking at my account.

In general I recognize the sort of leapfrogging feature sets Zwift delivers as the result of an agile development process. We love the stuff this approach delivers, truly. But there are times when maybe the next agile release, a couple on from the “MVP,” should be about consolidating the existing user experience for the sake of coherency. Pile enough new features on top of each other without tweaking the framework, and things start to feel jumbled and haphazard. (That’s an almost universal challenge faced by agile shops, I think.)

Perfectly reasonable feedback that we’re aware of and hope to resolve in the future.

I’d hazard a guess this is a result of different teams being responsible for different parts of the ecosystem, each with their own roadmap and priorities. It can be hard to line up feature parity when some things are vastly more important in one area than another.

Oh, it may very well be the immediate result of separate teams delivering similar features.

The thing is, though, I know Zwift comes to us from an “agile” team. That’s a popular, powerful way of rethinking how to deliver software. One sees signs of it in various places; if memory serves, the pace bots we have now were initially released as an “MVP” – which is a code word in agile for “minimum viable product.” The idea is to release a small feature and then guide its future development based on the feedback of users in places like this forum.

My simple attempt here is to remind the redoubtable Zwift team that sometimes new shiny features are not necessarily easy to take in for users who are still dealing with the rough-edged interfaces of ones that have already been released. Yeah, I want my Personal Best bot to ride ahead of (behind!) me the next time I ride, but if the interface for just knowing what the route I choose looks like is lacking, then some foundational work got overlooked.

I would suggest things like not showing the route for events in one place, though you have route info in nice detail elsewhere are gaps in continuity that could be as high on the priority list as other, perhaps shinier, bits of development. In the agile backlog of work, I’d bump that up a bit. That’s all.

1 Like

I agree with you. Just speculating as to why it’s they way it is.

I guess it comes down to how they have their teams structured, and whether there’s a single product owner or multiple POs grooming their own backlogs independently without any real oversight.

Agile teams can still be siloed as badly as any other team.

1 Like