An eye-controlled application for a university hospital

An assistive application for patients who cannot use their hands: eye-tracker control, speech synthesis and a guided journey.

University teaching hospital 2024 → 2025

In plain words

The need
A teaching hospital cares for patients who have lost the use of their hands. For them a touchscreen is not an interface, it is a wall.
What we delivered
An application driven entirely by gaze, with speech output, designed around that way of interacting from the start rather than adapted to it afterwards.
What it changed
The hospital has a tool its patients can use with no hands, where no ordinary application was usable at all.
Sector
University teaching hospital
Period
2024 → 2025
Our role
Design and development of the assistive application
Tech stack
  • Eye tracking
  • Speech synthesis
  • BLoC
  • Clean Architecture

At a glance

  • Fully gaze-driven, with no touch and no keyboard
  • Speech synthesis and audio feedback built in
  • Layered architecture, handover-ready for another team

The context

A university teaching hospital supports patients who have lost the use of their hands — neurodegenerative disease, paralysis, the aftermath of an accident. For them a touchscreen is not an interface: it is a wall.

Eye trackers exist — sensors that follow your gaze and let you point at a spot on the screen with your eyes. The hardware was there. What was missing was an application designed from the ground up for that mode of interaction.

The challenge

A gaze-driven application is not a regular application with sensor support bolted on. Everything changes.

There is no click. Pointing and confirming are the same gesture, which forces a dwell-based confirmation — looking at a target long enough to validate it. Too short, and users trigger actions unintentionally just by scanning the screen. Too long, and every interaction becomes exhausting.

Targets must be large and well separated. Gaze precision is not finger precision, let alone mouse precision. A dense interface with small buttons close together is simply unusable.

No error is harmless. A user who cannot cancel with a gesture or reflexively close a window is stuck. Every screen needs an exit, reachable by gaze.

And fatigue is the real adversary. This audience tires quickly. The number of interactions needed to reach a result is not a comfort detail: it is the product’s success criterion.

What we did

  • Eye-tracker integration as the primary input mode — not an option added later, but the founding assumption of the whole interface.
  • A step-by-step guided journey, with explicit progress. Users always know where they are and how much is left — which matters doubly when every step costs effort.
  • Speech synthesis and audio feedback. Sound carries confirmation, because a subtle visual cue goes unnoticed when the gaze is already busy navigating.
  • Adaptation to the screen’s physical size, not its resolution. A target must measure the same in real centimetres on any device — gaze precision sets the rule, not pixel count.
  • A layered architecture separating data, domain and interface, with dependency injection and explicit state management.

The outcome

An application whose primary interaction mode is the user’s gaze, delivered to a hospital.

The architectural choice deserves a word here. Putting everything in the screens would have been quicker. But an application delivered to a teaching hospital is meant to be handed over, audited and extended by others — sometimes years later, sometimes by an internal team. Separating the layers cleanly was not technical vanity: it is what makes the project transferable.

It is also the project that most directly illustrates why accessibility is not a checkbox at the end of development. Here, it was the product.

Screenshots

Screenshot coming
Screenshot coming
Screenshot coming

Client covered by a confidentiality agreement

Shall we talk?

Tell us about your idea in a few lines. We reply within one business day with concrete first feedback — no strings attached.