Sometimes a design challenge does not begin with a client brief. It begins with a quiet, persistent frustration.

I have been playing the electric guitar for longer than I would comfortably admit in public. Long enough that I occasionally feel I should have reached some mythical level of virtuosity by now. Instead, I have spent years hovering on a skill plateau. And that is fine. Guitar is a hobby for me. My focus has always been songwriting rather than performance. I care more about ideas than speed.

Over the years, one recurring need kept surfacing. I wanted a simple, interactive fretboard map that would let me experiment with scales visually. But also I was not looking for a dense music theory app overloaded with features. I wanted something immediate and responsive. Something that would help me define a scale and explore chord possibilities intuitively.

Existing tools did not quite work for me. They were either too complex, too rigid, or too focused on memorisation rather than exploration. Much of Western music theory terminology developed through pedagogy, liturgical practice, and academic tradition, often reflecting historical lineage more than interval structure. For newcomers, these naming systems can obscure relationships that are otherwise straightforward.

Consider labels such as Hungarian Minor, the mystic scale, the Lydian Chromatic concept, or the Rimsky Korsakov associated octatonic scale. These names carry rich musical history, but they are only meaningful if you already understand what they describe. As both a guitar player and a designer, that gap felt like an opportunity. So I decided to design the tool I always wished existed.

Most music theory tools assume the problem is learning scales. That was no longer where I struggled. I was not trying to memorise the Ionian mode or recognise the Hungarian Minor by name. During songwriting, I wanted to experiment. I wanted to choose a set of intervals that sound interesting to me, place them on the fretboard, and immediately understand what harmonic space they created. I wanted a practical tool not a theoretical framework.

Existing tools forced me into predefined systems. They asked me to select a scale from a long list of historical names and theoretical categories. That approach assumes the user already knows what they are looking for. Creativity rarely works that way. Songwriting often begins with curiosity rather than certainty. What happens if I build a six note scale around minor thirds? What chords naturally emerge from it? Which shapes fall comfortably under the fingers?

The challenge therefore was to create an interactive fretboard experience that allows scales to be defined by intervals then immediately reveals their harmonic possibilities. I intentionally framed the challenge narrowly. This was not about building a full music learning platform. It was about answering one practical question at the moment ideas appear:

If I construct an unfamiliar scale using a specific interval pattern, what chords can I actually play on the guitar?

The user, in this case, was me. That might sound indulgent, but it allowed for honesty. I knew exactly where the friction lived. Designing for yourself can be risky if it becomes self centered. You can easily end up solving a problem that no one else has. But when approached as a real constraint rather than a personal preference, it can also produce clarity. The goal was removing friction from exploration.

In my roles as interaction or product designer, I have received both praise and criticism for my work that stayed with me. Both are useful. I tend to listen carefully, even when feedback makes me uncomfortable. Doubt can be productive. What anchors my process is not aesthetic preference but value. Does the design solve the problem? Does it reduce friction? Does it enable the intended behavior?

I am comfortable iterating. I do not mind yet another adjustment, rework or even a complete pivot if it improves the outcome. In this project, that mindset was essential. Because when you design something for yourself, you are constantly tempted to over-engineer it. I had to repeatedly ask; is this feature solving the core problem, or is it just another shiny thing?

Before touching any interface elements, I listed what I actually needed from the tool.

• The ability to define scale intervals. This was the most important feature, as I wanted to experiment with scales rather than be limited to the traditional church modes of the diatonic system. I decided to focus on a small set of interval distances: the minor third, and the minor and major second.

• Immediate visual feedback of scale tones. This became the primary feature of the tool and was tightly coupled with scale construction.

• The ability to define the number of steps in a scale. Theoretically, a scale can contain any number of tones between one and twelve within an octave. In Western music practice, however, scales containing five to eight notes tend to occupy the most musically usable range.

• The ability to switch between scale modes. Technically this is not strictly necessary, since scales are circular by nature, but it helps visualise scale maps across the fretboard and align them with chords that use open strings.

• A clear visual representation of the fretboard from the nut to the twelfth fret, as this captures a complete octave on each string. Since I play standard six string guitars, I decided not to support multiscale or extended range instruments. I aslo was not bothered about alternative tunings or capo. All great ideas for nice-to-have features, yet to me these were distractions I wanted to avoid.

• Fret markers to provide an intuitive reference for left hand positioning. Many guitar applications either omit fret markers entirely or rely on fret numbers. For me, traditional dot markers are the most intuitive visual reference.

I knew that I did not want to select predefined scales identified by archaic or confusing names such as the heptatonic melodic scale, or modes bearing the name of a long forgotten Greek tribe, such as Mixolydian. Synonymous labels like Gypsy Minor, Hungarian Minor, or Double Harmonic Minor felt equally limiting. They convey little practical meaning without prior theoretical knowledge. To me, Mixolydian and Ionian are simply interval patterns: 2, 2, 1, 2, 2, 1, 2 and 2, 2, 1, 2, 2, 2, 1 respectively.

• A way to identify potential chords within a scale. As an amateur guitarist, I tend to think of harmony in two categories: triads, and triads extended with additional tones.

• Minimal cognitive overhead. I wanted to avoid overly complex or academic chord naming conventions such as Cmaj9#11 jazz voicings, C7sus4 add tone structures, or altered dominants like C7b9#11. Frankly, I cared less about the theoretical label and more about whether the chord sounded good and functioned within the context of the scale.

That last point was crucial. Creativity suffers when the tool itself becomes the focus. The interface should feel like an extension of thought, not a puzzle to solve.

