Gambit — Hebrew Patient Intake

The brief

One intake tool, four very different conversations.

Who the questionnaire is for.

Gambit is a Hebrew intake tool for a BRCA cancer-screening program. It has to talk to four people at very different points of the same journey — someone who has never been tested, someone who just learned they carry the gene, someone in active treatment, and someone in recovery. The same questions would be wrong for all four. So would the same tone.

What it has to be.

Quiet. Hebrew-first. Right-to-left. Short enough to finish in one sitting, structured enough to capture what the clinic needs, and soft enough that a person with cancer isn't answering a pop-up quiz. And simple enough for a small organization to run without an engineering team.

The flows

Four journeys, one engine.

Pick a tile, get your questions.

The landing page shows four tiles. Tapping one opens a window that walks you through that journey's questions, one at a time, and ends with a short contact form. Four different interviews — but behind the scenes, one shared engine runs them all.

Questions live in a list, not in code.

Every question sits in one simple file: its text, its answer type (yes/no, checkboxes, a date, free text), and an optional follow-up — "if yes, who?". Changing the questionnaire means editing that list, not the app itself. No developer needed for a wording change.

Under the hood

Four moving parts, each with one job.

Kept deliberately simple.

The app tracks four things while you fill the form: your answers so far, whether the current question is answered (that's what unlocks the "Next" button), which step you're on, and which journey's window is open. Each part has exactly one job, layered in a fixed order — simple to reason about, hard to break.

The four parts.

• The answers — Everything you've filled in so far — this is what becomes a row in the Google Sheet at the end.
• The "can I continue?" check — One yes/no value: is the current question answered? The Next button reads this and nothing else.
• The step counter — Which question you're on. Back and Next move it; the form follows.
• The open window — Which journey's window is on screen right now. The landing tiles set it; the window reads it.

Where answers go

Google Sheets is the whole backend.

No database, on purpose.

There is no database and no admin panel. When a patient finishes, the answers are added as a new row in a Google Sheet. The clinic opens that sheet to see new intakes — the same tool they already use for everything else. Nothing new to learn, nothing new to maintain.

The keys stay on the server.

The connection to Google uses a private key. That key lives only on the server and never reaches the visitor's browser — the small technical care that keeps a simple setup also a safe one.

Language

Every Hebrew word matters.

Right-to-left, everywhere.

Every label, button, and heading is in Hebrew, and the whole layout reads right-to-left — set once at the top level, so every part of the page inherits the correct reading direction automatically.

Words that can't drift.

Rewording a question in a medical form is not a cosmetic change — it changes what a vulnerable person is being asked. Some changes in this project's history exist only to fix a single space or comma in one Hebrew label. The rule: treat every word as important, and change only what the clinic explicitly asks for.

A practical choice

Two versions of one design kit, side by side.

Stability over tidiness.

The project uses two versions of the same design kit at once — older screens use the old one, newer screens use the new one. Upgrading everything to match would mean re-testing every patient journey, and re-testing a medical questionnaire is not a small task. So each screen keeps the version it was built with. Stability wins.