A Google Forms survey ran August 4–21, 2024. Twenty-three respondents — mostly 18–34, tech-literate, with 30% self-identifying as neurodivergent.

The survey was designed with one deliberate constraint: the swipe mechanic was hidden. Questions asked about challenges and desired features, never about solutions. The goal was to validate the problem — not confirm the answer.

This reframed everything. Before the survey, MediaMop was a storage utility. After it, the product was clearly an emotional support tool for a task people avoid. The top three pain points are all psychological — fear, time, and indecision. Storage was tied for fourth.

Built directly from survey patterns — not as filler, but as cognitive tools used to pressure-test every later decision.

Noah’s decision fatigue became the single most load-bearing insight in the project. It explains why the Skip button exists, why progress persistence is non-negotiable, and why the app shows visible completion states. Bianca’s commute scenario shaped the architecture: sessions must be interruptible, startup must be fast, and the core swipe loop must be immediate.

The swipe screen was imagined whole before I opened Figma: thumbnails at the top, large preview in the middle, action buttons at the bottom.

What took longer was the colour semantics for the action buttons. After three failed passes, it settled into: Delete = error red, Keep = primary (brand colour), Undo/Skip = tertiary (neutral). The semantics were clear; translating them into something consistent took iteration.

Video support became a small UX test in itself. You can’t judge a video from a thumbnail — so I specified auto-play on open, tap-to-toggle controls, auto-hide after three seconds. Patterns already familiar from Instagram and TikTok. Nothing new to learn.

Three features came directly from Noah’s decision-fatigue insight:

• Skip. Indecision shouldn’t block progress. If you’re not sure, move on.
• Progress persistence by item ID, not index. If the app crashes after ten minutes and loses your decisions, you won’t come back. Engineering cost is trivial; trust cost of losing work is permanent.
• The Menu screen as intermediary. Users don’t go straight from Home to Swipe — they pick an album first. This forces scope: “I’m cleaning this album,” not “I’m cleaning my whole gallery.” A constraint that actually reduces decision fatigue by shrinking the problem.

Partway through development, a quiet realization: device folders don’t match how users think about their media. Nobody with 9,000 photos thinks “I need to clean the Camera folder.” They think “I need to clean up everything from last year.”

So I added Group By Month / Year / Type — virtual albums that don’t exist on the device. Users can slice their gallery by how they think, not how the OS stores files.

This was a product decision first, an architecture challenge second. The survey’s 91% preference for automatic organization had pointed here. I just hadn’t seen it yet.

The entire interaction flow was built against mock data before touching any device API. This was deliberate: validate the UX independent of platform complexity. When real-data problems emerged later, they were integration problems, not design problems. The interaction model was already proven.

I’d do this on every future project.

The switch from mocks to actual gallery integration produced the densest day in the project — 20+ commits in a single session. Android 13+ granular media permissions, async thumbnail loading, file sizes not directly available from the media SDK. None of this had been visible in the mock layer.

One non-negotiable carried through: privacy-first. All media processing happens on-device. No cloud uploads, no external APIs.

After a seven-month pause (see §07), I returned and immediately tested on my own 9,000-item gallery. Opening the album list took 2–5 seconds. That broke the “start cleaning right away” promise from the very first design brief.

Root cause was architectural — the app was loading every media item for every album upfront, including synchronous file I/O on the main thread. The fix was a lightweight AlbumSummary model for the list view, with full items loaded on demand when a user enters an album. Later, a persistent JSON cache took the same principle further.

This wasn’t a backend optimization. It was a UX fix. The question wasn’t “how do we make this faster” — it was “which specific delay breaks the user’s trust, and how do we eliminate that one?”

Cut after building

Features sometimes have to be built before you can tell whether they earn their place. Every removal below was a small lesson in restraint.

• Search and Favorites were in the original feature list. Neither got built — the Group By system replaced search for most use cases, and the Keep action during swipe replaced Favorites. Two features eliminated by designing better alternatives.
• Storage breakdown in Stats was built, then removed. Twelve commits in three hours: built → redesigned → enhanced → polished → removed the storage breakdown. It sounded valuable in planning; in practice it added visual noise without helping anyone make decisions.
• Backup and Restore was dropped entirely. A gallery cleaner that also does backups is a different product.
• Gamification (Duolingo-style badges) was considered early and never pursued. The progress tracking itself became the reward loop.

The visual identity didn’t arrive through planning. It arrived through iteration across multiple sessions — and, critically, through living with an imperfect version long enough to feel what was wrong.

I had to see each one in the real product to know it wasn’t right. Sketches and colour boards weren’t enough.

In an earlier phase, I explored three visual paradigms: glassmorphic (frosted glass), neumorphic (soft shadows), and premium flat (solid fills, subtle outlines).

Glassmorphism and neumorphism looked impressive in isolation. Across the full app, they muddied tap targets and broke visual hierarchy. The lesson was uncomfortable but useful: choosing aesthetics for portfolio appeal over user clarity is a trap.

The first Premium Flat pass put Mahogany Red in the primary slot — bold, fiery, distinctive. It felt right on day one. A week of living with it made something quieter clear: a dramatic red as the dominant surface colour made the app feel loud and warning-like, when cleaning should feel calm and considered. Red is the language of stop, and the whole app was asking users to go.

The fix wasn’t a new palette. It was a rebalance of the same three colours into different roles:

• Deep Navy → primary · calm, structural, the ocean the user sits inside
• Mahogany Red → secondary · hot, for emphasis and destructive actions
• Champagne Gold → tertiary · warm counterpoint, highlights and progress
• Emerald Green → success · completion states, the reward tone

I saved the mood board as ocean fire.png and started calling the palette Fiery Ocean — an ocean of navy lit by warm fire and gilded light. Same ingredients as Phase 4, different recipe. That’s what shipped.