TL;DR
Heloa is a connected child health record that guides parents through their child's first years with personalised health questionnaires. The medical logic behind those questionnaires was hardcoded into the app — algorithms couldn't be verified, questions couldn't be easily added, and adapting content to new medical guidelines took months.
I designed a new version of QStudio from scratch: a back-office platform that lets a non-technical medical team build, connect, and maintain the entire questionnaire engine visually. What previously took 3 years to cover the first 7 years of a child's life now takes 3 months — with full confidence in the accuracy and connectivity of every algorithm.
Context & Problem
The first version of QStudio had gotten the team this far, but the system was rigid. The algorithms were hardcoded — the medical team couldn't modify them, couldn't verify the branching logic, and couldn't test how a change in one question would ripple through the rest of the flow. Adding or editing a question required developer involvement.
The numbers told the story clearly: it took 3 years to build the questionnaire content covering a child's first 7 years. That pace was unsustainable — we needed to expand to new countries, new languages, new medical standards. And every content update carried risk because no one could visually confirm how algorithms actually worked.
Research & Discovery
This project didn't start with traditional user research — it started with deep immersion into the medical content team's workflow and the structure of paediatric medical knowledge itself.
The key insight was that medical reasoning and questionnaire logic are the same decision-tree structure — but inverted. A physician starts from a suspected pathology and checks symptoms top-down. A parent-facing screening questionnaire has to work bottom-up — starting from symptoms and identifying which domain warrants a visit to the doctor. Understanding this inversion shaped every design decision that followed.
I also mapped the full scope of medical content the platform needed to handle: pathologies organised in hierarchies, vaccines, allergies, developmental milestones, and medical events. Each content type needed to be available as a reference inside questionnaires.
This wasn't just a questionnaire builder. It was a content management system for interconnected medical knowledge.
Key Decisions
An information architecture shaped by medical standards
The most important structural decision was the content hierarchy: Standards → Periods → Questionnaires → Questions, with Pathology Modules as reusable sub-questionnaires.
Standards map to countries. Each country has its own paediatric guidelines and medical conventions. A Standard is the top-level container for everything specific to one country's medical framework.
Periods represent stages in a child's development — "First trimester of pregnancy," "0–2 months," "2–4 months," and so on.
Pathology Modules are the key architectural innovation. A condition like gastroesophageal reflux disease needs to be screened across multiple age periods. Rather than duplicating the entire screening flow in every period's questionnaire, I created Pathology Modules as standalone, reusable questionnaire fragments — built once, referenced wherever needed. Change the module, and every questionnaire that uses it updates automatically.
This composability is what made the 3-year-to-3-month acceleration possible.
A visual flow builder — because physicians think in flows, not forms
The most consequential design decision was choosing a visual, node-based flow builder as the primary editing interface.
The medical team needed to understand — at a glance — how questions connected to each other, where conditions branched, and where pathology modules plugged in. They aren't technical. A spreadsheet of IF/THEN rules would have been useless.
The visual flow builder solved this by representing each question or module as a node, with connections showing the path a parent takes through the questionnaire. The medical team can see the entire algorithm laid out spatially.
The condition system: the algorithm engine
Conditions serve three distinct roles:
Routing between questions — determining which question comes next based on previous answers. A grouped logic model ("If match all/any conditions in this group → Go to next question") lets the medical team build branching paths.
Determining whether to see a doctor — the most critical output. Exit conditions evaluate pathology module completions and set a result: "See Doctor" or not.
This is the area where I know the design fell short. The condition builder works — the medical team uses it daily — but it still reads like a query builder. I would have liked to evolve this toward a more natural-language representation.
What We Built
QStudio is the back-office that powers everything Heloa delivers to parents.
The Question Editor — rich text title with variables, subtitle, image upload, answer configuration, linked advice content, and the condition logic.
Personalised Advice — in the old system, advice was tied to a question regardless of what the parent answered. The new QStudio ties advice to specific answers. If a parent says their baby spits up after meals, they get advice about reflux. If they say no, they get different content — or none at all.
Outcomes
From 3 years to 3 months. The original content covering a child's first 7 years took 3 years to produce. With the redesigned platform, comparable scope now takes roughly 3 months.
~80% reduction in content production time. The medical team estimates they work roughly five times faster — they can create, connect, test, and iterate on questionnaires without developer involvement.
Full confidence in medical algorithms. For the first time, the team can visually verify that every algorithm works as intended.
A personalised parent experience. The redesign enabled customised questions, tailored advice based on answers, and end-of-questionnaire summaries adapted to each family's situation.
What I'd Do Differently
The condition builder is still too technical. It works, but it's a query builder wearing a medical hat. I would invest in a natural-language representation layer on top of the existing logic engine.
We built, broke, and rebuilt too often. On a project this complex, with this small a team, we sometimes moved too fast — shipping a pattern before fully stress-testing it against edge cases. More upfront modelling of content edge cases would have saved rebuilding time.
I would have involved the medical team in design reviews earlier. Some early design decisions were made with developer feasibility as the primary constraint rather than medical team usability.