Keyflow
Designing an app to reduce the friction of transposing sheet music for musicians
Team
Solo
Timeline
5 weeks (non-continuous)
Role
UX Researcher
UX/UI Designer
Tools
Figma
Problem
The idea came from a pain point I remembered from high school, where I studied classical voice: the difficulty of transposing sheet music into a different key. I wanted to find out whether this was specific to classical vocalists like myself, or something other musicians experienced as well.
Research
Competitor Analysis
Thematic Analysis
6.3
average frustration rate
/10
I interviewed 9 people in total to understand whether the transposition pain point I had experienced as a classical vocalist was shared by other musicians. After the interviews, I narrowed the target group to 5 participants (P1, P4, P5, P6, P8) who were more directly relevant to the research goal.
3
gave up on a piece due to transposition issues
/5
The clearest pattern came from Barriers and Current Method: frustration was driven not just by the time and cost involved, but by how much the difficulty depended on a piece’s popularity. None of the 5 participants’ actual solutions involved a dedicated transposition app. Instead, they relied on manual work, paid websites, or built-in device features.
The key insight from this analysis was that transposition was not only a practical problem, but created frustration and influenced how participants approached or abandoned pieces
The other 4 were excluded for reasons specific to their instruments, playing style, or current role.Key findings:
5
needed to transpose sheet music
/5
To understand whether this was already being solved elsewhere, I compared 4 apps used by musicians.
P1 rated their frustration with transposing as “laziness level 9.5.”
P5, on the time cost of finding a correctly transposed version: “Sometimes I bought one but it was just incorrect… so then the next day I had to find another one.”
None of the 4 apps analysed (Metronaut, Melody Scanner, ForScore, and MuseScore) have transposition as their main feature; it works as a secondary or side feature in all of them. Free versions were generally too restrictive, with most core features locked behind a premium upgrade. Melody Scanner’s camera scan redirects to an external website, creating friction in the workflow and a potential drop-off point.
To bring the interview findings together, I applied thematic analysis to the data, coding it into several themes: emotions, barriers, context, behaviour, current method, and needs.
Pivot
The project began with a clear assumption: transposition was the main problem. Early interviews supported this, as all 5 participants needed it, with frustration averaging 6.3/10.
But the questions about practice habits revealed transposition wasn’t isolated. P1 described struggling with complicated rhythms and losing track of solo parts. P8 relied on bookmarks and described being a slow reader. Competitor research added another signal: apps like Newzik, which already combined ensemble and practice management, weakening the idea of transposition as an unclaimed feature.
I shifted focus from finding a feature no other app had to addressing the pain points the target group actually raised. The project evolved from “How might we help musicians maintain their flow while changing keys and turning pages?” to
“How might we reduce preparation friction within individual music practice workflows?”
Personas & Journey Maps
→
Information Architecture & User Flow
Personas were rebuilt after the interviews, combining the 5 target participants into two personas (Peter,Sara) based on overlapping context, with pain points grounded in specific data rather than assumptions.
The journey maps changed more significantly, from a 3-stage structure based on assumptions to a 5-stage structure reflecting what interviews actually showed: Realise needs, Search, Struggle, Resolve/Compromise, and Practice. Peter’s journey ends in compromise; Sara’s ends in resolution. The added Practice stage reflects what the research had already shown: even after finding the right key, other difficulties continued, like losing track of notes or struggling with page turns.
The user flow changed more, from 3 separate flows (auto-transpose, practising with a saved sheet, editing a sheet) to 2: a main flow where import, transpose, and practice connect in a loop rather than a fixed sequence, and a separate flow for resuming previous practice.
The core structure ( Main Screen, Library, Settings) stayed the same. Changes were concentrated in the sheet viewer: Bookmark and Play were added, Edit Sheet was removed.
→
Design
Design decisions
Most of the original design decisions held up after the interviews and scope change, but some were revised, dropped, or added based on what the research showed.
Transpose as primary action
Transpose remained the core feature. The key signature typically sits at the top left of a sheet, which likely draws attention there first, and this matched how consistently key changes came up as a pain point in interviews.
Play elevated to same priority
Play was originally a secondary function, like Metronome and Notes, but was elevated to the same priority as Transpose once the scope expanded. This wasn’t based on interview data directly, but on the reasoning that playback marks the start of the core practice activity, while annotation and bookmarking only support specific moments within it.
No home screen
The app opens directly into uploading or scanning a sheet, skipping a home or dashboard screen. This matched interview data (Q14) on what musicians did first when opening the apps they already used: most went straight to finding or opening their own piece, rather than a management-style home screen.
Edit sheet, including pen-based note recognition, was one of the ideas I was attached to. I went back to the data looking for a reason to keep it, and couldn’t find one. It was dropped.
This was based on feedback from a design professor, who advised picking one clear focus rather than designing for a broad, undefined audience. Given the realistic constraints on finding test participants and time, and my own background in classical voice, classical music was the more practical focus.
The colour system follows a 60-30-10% rule: 60% sheet music and off-white background, 30% text and UI elements, and 10% burgundy, used for Transpose and Play, matching their priority as the app’s core actions.
Inter, a geometric sans-serif, keeps the interface feeling modern rather than old-fashioned, even with a rich colour like burgundy.
Edit sheet removed
Visual Design
Testing
Testing was conducted 2 rounds with 12 participants total: 6 for mid-fi (M1-M6) and 6 new participants for high-fi (H1-H6), at Prins Claus Conservatorium, Groningen.
Framework
Method: Moderated, task-based, think-aloud
Tasks: 2 (transposing a piece from E to F, finding a saved sheet)
Data: quantitative (time on task, errors) and qualitative(quotes)
Mid-fidelity
Results:
Task 1 — Transposing
32.8s → 25s
Time
Task 2 — Library
10.5s → 5.3s
Time
High-fidelity
The high-fi design was received positively across all 6 participants, such as:
“Musician-friendly”
Since mid-fi already showed 100% task completion and low error rates, most changes going into high-fi were refinements rather than structural redesigns. The key label was simplified from “EM” to just “E”, removing the Major/Minor distinction entirely. The library icon was redesigned based on confusion observed in mid-fi (M3 missed it, M6 suggested it look more like musical staff lines); this carried into high-fi without further issues.
“
A little colour, and there’s nothing changed about the sheet music. It’s really clear”
These results give some support to a few of the core design decisions: keeping Transpose and Play as primary actions, using an empty state rather than onboarding, and combining a stepper with a dropdown for key selection all worked without causing confusion across both rounds of testing.
Not everything was fully resolved. The library icon was already redesigned once, but H6 still suggested making it bigger. Testing so far has also focused mainly on the transpose and library flows; since the project’s scope expanded to the broader practice workflow, testing an actual practice session would give a fuller picture.
Overall, testing across both rounds suggests the research-to-design process held up in practice: pain points from the interviews and thematic analysis led to specific design decisions, and those decisions were tested with real users.
“Perfect, very clear,
it works”
0.66 → 0.33
Error
0.33 → 0
Error
Reflection
Working on this project reinforced how easy it is to fall in love with an original idea. The hardest part wasn’t the design itself, but staying open to evidence that the initial direction needed to change.
Next step
Research and design how practice-flow interaction like annotation and playback actually work in a full session, and then test them together
Prototype and test a vocal range indicator, showing a piece’s highest and lowest notes, raised by one participant