My Virgin Media

Connecting customers to the world of Virgin Media

Role: Mid-weight UX/UI Designer & Motion Designer

Client: Virgin Media (My Virgin Media account app, for iOS & Android) https://www.virginmedia.com/broadband

Team: Embedded in a sizeable cross-functional UX/UI team, working alongside product managers, engineers, brand, and marketing

My remit: Native app components for Internet, Mobile Data and TV services · In-app Lottie micro-animations · After Effects promo video for the app stores · Apple App Store and Google Play store assets · supporting print and inter-app promotion artwork.

Thread 1 — Designing three product lines under one roof (UX/UI)

Situation. My Virgin Media is the customer's everyday account hub. It has to handle three distinct mental models -a broadband customer checking hub speeds, a mobile customer tracking data, and a TV customer paying a bill or finding a box-set- and still feel like one product. The design team was sizeable, the brand guidelines were live and evolving, and timelines were tight.

Task. As a mid-weight designer in the team, I owned discrete components across all three product lines: account details, plan summaries, hub and HUB4 troubleshooting tiles, the home bar, more-menu and settings, and the notifications surface.

Action. I worked tightly to the Virgin Media brand and design rules so engineering could ship consistently across Android and iOS. Where the guidelines didn't yet cover an edge case: a coloured icon set inside a tile model that broke contrast at certain sizes, for instance, I proposed back-compatible patterns and walked them through with brand and accessibility leads before specifying them. I am genuinely passionate about accessible and inclusive design, so I kept WCAG colour-contrast, target-size and screen-reader behaviour on the table from the first draft, not as a last-mile audit.

I also got my fair share of difficult stakeholder moments. On one tile-model decision, marketing wanted maximum visual lift and engineering wanted the simplest reusable spec. I chaired a short working session, mapped both positions to the underlying business goal, reducing failed call-centre escalations, and landed on a tile that kept the marketing impact while staying inside the component library. The point was never to "win": the point was to put the business goal first and unblock the build.

Result. The components I owned shipped into the live app on both stores. Internally, the patterns I documented were re-used across subsequent tile, carousel ("Oomph") and promotion work, a small but real signal that the system I helped tend was holding together.

Thread 2 — A promo video and a library of Lottie micro-animations (Motion)

Situation. The team wanted the app store listings to show the product, not just describe it. There was no existing motion language for the app, no agreed promo video, and the in-app surface felt static — particularly the notification bell, where users were missing alerts.

Task. Take initiative on the motion side: design a 30-second promo video for the App Store and Google Play, and a library of in-app micro-animations that would feel native, run cheaply on lower-end devices, and reinforce the brand.

Action. I worked end-to-end and was largely self-sufficient on this strand: storyboard, asset prep, animation, sound design, export and hand-off. I built the promo video in After Effects against the brand's flares, type and colour palette, sourced licensed audio and ran several music passes with stakeholders to land on a track that fit the tone (I documented the audio shortlist so future videos wouldn't restart from zero). For the in-app micro-animations — including six iterations of the notification bell — I animated in After Effects and exported through Bodymovin to Lottie JSON, which gave engineering a tiny, vector, resolution-independent file instead of a heavy MP4. I tested motion at reduced-motion settings so the animations respected accessibility preferences.

Result. The promo video was used on both store listings. The Lottie library (bell, badge, spinner, success and finish states ) became the reference set the team pointed to for new motion work. Because Lottie ships as JSON, file sizes were a fraction of the equivalent video, and behaviour like "play once on first notification" was straightforward for engineering to hook up.

Thread 3 — App store and cross-channel assets

Situation. A great app still has to win the store-page click and the in-account banner.

Task. Produce store thumbnails for Apple and Google, plus inter-app promotion tiles, an eBilling print flyer, and supporting marketing artwork — all on-brand and store-compliant.

Action. I designed each asset against the platform's own guidelines (Apple's "show real UI" rules differ meaningfully from Google's), kept a single source of truth for the screen exports so versions didn't drift, and prepared print-ready CMYK files for the eBilling flyer at the sizes the print partner needed.

Result. A consistent visual language across store listings, in-app cross-promotions and supporting print collateral — with reusable templates the team could pick up after I'd handed over.

Conclusion — What I took from the project

A few habits this project sharpened:

The brand and design rules were still being written while we worked, so anything I documented (tile contrast fixes, icon behaviour, motion specs) was likely to get re-used. The patterns from the components I owned ended up showing up across later tile, Oomph carousel, inter-app promotion and help-squad work, which made the next round of design quicker for everyone. Designing for re-use turned out to matter more than designing for delivery.

The notification bell took six iterations, not for perfectionism but to get to something that performed cleanly on lower-end devices, respected reduced-motion, and still read well on the hundredth open. Choosing Lottie over MP4 was a file-size and battery decision as much as a visual one. The promo video reinforced the same point on the audio side: a documented track shortlist saved more time at review than any visual revision did.

Apple's store rules, Google's conventions, and the print partner's CMYK sizes are three different conversations, not a generic middle. Treating each on its own terms, and keeping a single source of truth for the screen exports across the app, store, inter-app and print surfaces, is what stopped Friday hand-offs becoming Monday re-exports.

Across all three threads, the through-line was the same: do the careful work up front, leave the project tidier than you found it, and don't make the next person redo what you've already figured out.