Galenus AI
Field research in El Salvador for an AI-powered medical assistant. The problem wasn't the model —it was that its reports didn't match the ones hospitals already used.
Industry
Digital Health · AI
Role
UX Researcher
Period
2022 – 2024
team
Distributed across three countries
TOols
Adobe XD, Figma, Excel
Reading time
6 min
In summary
The team was developing an AI engine capable of generating medical reports. The problem was not technical: the reports did not fit the format hospitals were already using.
I analyzed focus groups and field-recorded usability sessions with healthcare professionals, transcribing and coding the sessions while tracking friction screen by screen.
The analysis identified screens with failure rates close to 100% and produced a report broken down into design, content, and technical functionality.
I then designed an ethnographic research plan in primary care to understand how patient data is actually collected during consultations. The study was fully planned, but execution was still pending when I left the project.
01
The Problem
An AI engine can generate medically accurate reports and still be unusable if those reports don't look anything like the ones a hospital already uses.
A doctor with seven minutes per patient is not going to adapt their workflow to a completely new format. They will abandon the tool.
The technical team was working on the engine and reverse-engineering the actual report formats used by Salvadoran hospitals. My role was the other side of that equation: understanding the real clinical workflow the engine had to fit into.
How is patient information collected today, who collects it, and what tools do they use?
The question that comes before any interface question.
A distributed team, a shared product
The project was distributed across three countries: the product and development team in the Dominican Republic, a partner company in Mexico that provided consulting and developed part of the application, and advisors and physicians in El Salvador who understood the healthcare system where the product had to work.
That distribution explains much of the challenge: the people building the tool and the people who would use it did not share the same country or clinical context.
02
Fieldwork
I led in-person sessions with healthcare professionals in El Salvador, recorded for later analysis. The test subject was the patient-facing side of the application.
The analysis went beyond general observations. I transcribed and coded the recordings, tracking behavior screen by screen and organizing the results into a friction matrix by flow.
Coding the sessions is what turns a recording into a list of priorities.
The analysis of sessions with doctors. Coding the material is what turns a recording into a priority list.
Friction matrix
Flow | Critical screen | Failure rate |
|---|---|---|
Prescriptions | Prescription information | ~100% |
Profile | Profile navigation | ~100% |
Registration | Date of birth | ~85% |
Registration | Sign-up & onboarding | ~70% |
Appointments | Appointment navigation | >75% |
Schedule | — | ~30% |
The operational conclusion was about prioritization: prescriptions, profile, and registration had the most severe failures and needed to be addressed first.
The appointments flow, on the other hand, had one screen causing extreme confusion while the rest of the flow worked —the lowest-cost fix with the highest potential return.
03
From Findings to Decisions
The recommendations report didn't stop at “this screen is confusing.”
Each problem was broken down into three actionable layers, each directed at a different owner:
Design
What should change in the interface.
Content
What should change in the wording or information architecture.
Technical
What required a functional change in the product.
Date of birth · ~85% failure
Design: Replace the numeric keyboard with a date picker to eliminate formatting problems with slashes.
Content: If manual entry is retained, display the required format directly above the field.
Technical: Auto-format the date as the user types.
Prescription information · ~100% failure
Design: Use visual cues to distinguish the status and available actions for each prescription, and clearly separate the prescription itself from pharmacy access.
Content: Use plain language for statuses, with a glossary for unfamiliar terms.
Technical: Integrate a pharmacy locator with clear steps for obtaining the medication.
Registration onboarding · ~70% failure
Design: Remove non-essential questions from the initial sign-up and move them to the profile.
Content: Break the information into sections that can be completed over time.
Technical: Allow users to choose weight and height units, and restrict input to valid ranges.
Why this structure?
A report that only says “there is confusion” leaves the work unfinished.
Separating design, content, and technical functionality allows each discipline to take ownership of its part without having to negotiate the finding first —and helps the insight survive the meeting where it is presented.
04
Ethnographic Research in Primary Care
I later designed a qualitative ethnographic study to answer the deeper question, with explicit and falsifiable hypotheses.
For example:
“Doctors are the primary collectors of patient information, rather than support staff.”
Framed this way, the research could prove the hypothesis wrong.
The study combined three methods:
Participant observation during real consultations
Semi-structured interviews with doctors, nurses, receptionists, and patients
Document analysis of forms and existing records
The plan also included ethical considerations around informed consent, anonymity, and non-interference during consultations.
Risks were identified from the start: access to sensitive information under medical privacy regulations, observer effects, cultural barriers, and differences in tools between healthcare centers.
What happened to the study?
The study was not carried out while I was on the project.
The plan was complete and ready to execute, but implementation was delayed by other project priorities and was still pending when I left.
I include it because designing the study —with falsifiable hypotheses, combined methods, an ethical framework, and explicitly stated risks— was real research work, even though the fieldwork itself remained to be done.
Two users with different needs, timelines, and pressures on the same system. Designing a single journey would have failed for both.
05
Results
The research provided:
A data-based prioritization of which flows to fix first, using screen-level failure rates rather than opinions.
An actionable report organized by discipline, allowing design, content, and technical teams to work from the same findings.
Separate user journeys for doctors and patients, reflecting their different needs, contexts, and pressures.
A fully documented ethnographic research plan, ready for execution.
What I cannot claim:
I don't have adoption data or measured improvement after the recommendations were implemented.
This case therefore includes no post-implementation impact figures.
06
Learnings
The problem was the format, not the model
The engine worked.
What failed was the fit between its reports and the reports hospitals were already using.
For applied AI products, fitting into an existing workflow can matter more than the quality of the model itself —and you only discover that by going to the place where the work actually happens.
Screen-by-screen coding turns observations into priorities
A recorded session produces impressions.
A friction matrix produces a work order.
A bad result that is well localized is more useful than a good one that is vague
Discovering that a single screen was breaking the appointments flow was more useful than any positive finding that was too broad to act on.
Researching across countries means separating cultural factors from universal ones
A workflow that works in one healthcare system does not automatically transfer to another.
Research in a different country forces you to distinguish between what is culturally specific and what is genuinely universal.