A semester project with real patients in the room
Melafy was a Medical Design project at HfG Schwäbisch Gmünd, built over one semester in a team of three and supervised by Prof. Hans Krämer and Prof. Jens Döring. Skin cancer patients, contacts from teledermatology and researchers at the German Cancer Research Center in Heidelberg supported the work throughout.
credits
A prototype you can hand to a patient
We opened with a two-week Google Design Sprint and carried its results into the process, then worked through user journey mapping and interviews. We decided early on a modular, testable hardware prototype over a finished-looking one, and paired it with a functional Figma click dummy. That pair became the instrument. We put it in the hands of real skin cancer patients, teledermatology contacts and DKFZ researchers, and changed it between sessions.
The same picture every time
A photograph a patient takes of their own mole only helps if it can be compared to the last one. So the scanner’s job is consistency: same distance, same angle, same light, on every capture. Light rings on the underside guide placement, and the app’s comparison view puts two dated captures side by side with colour spectrum, boundary and surface readings, so change over months becomes visible.
We simulated the plumbing to design the risk
Capturing the image on the device and transferring it to the phone was the expensive, uninteresting half of the build. We simulated that step on both the device and the click dummy. It kept the project’s scope realistic and left the budget for the two interactions that carry the risk: placing the scanner consistently, and reading the comparison. Every design decision we made was tested against those two.
The doctor keeps the diagnosis
Melafy never tells a patient what a lesion is. The dermatologist opens the account and sets the first tasks, and the insurer ships the device. When something looks abnormal, the doctor receives a package containing the patient’s questionnaire and the image comparison, and decides from there. The patient gains a role in their own aftercare while the diagnosis stays where it belongs.
decision 04
Modular from the first print
An ESP32 DevkitC V4 in a 3D-printed case, deliberately over-provisioned so functions could be added later. Three enclosures went through sketch, print and test on real forearms before one of them won. Because the build was modular, a test on Thursday could change the form by Monday, which is how the haptics got decided against real hands.
craft
Hardware and interface in one loop
Arduino C++ on the device, Shapr3D and Blender for the enclosure, an Ultimaker for every iteration of it, Figma for the app. Keeping all four in the same weekly loop is what let a finding from a usability test land in the next printed housing.
outcome
Tested with real patients, and it stopped there
A working interactive prototype, a functional click dummy and a project film. The device went through three printed enclosures, each sketched, printed and tested on real forearms, before one of them won. Skin cancer patients used it, DKFZ researchers and teledermatology contacts reviewed it, and each session changed the next print. It stayed a semester project and went no further.
learnings
Two limits I would name in an interview
The readings in the comparison view are an interface concept. We simulated the capture pipeline on purpose, so those numbers were never validated as measurements. The second limit is bigger. The whole system rests on patients keeping this up for years, and one semester cannot test that. If I picked it up again I would start with a longitudinal study and with the doctor’s side, because the model only scales if reviewing uploads costs less than the appointment it replaces.