Music Player - Interactive Component

What started as a full streaming platform concept — designed to strip away the "social feed" noise of apps like Spotify — became a focused, working music player component once a hard real-world constraint (no free public music API) forced a pragmatic pivot. The idea started from a frustration: most music streaming apps today have drifted into social-network territory — feeds, activity, algorithmic noise — when what I actually wanted was a clean, focused listening experience. I set out to design a full streaming platform concept around that idea: a homepage, an authentication flow, pricing tier cards, and the overall UI, all built around calm, distraction-free listening rather than engagement loops. Role: UI/UX Designer & Front-End Developer Stack: React, Figma (design), Framer Motion, Vercel Live: music-player-component-three.vercel.app

The original design problem: how do you build a music streaming experience that feels calm and focused, when the entire industry has moved toward engagement-maximizing social features? From that question, several design constraints emerged: - Visual calm over feature density — the UI needed to feel like a sanctuary, not a dashboard. Every element had to justify its presence. - Interaction quality over quantity — fewer features, but each one polished to feel premium. - The streaming problem — getting access to a genuinely free, public API for streaming full tracks turned out to be effectively impossible. Most music APIs are locked behind label licensing, paid tiers, or heavily restricted previews. This constraint forced a scope pivot: from full platform to focused component.

I defined three UX priorities: Calm, distraction-free listening — the core experience was about removing noise. No feeds, no social features, no algorithmic recommendations. Just the music, the controls, and the artwork. Premium micro-interactions — every state change (play, pause, seek, track switch) needed to feel smooth and intentional. Framer Motion handled the transitions: progress animations, play/pause state changes, and subtle depth effects that reinforce the premium feeling. Focused scope — rather than shipping a shallow multi-page concept, I narrowed to the most interaction-heavy piece: the player component itself. If the core listening experience didn't feel right, the full platform concept wouldn't matter.

Design in Figma I designed the full streaming platform concept in Figma: homepage, auth flow, pricing cards, and the player interface. The visual system was built around calm colors, clean typography, and generous spacing — every decision reinforcing the "distraction-free" principle. Player Component in React I built the music player as a standalone React component, the most interaction-heavy piece of the whole concept. I paid close attention to state management: play/pause, progress tracking, volume, and track switching all needed to feel instant and responsive. Framer Motion for Micro-Interactions I used Framer Motion to make every interaction feel smooth — play/pause state transitions, progress bar animations, and hover effects. The goal wasn't flashy animation, but perceived quality: the feeling that the interface responds to you, not just processes your input. Real Tracks via SoundCloud Since no free public API was available, I integrated two of my own tracks (released under the name KAM on SoundCloud) directly into the player. It let me ship something real and fully functional instead of leaving the project stuck on an external blocker.

The project evolved through two distinct phases: Phase 1 — Design exploration: Figma work on the full platform concept. Homepage, auth flow, pricing cards, player UI. This phase defined the visual language and interaction principles. Phase 2 — Focused implementation: once the API constraint became clear, I narrowed scope to the player component. The loop was: prototype the interaction in code, refine the motion in Framer Motion, test on multiple devices, adjust timing and easing, deploy to Vercel, iterate. The pivot from full platform to component was the key workflow decision — it turned a blocked project into a shippable one.

Pivot from platform to component: rather than abandoning the project when the API constraint appeared, I adapted the scope. Shipping a smaller, real, working piece was worth more than sitting on a bigger unfinished vision. Own tracks as placeholder content: using my own music (KAM on SoundCloud) solved the API problem pragmatically. It let me test the player with real audio data while keeping the project deployable. Framer Motion over GSAP: for this component, Framer Motion's React-native API was a better fit than GSAP. The interactions were component-scoped, not page-scoped, and Framer Motion's declarative approach matched the React architecture. Desktop-first: the player was designed and built desktop-first, then adapted for smaller viewports. The visual density of a music player benefits from horizontal space, and mobile adaptations were scoped down to essential controls.

Challenge: External constraints killing the original vision The API licensing problem wasn't solvable by better code — it was a legal and business constraint. I learned that not every blocker is technical, and the right response is often adapting scope, not doubling down. Challenge: Shipping a partial vision as a complete piece Going from "full streaming platform" to "one player component" felt like failure at first. But the component, fully polished, communicated the design intent better than a half-finished multi-page concept ever could. Shipping a focused, real, working piece is worth more than protecting a bigger vision that can't ship. Challenge: Micro-interaction quality at the component level GSAP taught me page-level motion. Framer Motion taught me component-level motion — smaller, tighter, more dependent on React state. The transition between the two scales was a learning curve, but it expanded my motion design vocabulary. Result: A live, deployed, working music player component with polished UI, smooth Framer Motion micro-interactions, and real playable tracks — publicly available on GitHub and deployed on Vercel.

The player is live and playable at music-player-component-three.vercel.app. The full platform concept (homepage, auth, pricing) exists in Figma but hasn't been implemented. If I were to evolve this project, I would: - Integrate a proper music API (Spotify, Apple Music, or a self-hosted solution) to support a real catalog. - Build out the homepage and auth flow from the Figma concept into a full React implementation. - Add playlist management and queue functionality to make the player feel like a real product, not just a demo. - Explore audio visualizations tied to playback state for an extra layer of interactivity.

For recruiters and hiring managers, this project shows I can navigate real-world constraints without abandoning a vision — I adapted scope, shipped what I could, and made it polished enough to demonstrate the design intent. It shows Figma design skills, React implementation, Framer Motion for micro-interactions, and the pragmatism to ship something real when the original plan falls apart. For developers and tech leads, it demonstrates component-level React architecture, state management for media playback, and motion design at the interaction level. The SoundCloud integration is a pragmatic hack, not a permanent solution — but it shows I prioritize shipping over perfection when the constraint is outside my control.