I ran a Google Forms survey from Aug 4 to Aug 21, 2024. There were 23 participants, who mostly comprised ages 18 to 34 years, and were tech-savvy. 30% of these identified as neurodivergent.

I designed this survey with one constraint that being — the swipe mechanic was deliberately hidden. The questions revolved around the problems faced and desired features, not solutions. My goal was to validate the problem I was facing, not seek answers.

The survey results reframed everything. Before the survey, MediaMop appeared to be a storage utility tool. After it, I could see that my product was clearly an emotional support tool for a something people want to do but avoid because of the cognitive load. The top 3 pain points were all psychological — fear, time, and indecision. Storage surprisingly ranked fourth.

I created these on the fly by analyzing the survey response. Not just for fluff, but as tools to challenge each subsequent decision.

Decision fatigue was the critical insight generated by Noah’s persona and formed the basis of many subsequent decisions, such as the Skip button, progress persistence, and visual progress representation. Bianca’s commute scenario shaped the framework: sessions must be interruptible, startup must be instant, and the feedback must be immediate.

The swipe screen was painted in my mind even before I opened Figma: a row of thumbnails at the top, large preview in the middle covering most of the screen, and the row of action buttons at the bottom.

Colour semantics surprisingly took way longer. After three failed iterations, I settled into: Delete = error red, Keep = primary (brand colour), Undo/Skip = tertiary (neutral). Now that the semantics were clear, translating them into something consistent took another series of iterations.

Another challenge was video support. You can’t judge a video from a thumbnail. To make the video review feel more native, I incorporated several features like auto-play on open, tap-to-toggle controls, auto-hide after three seconds. These are the patterns we are already familiar from Instagram and TikTok. So no learning curve there.

Noah’s decision-fatigue birthed three features:

• Skip. Progress shouldn’t be blocked by indecision. If you’re not sure, move on.
• Progress persistence by item ID, not index. In an unlikely event of an app crash or even a manual break, you won’t come back if you find that you’ve lost all your decisions. The engineering expense is negligible; the psychological cost is irrevocable.
• The Menu screen as intermediary. Users do not jump from the Home page to the Swipe screen. They choose a particular folder. This provides scope: “I’m cleaning this album,” not “I’m cleaning my whole gallery.” A boundary that actually reduces decision fatigue by compartmentalizing the problem.

Somewhere along the way during the design phase, I realized device folders don’t match how users think about their media. Nobody with 9,000 photos is thinking “I need to clean the Camera folder.” We are thinking “I need to clean up everything from last year.”

So I added views. Like filters but better. Group By Month / Year / Type. These would be virtual albums that don’t exist on the device. Now the users can slice their gallery by how they think, not how the device stores files.

As a developer, I knew it would be architecturally demanding; but as a designer, I was beginning to see the interactivity challenge. The survey’s 91% preference for automatic organization brought me here. I just hadn’t seen it yet.

I built the entire interaction flow against mock data before touching any device API. This was intentionally done to 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.

This will become a standard for my every future project.

Transition from mocks to gallery integration led to the most intensive day in the development process, when almost 5,500 LOC was added in one sitting. Android 13+ specific permissions for media access, async thumbnails loading, media file size unavailable in media API. None of this could be foreseen in mocks.

One thing was clear and non-negotiable: privacy-first. All media processing happens on-device. No cloud uploads, no external APIs.

Following the seven-month break (§07), I came back to test on my own collection of 9,000 photos. Opening the album list took 2–5 seconds. That clearly broke the “start cleaning right away” promise from my very first design brief.

The problem stemmed from the architecture: The app fetched all media assets for every album, doing synchronous disk I/O on the UI thread. The solution was a light-weight AlbumSummary model for the album list view, with the full item loaded only when a user entered an album. Later, a persistent JSON cache took the same principle further.

This was not about optimizing the server. It was about fixing the user experience. The problem was not “how can we speed up the process?” It was “which delay specifically makes the user lose trust, and how do we get rid of it?”

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 Favourites 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 Favourites. Two features eliminated by designing better alternatives.
• Storage breakdown in Stats was built, then removed. ~3 hours of continuous rework: 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. (However, I am re-reconsidering it now.)

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 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.