Case studyFreelanceStreaming Mobile · Web · TV10 months

Movie: one product, three screens

A free streaming platform for films, shows and live TV. An independent project — I led the design from the first research call to a shipped product that works the same on a phone, a browser and a television.

Product
Movie, a free streaming platform. Freelance / independent project
My role
Lead Product Designer.
Research, usability testing, interaction & visual design
Team
2 designers, 1 BA, 1 PM,
6 Flutter, 2 QA
Timeline
10 months.
Mobile, web and TV from one system
3M
users on the platform — a free product competing with paid streaming services
Platform scale
150K
daily visits, across mobile, web and television
Daily active
3
platforms designed from one system — phone, browser, TV remote
Cross-platform
01

The problem

Movie was a free product walking into a room owned by Netflix, Apple TV and a dozen others. Free gets you in the door. It does not keep anyone there. The question I had to answer wasn't "how do we look like the big platforms" — it was "why would someone pick us, and then stay."

And it had to hold together across three very different screens. A film you start on your phone on the bus, keep watching in a browser at home, and finish on the TV that night — same account, same place you left off. On paper that's one product. In practice it's three interaction models, and the TV one is nothing like the other two.

So the work split into two hard problems: stand out from platforms with far bigger budgets, and make one product feel native on a touchscreen, a mouse, and a remote — without designing it three separate times.

02

Where we chose to compete

Research came first: competitor teardowns, concept work, and cutting the feature list down to an MVP. Out of that came four places where a small free product could actually beat the giants — not on catalogue size, but on experience.

Adaptive interface, every device
Not "responsive" as an afterthought. One flexible design meant to feel right from a phone to a desktop to a living-room TV, for an audience that isn't tech-fluent.
Search and navigation that actually find things
A sharper filtering and categorisation system, so a person lands on the film they want in a few taps instead of scrolling a wall of posters.
Personalisation
Interface and recommendations that shift with what you watch — the thing paid platforms do well and most free ones don't do at all.
Free, and honest about it
Full access to a large library at no cost. The one advantage the paid incumbents structurally can't copy.

These four weren't a wish list. They were the filter for every later decision: if a feature didn't serve one of them, it didn't make the MVP.

03

The calls I made, and what they cost

Two decisions shaped the whole product.

Decision 01
One design system for three platforms — or three tailored designs?

Mobile, web and TV each have their own rules. The safe path is to design each one on its own terms. But three separate designs drift apart fast, and with six Flutter developers we couldn't afford to maintain three visual languages.

✓ What I chose
One system, platform-aware at the edges
A single design system built from scratch, with shared components, then a distinct control layer where each platform needed it. The TV version got its own navigation model for the remote; mobile and web shared more. Same product, same account, same place you left off — three ways to reach it.
✕ What I rejected
Three designs, each perfect on its own
Cleaner per screen, but they'd drift within months, and every new feature would cost three times the design and QA. A small team can't hold that line.
What it cost
The TV experience had to bend to the shared system in places where a bespoke TV design would have been slicker. I accepted a slightly less tailored remote experience in exchange for a product three developers could actually ship and keep consistent.
How I checked
Concept and structure tested before build: app map, then low-fidelity wireframes across all three platforms, so the shared spine was proven before any high-fidelity design.
App map
Why this way
The app map came before any screens. Getting the structure right once, up front, is what made a single system across three platforms possible instead of a nice idea.
Decision 02
How do you navigate a rich catalogue with five buttons?

Phone and web have a cursor or a finger — precise, direct. A TV has a remote: up, down, left, right, select. The same grid of films that works with a thumb becomes a maze when every move is one directional click.

✓ What I chose
A separate control structure for the remote
The TV version kept the visual language but got its own navigation built for directional control — focus states, predictable movement, fewer things to land on per screen. It aligns with the web version in function, but the way you move through it is designed for a remote, not adapted from a mouse.
✕ What I rejected
Porting the web layout to the TV
Cheaper and faster, but a mouse layout driven by a remote is the classic bad smart-TV experience. It would have undercut the whole "works everywhere" promise on the biggest screen.
What it cost
Extra design and a separate set of states to maintain for TV. Worth it: the living-room screen is where a streaming product either feels premium or feels broken.
How I checked
Usability testing through the process, feeding fixes back into the structure before the design was locked.
Mobile wireframes
TV structure
04

The work

Mobile

The mobile app carried the full MVP: watching, commenting, rating, building collections, and a user menu branching into the rest. It's the screen most people meet Movie on first, so it set the tone for the other two.

Mobile design
Mobile screens

Web

The web version mirrors mobile's functionality and stays in sync with the same account and recommendations. The main screen pulls together collections, suggestions, film cards and viewing history in one place.

Web design

TV

The TV version carries the same functions within the limits of remote control. Everything you can do elsewhere is here — reached through a navigation model built for five buttons instead of a cursor.

TV design

Design system

Built from scratch — a set of versatile components for Movie, and general enough for other products at the company. Every component is drawn in all its states: default, hover, disabled, focus, pressed, loading. Consistency comes from standardised labels, icons and containers, not from luck.

UI kit — mobile
UI kit — TV
Why this counts
A system that holds default through loading across mobile, web and TV is what let a small team ship three platforms that feel like one product. The states are where that promise is kept or broken.
05

Results

What I can state plainly: Movie runs on mobile, web and TV from one design system, and it reached 3 million users and 150,000 daily visits as a free product against paid incumbents.

What I won't dress up: I don't have clean before/after product metrics to hand for this write-up. So instead of inventing a chart, here's the evidence I do have — the platform's scale, and unprompted reviews from the stores.

3M
users on a free platform competing with paid services
150K
daily visits across three platforms
3
platforms shipped from one system by one small team

What users actually wrote

After the MVP shipped we set up feedback collection and read the store reviews. A few, unedited:

The best application. Free, and a lot of different films. New items are always fast and in good quality.

Clinton P.

Excellent application — thanks for the chance to watch all the foreign films and series.

Paul S.

It's so good that you exist. Now I can watch the films I want again.

Christopher S.

The most useful review was the critical one: a user praised the catalogue and quality, then flagged the ads as the single downside. That's the kind of signal that actually shapes the next release.

Honest note on the numbers

3M users and 150K daily visits are platform totals, not a change I'm attributing to a single design decision. A free catalogue draws people on its own. What design is responsible for is whether they can find something and finish watching it across three devices — and that's the part I'd measure properly if I ran this again.

06

What I'd do differently

I'd instrument it from day one
We shipped, users came, reviews were good — but I can't tell you what the search changes did to completion rate, or how many people actually moved between devices mid-film, because we didn't set those measurements up front. The scale is real; the proof of which design decisions drove it isn't. Now I define the metric before the first screen.
The TV version deserved more of my time
Bending the TV experience to the shared system was the right call for a small team, but it's the screen I'd most want to revisit. A remote-first product on the living-room screen is its own craft, and there was more to get there than ten months allowed.
Where AI would fit today
There was no AI in my process here — it wasn't part of how I worked then. Today it would take the slow parts: synthesising research, drafting the dozens of component states a three-platform system needs, first-pass interface copy. The platform-specific calls — how a remote should move through a catalogue — would still be mine to make.