The question
no one had asked.

A note on what this piece is.

This is not a traditional case study. There are no screens to show, no prototypes to interact with. The innovation I worked on is proprietary, the implementation details, the technical architecture, and the product specifics belong to the hearing care company.

What I can share, and what I believe is even more valuable, is how I think. How a UX instinct survived intact inside a deeply technical role. How a single question, asked at the right moment, opened a path through a complex system that nobody else was positioned to find.

Creating the space before filling it.

The whole journey with innovation started with a workshop. Our Scrum Master had organised an internal session focused on improving how we approached innovation as a team. We worked in small groups of three, each tasked with bringing an idea that could change the way we worked.

The problem was familiar to anyone who has worked in iterative development cycles. We had a dedicated innovation week at the end of each three-month sprint, but there was always something left to finish. Something urgent. Something that couldn't wait. The innovation week kept getting eaten by the work that came before it.

I had seen this pattern before. During my IT studies, where I was constantly moving between highly technical subjects and creative work, I had developed a personal rhythm balancing between the two in short, regular intervals rather than saving the creative work for later. Later never came. So I stopped waiting for it.

I called it the sandwich method. In the workshop I proposed a version of it for the team: instead of reserving a full week at the end of a long cycle, we dedicate 10% of each two-week sprint to innovation. Small, consistent, protected time, built into the rhythm rather than bolted onto the end of it.

My team loved it. Our Scrum Master brought it to management. They accepted it. I had opened a door. And I walked straight through it.

The question that started everything.

A few weeks later I found myself in an onboarding session on audiology. Two Hearing Care professionals were walking us through the science of hearing loss, the technology, the daily reality of their patients. The kind of session where you realise how little you knew about something that affects millions of people.

That's how my mind works in those moments. As it absorbs new knowledge, it starts making connections automatically, between what exists, what's possible, what might be missing. The experts were introducing us to the features users could already access through the app. And somewhere in the back of my mind, a question was forming.

At the end, they opened the floor. I asked it.

One of them didn't hesitate. "I hear it all the time." That was enough for me to start.

I sketched the concept. Threw together a few slides to make the idea tangible. And then began what turned out to be a long journey, conversations across teams, finding alignments, climbing a steep learning curve of technical details I had never needed to understand before.

Staying in the system, not above it.

I could have stayed in my lane. I was a systems engineer. A technical role with a clear scope. I didn't stay in my lane.

I had a small window to work on it, 2 to 3 hours per iteration, the innovation time the team had adopted. Not much. But I used every minute of it, and I did it happily. There was nowhere else I wanted to be.

I validated the hypothesis with a marketing team who had data from a recent market study pointing in the same direction. The signal was real. But I was working on a highly constrained hardware system, not a web app, not a SaaS product. A medical device. And in that world, "the user wants this" is only the beginning of the conversation.

So I stopped designing and started listening. I spent weeks in conversations across every discipline that touched the product: embedded software specialists, hardware experts, connectivity teams, enterprise architects. I asked questions. I learned the language of the system I was trying to change. I mapped where the constraints lived, not to work around them, but to understand them well enough to find where something new could fit.

Already there, waiting to be found.

The moment I remember most clearly is sitting with an enterprise architect, walking through the existing technical stack. He pointed to something already there, a structure that, with a small extension, could do almost exactly what users were asking for. Low cost. High value. Technically feasible.

I was so excited I had to slow myself down.

This is what happens when UX thinking meets deep technical context. The solution wasn't invented, it was recognised. It had been sitting in the system, waiting for someone who understood both the user need and the architecture well enough to connect them.