Leading a multi-team redesign of MegaFon's main screen
Two months before release, the design lead had left and the integrated build was not shippable. I stepped in and led it to launch without formal authority over the teams.
About
MegaFon is one of Russia's largest telecom operators, with more than 77 million subscribers. Customers use its app to manage their plan, monitor usage, make payments, and discover additional services. The main screen connects all of those jobs.
The company was redesigning it while rolling out a new design system. More than four product teams were involved, each responsible for a different block. I joined mid-project and took responsibility for bringing their work together for release.
Outcome
We released the redesigned main screen on schedule and on the new design system. Although separate teams built its blocks, the final screen worked as one product.
After launch, payment transactions grew ×1.5, monthly active users ×1.5, daily active users ×2, and revenue 30%.
Problem
Two months before release, the original design lead left. No one had formal authority over all the teams, but their work now had to come together in one integrated build.
At the first build review, it did not. Individual blocks were reasonable in isolation, yet the full screen had no stable hierarchy. Components, spacing, and behavior changed between blocks, while every stream had a different view of what deserved attention.
The first instinct was to send each team back to polish its work. I saw a different problem: the blocks were not failing on their own; the seams between them were failing. Improving each part independently would not make the screen coherent.
I also could not assign work or overrule the other streams. The project had to move through alignment, not authority.
Getting the streams aligned
Research the users and the market together.
I first tried group calls, but they produced discussion rather than clarity. Teams arrived with different context, and conversations turned into defending local decisions.
I replaced open-ended discussion with a design specification. It explained the relevant design-system rules, showed where the build diverged from them, and defined how blocks should work together. Teams could now compare the build with one standard instead of challenging one another's choices.
Align one-to-one, then ratify together
A specification alone was not enough. Introducing it for the first time in a large meeting would have moved the same disagreements into a document.
I reviewed the rules with each designer, surfaced constraints, and resolved objections first. The next group meeting was a ratification rather than another negotiation: everyone had seen the proposal and could commit to one way of working.
Review the whole product, not isolated blocks
We introduced recurring reviews where every designer examined the integrated build, not only their own block. A shared document kept issues visible across streams, and together we triaged release blockers and post-release work.
Designers then carried the agreed changes into their developer teams. Integration became a continuous part of the process instead of a problem discovered at the end.
Learnings
A specification can align execution, but it cannot settle priorities the organization has not agreed on. The screen became coherent only after the design rules and product priorities were aligned.
Next time, I would establish whole-screen ownership and cross-stream reviews before the first release candidate. Integration should be part of the operating model, not a fix added after the product fragments.