Vladyslav Didyk

Gambit — Admisión de pacientes en hebreo

Un cuestionario en hebreo para un programa de salud: cuatro recorridos de pacientes, un formulario sencillo.

Gambit — Admisión de pacientes en hebreo

Gambit es un cuestionario de admisión en hebreo, de derecha a izquierda, con cuatro recorridos de pacientes. Las respuestas llegan a una Hoja de cálculo de Google. Lo diseñé y construí yo solo en tres semanas en 2023.

Una página de admisión en hebreo para un programa de detección de cáncer BRCA. Recibe a cuatro tipos de pacientes (personas que consideran hacerse la prueba, portadores del gen, pacientes en tratamiento y personas en recuperación) y le hace a cada grupo las preguntas correctas, en el tono correcto. Las respuestas llegan a una Hoja de cálculo de Google que la clínica ya sabe usar. Todo el sitio se lee de derecha a izquierda, porque todo está en hebreo.

Rol
En solitario: diseño y código
Plazo
3 semanas
Stack
Next.js 13 · React · MUI v4 · MUI v5 · Emotion · google-spreadsheet · Netlify

El encargo

Una herramienta de admisión, cuatro conversaciones muy distintas.

Para quién es el cuestionario.

Gambit es una herramienta de admisión en hebreo para un programa de detección de cáncer BRCA. Tiene que hablarle a cuatro personas en momentos muy distintos del mismo camino: alguien que nunca se ha hecho la prueba, alguien que acaba de saber que porta el gen, alguien en tratamiento activo y alguien en recuperación. Las mismas preguntas serían inadecuadas para los cuatro. También lo sería el mismo tono.

Lo que tiene que ser.

Tranquila. Primero en hebreo. De derecha a izquierda. Lo bastante corta para terminarla de una sola vez, lo bastante estructurada para recoger lo que necesita la clínica y lo bastante suave para que una persona con cáncer no sienta que responde un cuestionario de preguntas sorpresa. Y lo bastante simple para que una organización pequeña la gestione sin un equipo de ingeniería.

Los flujos

Cuatro recorridos, un motor.

Elija un mosaico y reciba sus preguntas.

La página de inicio muestra cuatro mosaicos. Al tocar uno se abre una ventana que le guía por las preguntas de ese recorrido, una por una, y termina con un breve formulario de contacto. Cuatro entrevistas distintas, pero detrás de escena un solo motor las ejecuta todas.

Las preguntas viven en una lista, no en el código.

Cada pregunta está en un archivo simple: su texto, su tipo de respuesta (sí/no, casillas, una fecha, texto libre) y un seguimiento opcional: “si es sí, ¿quién?”. Cambiar el cuestionario significa editar esa lista, no la aplicación. No hace falta un desarrollador para cambiar una redacción.

Bajo el capó

Cuatro piezas móviles, cada una con una sola tarea.

Deliberadamente simple.

La aplicación sigue cuatro cosas mientras se llena el formulario: sus respuestas hasta ahora, si la pregunta actual está respondida (eso es lo que habilita el botón “Siguiente”), en qué paso está y la ventana de qué recorrido está abierta. Cada pieza tiene exactamente una tarea, organizadas en capas en un orden fijo: fácil de razonar, difícil de romper.

Las cuatro piezas.

  • Las respuestas — Todo lo que se ha llenado hasta ahora: esto es lo que al final se convierte en una fila de la Hoja de cálculo de Google.
  • La verificación “¿puedo continuar?” — Un solo valor sí/no: ¿está respondida la pregunta actual? El botón Siguiente lee esto y nada más.
  • El contador de pasos — En qué pregunta está. Atrás y Siguiente lo mueven; el formulario lo sigue.
  • La ventana abierta — La ventana de qué recorrido está en pantalla ahora mismo. Los mosaicos de inicio la establecen; la ventana la lee.

Adónde van las respuestas

Hojas de cálculo de Google es todo el backend.

Sin base de datos, a propósito.

No hay base de datos ni panel de administración. Cuando un paciente termina, las respuestas se agregan como una nueva fila en una Hoja de cálculo de Google. La clínica abre esa hoja para ver las nuevas admisiones: la misma herramienta que ya usa para todo lo demás. Nada nuevo que aprender, nada nuevo que mantener.

Las claves se quedan en el servidor.

La conexión con Google usa una clave privada. Esa clave vive solo en el servidor y nunca llega al navegador del visitante: el pequeño cuidado técnico que hace que una configuración simple también sea segura.

Idioma

Cada palabra en hebreo importa.

De derecha a izquierda, en todas partes.

Cada etiqueta, botón y título está en hebreo, y todo el diseño se lee de derecha a izquierda, definido una vez en el nivel superior para que cada parte de la página herede automáticamente la dirección de lectura correcta.

Palabras que no se desvían.

Reformular una pregunta en un formulario médico no es un cambio cosmético: cambia lo que se le está preguntando a una persona vulnerable. Algunos cambios en la historia de este proyecto existen solo para corregir un espacio o una coma en una etiqueta en hebreo. La regla: tratar cada palabra como importante y cambiar solo lo que la clínica pida explícitamente.

Una decisión práctica

Dos versiones de un mismo kit de diseño, lado a lado.

Estabilidad antes que orden.

El proyecto usa a la vez dos versiones del mismo kit de diseño: las pantallas más antiguas usan la vieja y las más nuevas usan la nueva. Actualizar todo para que coincida significaría volver a probar cada recorrido de paciente, y volver a probar un cuestionario médico no es poca cosa. Por eso cada pantalla conserva la versión con la que fue construida. Gana la estabilidad.

Siguiente proyecto: Pixel — Diagnóstico de pantalla