Back to Case Studies// Personal Project · Mobile UX

YouTube — Redesigning the Download Feature.

I commute an hour each way and rely on YouTube's offline downloads to get through it. Videos vanishing on their own and deleting them one at a time kept bothering me enough that I turned it into a full case study — interviews, a redesigned deletion flow, a faster way to reorder.

RoleUX/UI Designer
TypeIndependent Case Study
PlatformYouTube — Download Feature
Timeline2023
// Context

This wasn't a client brief — it's an independent case study I ran on a feature I use almost daily. I interviewed and surveyed other commuters who download YouTube videos for offline viewing, then designed and prototyped a fix in Figma. The original write-up is on Medium →

// The Problem

What kept happening

Downloaded videos couldn't be saved to local device storage, and disappeared on their own if left unwatched too long. On a route with patchy signal, losing a video I'd deliberately downloaded defeated the point of downloading it.

What made it worse

Deleting was one video at a time, no batch option. Resolution couldn't be changed after downloading. Reordering a queue of a few videos took 10 taps across 11 screens — more effort than just rewatching whatever was already first in line.

// Process
01

Checking it wasn't just me

Before designing anything, I ran interviews and a survey with other people who download YouTube videos for offline viewing. The same five complaints came up independently — this wasn't one commuter's pet peeve.

02

Mapping the real cost in steps

Traced the existing flows screen by screen instead of going on feel: deleting a video took 3 taps across 4 screens, reordering took 10 taps across 11. That gap between what it should take and what it actually took became the design target.

03

Designing around Haikal

Built the redesign around Haikal, a 27-year-old commuter persona pulled from the interviews — an hour each way, tutorial and gaming content, wants videos ready to go without fighting the app to manage them.

// The Solution

Two ways to delete, depending on the situation: swipe a single video away in place, or switch to multi-select to clear several at once instead of repeating the same flow one video at a time. Reordering became drag-and-drop directly in the list, instead of routing through a separate screen for every move.

Delete a video

Before
3 taps · 4 screens
After
2 taps · 1 screen (swipe)

Reorder the queue

Before
10 taps · 11 screens
After
4 taps · 3 screens

Step counts mapped directly from the existing flow vs. the redesigned one — not estimates.

I also considered two options I didn't ship. An auto-save toggle that would let a video skip the expiry countdown entirely — closer to a real fix for the “videos vanishing” complaint — but it meant reworking how the app manages local storage limits, further than I could responsibly scope without access to YouTube's actual storage architecture. And a dedicated “manage downloads” screen, separate from the main library — cleaner in isolation, but it added a screen to remember instead of removing friction from the one people already use. Swipe-to-delete and drag-to-reorder won because they fixed the two most-cited complaints without asking Haikal to learn a new part of the app.

// Outcome

This was a proposal, not a shipped feature — YouTube doesn't take outside redesigns, and I don't have adoption numbers to report. What it did do: turn a recurring commute annoyance into a fully scoped problem with real numbers behind it, and confirm through other commuters that the friction wasn't just in my head.

// Reflection

Not every case study starts with a client brief. This one started with being annoyed on the same train ride for months. Treating my own friction as a real research question — checking it against other people instead of assuming they felt it too — is what turned a complaint into something worth showing. The honest limit: I validated the problem with other commuters, but the solution itself was only ever tested against my own workflow and a prototype — no usability testing loop, because there was no team or budget behind it. I'd treat that gap the same way on a real job: ship the fix, then go find out if it actually holds up once people who aren't me are using it.

More case studies.

See the rest of the portfolio — design systems, dashboards, and everything in between.

Back to Case Studies →