Finally, the interface needed a sense of playfulness. I wanted it to have a fun factor. Something slightly quirky.

From the beginning, I wanted the prototype to remain simple and fully under my control. The scope was narrow and exploratory, and introducing frameworks or dependencies too early felt like unnecessary engineering. The goal was not to optimise for scale or future extensibility, but to understand the interaction problem as directly as possible.

For that reason, I chose vanilla HTML, CSS, and JavaScript. Working without abstractions allowed me to iterate quickly and adjust behaviour as new usability issues emerged. Rather than predesigning UI components, I treated code as a sketching medium. Controls and visual elements evolved alongside the interaction model instead of being formalised upfront.

Rendering everything as standard HTML elements quickly became cumbersome due to layout complexity and the need for precise positioning. Canvas offered performance and flexibility, but it required a fully imperative redraw model that introduced complexity I did not need at this stage.

SVG provided the right balance. It allowed precise geometric positioning while keeping individual notes and markers accessible through the DOM. Elements could be styled with CSS and updated selectively through JavaScript instead of redrawing the entire surface.

One of the early ideas I explored was allowing users to define scales purely as numerical intervals. On paper, this felt logical. Scales are, after all, patterns of distances between notes, so representing them as numbers seemed both accurate and flexible. In practice, however, the experience quickly became frustrating.

Because scales are circular systems constrained within twelve tones, every change introduced unintended consequences elsewhere. Adding a tone to one step required compensating somewhere else to avoid exceeding the octave. A step that previously contained one tone might suddenly require two, forcing the user to remember to subtract a tone elsewhere. What initially appeared simple turned into a constant exercise in mental bookkeeping.

During testing, I found myself repeatedly stopping to calculate rather than experiment. Instead of exploring chords, I was managing constraints. Each adjustment required at least one additional correction, and sometimes several. The interface was technically correct, but it demanded that the user perform mental arithmetic before seeing the result.

I briefly explored an alternative approach that treated intervals like modular blocks filling a twelve tone canvas, almost like assembling Lego pieces. The idea was visually appealing, and drag and drop interaction initially felt promising. However, it introduced the same underlying issue. The user still had to think ahead, calculate totals, and resolve invalid combinations. The interface would also need constant validation warnings to prevent impossible configurations.

I realised that the tool should carry the responsibility for maintaining musical constraints, not the user. One possible solution was to cap the available options by removing blocks that would spill over the octave. However, this did not help the user understand how many steps they were actually creating. Each step represents a potential new chord. The breakthrough came when I introduced explicit control over the number of steps in the scale. Instead of manually compensating for every adjustment, the system recalculated the remaining intervals automatically, always preserving the octave.

Suddenly, experimentation became fluid. I could explore ideas without interruption, adjusting intervals freely while the fretboard updated in real time. Instead of managing rules, I could simply experiment.

Testing this interaction also exposed something humbling. Many of my frustrations came from a mismatch between expectation and outcome. I would imagine a particular interval pattern, only to realise that it required a different number of steps than I had assumed. The difficulty was not theoretical knowledge but the limits of mentally visualising a complete fretboard map.

Once the system handled those constraints automatically, the tool began delivering the value I was looking for. It removed friction from exploration rather than adding another layer of theory to manage.

The scale intervals presented as three size blocks with the step count above.

All this discussion of intervals and scales raises an obvious question: where are the chords? They were the goal of the tool from the beginning.

In most tonal harmony, chords are built from triads, constructed from the first, third, and fifth scale degrees. These can then be extended with additional tones drawn from the same scale, creating richer harmonic colour. There is considerably more nuance to chord construction, but this article is not meant to teach music theory. What mattered for the design process was identifying the smallest meaningful unit of harmony. The triad became that unit.

Rather than presenting dense chord libraries or complex jazz naming conventions, I chose to show only the core triads derived from the selected scale. Potential extensions remain visible as transparent notes, allowing experimentation without overwhelming the interface. The intention was to prioritise exploration over classification.

Voicing introduced another layer of complexity. The same chord can appear in multiple positions across the fretboard, each with a different melodic character and physical feel under the fingers. To maintain musical readability, I chose to prioritise chords in root position. The core scale degrees are colour coded so that the harmonic structure remains immediately recognisable. Extensions are displayed as transparent notes, allowing experimentation with alternative fingerings while enabling colour and variation to emerge naturally through interaction.

Looking back at the prototype, the core interaction delivers the value I originally set out to create. It encourages experimentation rather than instruction, allowing scales, intervals, and chords to emerge naturally through exploration on the fretboard. At the same time, several clear directions for further development have emerged.

The interface would benefit from visual refinement. The current colour palette, alignment, and layout carry a deliberately playful and improvised character that supported rapid experimentation during development, but at times this reads as visual noise. A more intentional colour system, clearer spacing, and stronger alignment would preserve the tool’s personality while improving clarity and focus.

Supporting responsive layouts is another natural step. Enabling comfortable use on mobile devices would allow the tool to move beyond the desktop and better match how many musicians experiment with ideas away from their main setup.

Functionally, support for alternative tunings feels like the most meaningful extension. Treating tuning as another creative variable would open new harmonic possibilities and allow chord shapes to be explored in entirely different contexts.

The prototype also revealed technical work still to be done. Much of the code evolved alongside the interaction design, enabling rapid iteration but now calling for refactoring. Separating calculation logic from rendering and simplifying state management would improve maintainability and make future experimentation easier.

These next steps follow the same principle that shaped the project from the beginning: remove friction, keep complexity where it belongs, and allow the instrument, rather than the interface, to lead the experience.