Practice Bud-E

The project started with a question that didn't have an obvious answer: why do so many young people quit their instruments right at the age when their interest in music is actually growing? Research consistently shows that participation in lessons drops sharply at the start of the teen years, yet the same cohort is consuming more music than ever. Something in the learning model was failing them.

I focused the problem around five assumptions I wanted to either validate or disprove: that students hit roadblocks and quit, that self-taught learning is overwhelming, that fear of judgment suppresses creativity, that students who are forced into lessons have lower motivation, and that financial barriers play a meaningful role. These became the foundation for all the research that followed.

I planned six stages of research over six weeks: a literature review, competitive analysis, online survey, user interviews, affinity mapping, and synthesis. The goal was to understand the problem from multiple angles before touching any design work.

The interviews were the most revealing part. Across every user group a few clear themes emerged: students wanted music theory explained through songs they actually cared about, not in the abstract. They felt the gap between "learning an instrument" and "making music" was too wide, and that jump was never bridged. Community and collaboration mattered more than any app feature. And the fear of sounding bad in front of others was a genuine blocker, particularly for self-expression and creation.

Several original assumptions were validated, and a few new discoveries surfaced that I hadn't anticipated, most importantly that self-taught learning, done well, is empowering rather than overwhelming, and that students have a strong natural musicality that traditional lessons tend to suppress rather than develop.

Rather than building a prototype from scratch for the first round of user testing, I found a smarter path. During competitive analysis I came across Hookpad, a web app whose core goals closely mirrored my research findings. Instead of spending time building a wizard-of-oz prototype, I used Hookpad as a testing vehicle to observe how real users approached music creation tools and where they got stuck.

I recruited six participants split across three user groups: absolute beginners, adventurous learners with some instrument experience, and intermediate players. The testing goals were simple but deliberate: could users actualize a musical idea, did they leave the session feeling proud of what they made, and did they learn at least one new thing.

The sessions were illuminating. One user started beatboxing drum patterns. Another sang the notes they wanted to place before adding them. There was clearly a natural musicality in the room that the software had no way to capture. More critically, the screen itself kept getting in the way, a constant source of distraction and context-switching that pulled users out of the creative flow.

Coming out of user testing I distilled everything into a set of product goals that would act as a design brief for everything that followed. The most consequential one was also the most challenging: the product had to be accessible away from the phone and computer.

That single constraint ruled out every software-only solution I had been considering. If the screen was the problem, putting the product on another screen wasn't a fix. I ran a brainstorming session to explore what form the product could take instead, and gradually landed on something more interesting: a dedicated physical device. Not a tablet, not a phone. A companion object that could sit on a shelf or desk during practice, provide audio feedback and guidance, and stay out of the way when it wasn't needed.

The brief I set for the physical device was specific: it needed to feel friendly and characterful enough to appeal to a teen audience, but grounded enough that it didn't look like a toy. I wanted it to feel like something you'd actually want on your desk, closer to a Google Home or Amazon Alexa than a piece of classroom equipment.

I started with a mood board pulling from retro technology, character design, and consumer hardware. Early sketches went through a round of peer feedback, which pushed me to simplify the form and soften the face. From there I moved into 3D modelling in Blender, working through multiple iterations before arriving at the final design.

The final device included large front-facing speakers, a microphone for picking up instruments and voice commands, a color-communicating light for non-screen feedback, tuning indicator lights, a tilted screen angled toward the user, and a tactile volume knob. Every component had a research-backed reason to be there.

Rather than designing a complex new interface for the device itself, I decided the right move was a mobile companion app. The device handles the in-room experience; the app handles setup, progress tracking, and reflection. This kept the learning curve low, since users are already familiar with phone interfaces, while keeping the device focused on what it does best.

The app was built around five core areas: a dashboard for quick device control, a warmup module to guide the start of any practice session, a lesson search that surfaces content based on the user's musical interests rather than a fixed curriculum, a profile page with gamified progress tracking and achievements, and a recordings library that captures practice sessions for later reflection.

Before moving into high fidelity I established a full brand identity for Bud-E, selecting a colour palette and typeface system that felt playful but credible, and designed a logo that could live on both the physical device and the app.

Practice Bud-E was a proof of concept, not a shipped product, but it proved something real. A research-led process, followed seriously, will take you places you didn't expect. I started this project thinking I was designing a software tool. I ended it having designed a physical product in Blender, a mobile companion app, and a brand identity, because the research made it clear that anything less wouldn't actually solve the problem.

The project taught me how to hold conviction and flexibility at the same time: conviction in the research, flexibility in the solution. The willingness to throw out the original concept entirely and start from a new constraint was the decision that made the work interesting. It's the project that showed me that the best design outcomes often come from the moments you're willing to abandon your first answer.

The full slide deck, including all research documentation, affinity mapping, prototype iterations, and final deliverables, is available to view below.