Author: The no-code tool for fast and flexible health questionnaire creation

The questionnaire had been built for general surgery, and everything about it was fixed in code. That caused problems in three places.

• Growth. Built for general surgery only, it kept Definition Health out of high-volume, lower-risk pathways like endoscopy. Hospitals also couldn't adapt it to their own policies.
• Cost of change. Content was hard-coded, so adding a single question could take up to two sprints of engineering.
• Patients. It was built on SurveyJS, a third-party form builder whose markup fell short of WCAG AA. Patients also complained about its length and relevance, and satisfaction scores reflected it.

Before I joined, Definition Health had built up a clear picture of the problems through patient satisfaction surveys, support contact, hospital meetings, training sessions and an NHS audit. A company-wide workshop on my first day turned that into a brief: produce many tailored questionnaires instead of one, let clinical staff edit content without engineers, rethink the navigation for mobile and accessibility, and add screening questions so patients only answer what applies to them.

Author had to handle a lot of connected data: question sets, pages, sections, patient questions, clinical questions and the rules between them. Before designing any screens, the product manager and I mapped it using object-oriented UX, listing every object, its attributes, its actions and how it related to the others.

Sharing the map with engineering showed we weren't all picturing the same system. I ran an alignment workshop to work through where we agreed and where we didn't. Then I studied survey builders, form builders and workflow tools for patterns we could reuse.

Each questionnaire holds questions for two audiences. Patients answer their questions first, then a pre-op nurse reviews those answers and completes clinical questions of their own. Patients shouldn't see the clinical questions, but the people building the questionnaire need to see both together to make sense of a page.

I explored three options:

• Tabs for patient and clinician. Dropped, because switching tabs hid the context clinical users needed.
• A side-by-side builder that matched the final clinical view. Dropped, because it needed bigger screens than the 15-inch laptops our users worked on, and more engineering time than we had.
• One page, with each question marked as patient or clinician. Chosen. It didn't mirror the final layout, but it showed the whole page at once, and it made conditional logic easier to build later.

Patients, especially those with few or no health conditions, were answering far more questions than they needed to. Conditional logic would let questions appear only when an earlier answer made them relevant.

I drafted the requirements with our clinical team, then broke the logic into levels of complexity. The questionnaire the clinical team had designed for endoscopy could be built almost entirely with the simplest level, which gave us a focused first version.

I explored driving logic from "disclosures", the medical facts recorded against answers. We decided the disclosure system wasn't mature enough yet, so logic ran from questions and answers instead.

Logic-driven questions got a branch icon and a distinct highlight, since users already called the feature "branching". Once logic could span pages, I designed a Tree Browser so editors could find any question in the questionnaire without the canvas being covered.

The old questionnaire's worst input was the radio matrix: rows of conditions, each with Yes and No radios under column headings. The radios were below AA target size, and they had no labels of their own, so on a phone the headings scrolled away and patients had to remember which column meant yes.

I replaced it with a checkbox list and a "no to all" option at the bottom. That rested on a clinical decision to record only the conditions a patient has, which the clinical team judged safe. I put "no to all" last so that patients would see the full list before choosing it. In Author it's a single switch, and the front end handles the toggling. I also redesigned the radios with large click areas that meet the WCAG 2.2 AAA target size.

With Author, a questionnaire change that used to take around four weeks of engineering became a few minutes of work for a clinical editor. New questionnaires needed no engineering at all, and the clinical editors built several themselves, including endoscopy, a pathway the old survey couldn't serve.

For patients, logic and the new inputs cut the effort of answering. In our designs, patients with no health conditions needed up to 50% fewer clicks and taps, and those who triggered every mapped condition needed 30% fewer. Every input was built from our own accessible components instead of SurveyJS.

The clinical editors had started working with hospitals that were keen to see Author go live, and hospital testing was planned after positive demos. Before that could happen, Definition Health went into administration. The Author IP was bought by a larger competitor.