Design offline downloads people can actually rely on

Separate content you can play offline from content you can request

Minno divides a show into Downloaded episodes and Episodes not downloaded. A completed episode has a checkmark, while other rows offer a download action. Pimsleur uses a lesson list with an active progress indicator and pause control on Lesson 1, alongside download controls for the remaining lessons. Both designs make several availability states inspectable within the collection.

Use labels and icons that map to actual states. Not downloaded means no usable local asset exists. Queued means work has been accepted but has not started. Downloading means a transfer is active. Downloaded should mean the file has passed the checks required for playback, not merely that the final byte arrived. A corrupt file or an expired access token needs a different explanation.

Keep availability visible at the same level where people select content. If a row moves into a separate offline section, preserve its position or provide a predictable sort. A completed lesson should not appear to vanish after download. For a batch, communicate whether Download All includes the current course, only visible items, or future episodes as well.

Let the queue explain itself while work is unfinished

The Underbelly shows one video as Syncing 0% in the Downloads view. Breaker exposes Downloaded, Queued and Errors counts above its episode list. The contrast shows two levels of explanation: a row-level state for the specific item and a queue-level summary for the collection. A person should be able to find the work they started at either level.

A percentage is useful only when its denominator is meaningful. Do not turn processing, authentication or preparation into a fake transfer percentage. If a download is waiting for Wi-Fi, another task or enough storage, name that reason. A long-lived zero can otherwise look like a broken button even when the queue is doing exactly what the product intended.

Provide recovery where the state appears. A failed row can offer Retry and a concise reason; a paused row can offer Resume; a queued row can offer Cancel. Keep partially downloaded data only if the transport can resume safely. Repeated taps should attach to the existing job, not enqueue several copies of the same asset. Preserve each item identifier across list refreshes and app restarts.

Show the storage tradeoff before people need to clear it

Mindvalley displays both the total size and per-item sizes in its Downloads view. YouTube Music separates storage and download policy in a Downloads & storage settings screen, including Wi-Fi-only behavior and quality choices. These surfaces answer different questions: what is using space, and how future downloads should use it.

Choose storage units that help a person compare items, and round consistently. A short duration does not imply a small file, especially when video quality differs. If the user can choose audio-only or a lower quality, explain the effect on offline playback before transferring the asset. Do not hide the quality policy until after the library fills the device.

Represent download policy independently from asset status. Changing Wi-Fi-only should not erase completed files. Changing quality should explain whether it affects future downloads or also replaces existing copies. For automatic downloads, give people a bounded policy they can inspect: a content scope, a storage limit or an understandable retention rule. Avoid silently expanding the offline library after a simple favorite action.

Say what removing a download actually removes

Minno asks whether an episode should be removed from Downloads and states that it will no longer be available offline. The Underbelly uses Remove Offline Video? and explains that the video leaves the offline library. Both messages narrow the consequence to the local copy. They do not use a broad Delete label that could imply loss of the underlying content.

Write removal copy around the resource and its scope. Remove download is different from remove from favorites, remove from a playlist or delete a user-created recording. A menu containing several of these actions needs distinct verbs. If the user can download the content again while online, the interface can say so when that fact is true. Do not promise redownload if an access rule may prevent it.

Keep a single-item removal separate from a bulk storage reset. For bulk removal, show the affected count and the local-storage consequence. Preserve bookmarks, playback progress and favorites unless the action explicitly includes them. If cleanup runs in the background, acknowledge completion only after the relevant files and indexes are updated; a premature success message breaks the storage promise.

Keep feedback useful after the local copy disappears

YouTube Music shows Removed from downloads while leaving its library and mini-player visible. Activations places a Clear all offline data command below its downloaded-content list, with instructional text describing a swipe removal affordance. These are different moments: completed single-item feedback and an available collection-level command.

After a successful removal, update the affected row and storage total together. If the same content remains in a general library, show a download affordance there again instead of leaving a stale completed icon. Feedback should identify the action without implying that the person lost ownership, favorites or listening progress. Keep current playback coherent if a file is removed while playing.

Do not rely on a transient message as the only source of truth. The persistent list should explain the new state after the message disappears. A swipe can be an efficient shortcut, but also offer a discoverable menu action for users who do not know the gesture or cannot perform it. When cleanup fails, keep the previous state and explain which local copies remain.

Build the manager around assets, jobs and access

Store a content identifier, asset version, local path, transfer state, byte count and last validation time for each download. Track access eligibility separately. A person may have a complete file but no current right to play it, or the right to play it but no local file. Those states need different actions and cannot safely share one downloaded boolean.

Use stable job identifiers and deduplicate transfer requests. When the app restarts, reconcile the database with the local files before showing a completed badge. A missing file should not remain playable in the interface. A recovered partial file should not become a second download. Plan for process termination, network changes, expired authorization and a content update during transfer.

Make offline entry points work without fetching the online catalog first. Store enough title, artwork and duration metadata to browse local content. If artwork fails, keep the item identifiable by text. Handle a low-storage interruption before the final write, and give the user a recoverable choice rather than wiping unrelated content automatically.

Test the promise in airplane mode

Start with a simple acceptance test: download an item, close the app, enable airplane mode, reopen the offline library and play it. Repeat with an interrupted transfer and with a file removed outside the app. The difference between a saved-looking interface and a usable local asset becomes obvious under these conditions.

Measure successful offline starts, stalled jobs, retry outcomes, unexpected redownloads and storage-cleanup failures. Segment by content type, quality choice and network policy. Do not count a tap on Download as an offline success. Likewise, a large number of downloaded files does not prove that people value the feature if they cannot find or use them.

Test long titles, mixed video and audio libraries, large text and an active player during removal. Review whether each failed state gives a next step without demanding a connection for a task that should work offline. The interface earns trust when its availability labels survive real interruptions.

Check the offline promise before release

Use these checks on a working build, not only on the polished reference state.

• ✓Can queued, active, paused, failed and playable items be distinguished without color alone?
• ✓Does Download All state a predictable content scope?
• ✓Can people inspect storage usage and network policy before a transfer?
• ✓Does removal preserve favorites and progress unless explicitly requested otherwise?
• ✓Are repeated requests and app restarts safe for the queue?
• ✓Does the offline library open and play content with no connection?
• ✓Are missing, expired or corrupt local files recoverable instead of falsely marked ready?

Connect downloads to loading and recovery

Compare the mobile loading-state examples when distinguishing preparation, transfer and conversion rather than presenting one generic spinner.

Use the mobile error-state review for retry copy and preserved context. Download failure is usually a recoverable product state, not a dead end.

For complete recorded journeys, browse the downloading-content flow gallery and inspect what appears before and after the download list.