the Feed
Project overview
A vertical feed that pulls live events, highlights and news from every match into one chronological stream, so following several games no longer means navigating between them. It moved LiveScore from a check-and-go utility towards somewhere users stayed, and introduced the product’s first direct engagement feature.
The context
LiveScore users were stuck inside single match views. Following more than one game meant navigating back and forth, which added friction to exactly the thing fans came to do. The platform was also a one-way broadcast with no way for anyone to respond to anything. The business wanted deeper sessions and a sense of community, but not the moderation burden and hostility that open comments bring to sports products.
My role
I owned the design end to end: research, concept, high-fidelity prototyping, and QA of the built designs in the production codebase. The PM facilitated development and coordinated timelines. I was the only designer on the project, working under a lead product designer.
team and timeline
One designer, one PM and a development squad of five, with design and product each overseen by their respective leads. Three months from concept to launch, shipped at the start of 2026, with rollout and early monitoring overseen directly.
Constraints
Nothing like this existed anywhere in LiveScore. There was no precedent for user interaction of any kind, which meant no patterns to build on, no moderation capability, and no internal appetite for the risk that user-generated content usually carries. Anything I proposed had to deliver a genuine sense of participation while asking the business to take on close to zero moderation exposure.
Key Metics
40
Seconds, the average session uplift, from an A/B test comparing users with the feed against those without it across the month-long rollout.
60%
Of users engaging regularly with emoji reactions within the first month of launch, on a product that had never had an interaction feature.
75%
Of reactions landed on content from blended default competitions rather than a user’s own favourites, confirming in behaviour what testing had predicted.
The solution
Problems identified
Research insights
Community without toxicity
Fifteen moderated interviews showed users wanted to feel part of something but actively feared the negativity of sports forums. They wanted presence, not debate.
Clarity first, depth second
Fans care about games they have not chosen. In unmoderated testing with 50 users, 90% said a feed limited to their own favourites would give them less reason to come back. They wanted the title rival dropping points, without having to follow anyone.
Video is a filler, not a feature
Users were happy to watch highlights during downtime, but while a match was live they wanted data speed over video.
Experimentation
Decisions & trade-offs
The defining call was reactions instead of comments. Comments were the obvious answer and the one most requested internally, but interviews showed users wanted belonging rather than discussion, and a comment system on live football carries moderation cost and reputational risk the product had no capability to absorb. Three emoji delivered most of the value at a fraction of the exposure.
I chose a chronological base rather than an algorithmic one, so live relevance was never in question, then blended in contextual events to widen the picture beyond a user’s own teams. Defaults are geo-adjusted, so a UK user sees the Premier League while another market sees what is relevant there.
I also resisted adding filters. Filters would have solved density but added a control surface most users never touch. Instead the only way to make the feed richer is to favourite more teams, which turns information control into profile building and makes the product stickier as a consequence rather than as a feature.
Lessons learnt
Small interactions move large numbers
Three emoji changed behaviour more than a full social layer would have, on a product that had never asked users for anything. Engagement came from lowering friction, not from adding features.
Reuse buys comprehension, not just speed
Building the feed from SEVolution components meant it shipped in three months, but the larger gain was that users understood the interface immediately because they had already learned the patterns elsewhere. A design system pays back twice: once in build time, and again in the learning curve you never have to ask anyone to climb.
Validate the thing before wiring it to everything else
I designed the in-stream commercial integration but argued to hold it for a second version. Adding it would have increased build time and complexity before anyone knew whether people wanted a feed at all. Proving the core first meant the commercial work could be built on evidence rather than assumption, and it is the reason the feed shipped in a quarter rather than half a year.
