the Feed
Project overview
A vertical feed that pulls live events, highlights and news from multiple matches 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 social feature.
The context
LiveScore users were stuck inside single match views. Following more than one game meant navigating back and forth, adding friction to the thing fans came to do. The business wanted longer sessions and a sense of community, without 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. I ran most of the moderated interviews myself, and the PM ran a few to validate the reaction and timeline concepts.
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. With no precedent for social interaction, there were 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 metrics
40
Seconds. 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.
75%
Of reactions landed on content from blended default competitions rather than a user’s own favourites, confirming in behaviour what testing had predicted.
Problems identified
The empty feed
A feed built only from a user’s favourites left casual fans looking at nothing.
Cognitive overload
A raw stream of every live score was chaotic and unreadable.
No way to respond
Users had no mechanism to react to anything, which capped emotional investment and left the product unable to do anything with fan passion.
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 to take part without having to argue.
Context matters more than following
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.
Highlights are for downtime
Users were happy to watch highlights between matches, but while a match was live they wanted data speed over video.
Decisions & trade-offs
The defining call was reactions instead of comments. Comments were the obvious answer, but the interviews pointed to belonging over 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 side effect.
Experimentation
Reaction taxonomy
A/B tested emoji sets to find a vocabulary that captured genuine sports feeling, including frustration, without giving hostility somewhere to live.
Content density
A/B tested every event against key events only. Key events won decisively, which showed curation mattered more than completeness.
Default competitions
Tested blending logic and geo-adjusted defaults against an empty starting state, to find how much unfollowed content the feed could carry before it stopped feeling personal.
The solution
A modular Bento feed
Reused the SEVolution widgets as scrollable feed cards, so the feed launched quickly with rich data.
A chronological discovery engine
A unified timeline built from a user’s favourite teams and competitions, blended with geo-adjusted default competitions so the feed is never empty for a casual fan.
First-party reactions
Fans can register sentiment on a moment instantly. Built as a modular system, the reaction set was adopted so quickly that it was rolled out onto the Single Event View for lineup confirmations and final scores.
Off-peak content mixing
The feed is content-agnostic, moving from live events and instant replays during matches to longer highlights and editorial during quiet periods.
The favouriting loop
Density scales with the teams and competitions a user chooses to follow.
A commercial path, ready for version two
In-stream contextual odds were designed to sit natively in the vertical scroll.
Lessons learnt
Small interactions move large numbers
Three emoji changed behaviour more than a full social layer would have. A low-friction way to take part was enough to build an engaged community.
Familiar components need no explaining
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 and we held 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.
