Auth – Narrativa de Diseño
La primera impresion determina si ADEN es “otra app” o “mi app de salud”
La Historia
María descarga ADEN desde un link que le envió su médico. No la encontró en el App Store buscando “salud” – llegó por invitación. Esa distinción importa más de lo que parece.
Cuando abre la app por primera vez, lo que NO ve es tan importante como lo que ve. No ve un muro de campos obligatorios. No ve un formulario de registro con quince líneas. No ve “Acepta cookies” tapando media pantalla. Ve una pantalla limpia con un campo de email, un botón de acción, y una línea que dice “Inicia sesión en ADEN”. Debajo, social login. Nada mas.
En Colombia, el 80% de los usuarios no confían en apps que piden datos personales (Mobile Growth Association, 2024). En salud, esa desconfianza se multiplica. Los colombianos vienen de un ecosistema de EPS donde las apps oficiales tienen 40+ puntos de caída en satisfacción, donde el gasto de bolsillo médico subió 5% en 2024, y donde solo 6 de 29 EPS cumplen regulación financiera. La confianza está rota. ADEN no puede permitirse un solo momento que refuerce esa desconfianza. Los primeros 30 segundos son un contrato emocional: demostrar que este servicio es diferente antes de pedir un solo dato.
Por eso el auth de ADEN no empieza con “dame tu información”. Empieza con “te estabamos esperando”. El código de invitación que María ingresa no es friction – es señal. Le dice: “esto no es para cualquiera; alguien que te conoce penso que lo necesitabas”. Es la diferencia entre entrar a un hospital y entrar al consultorio de un médico que ya sabe tu nombre.
Principio de Diseño: Confianza Antes de Datos
El magic link no es una decisión técnica. Es una decisión de confianza.
Cuando un servicio de salud le pide a un usuario colombiano que cree una contraseña, está comunicando implícitamente: “este es un sistema más que vas a tener que administrar”. Las contraseñas cargan el peso cognitivo de seguridad sobre el usuario. El magic link invierte esa dinámica: ADEN asume la responsabilidad de la seguridad. El usuario solo confirma su identidad a través de su email – un canal que ya controla y en el que ya confía.
La biometría es prominente para usuarios recurrentes por la misma razón. Face ID y Touch ID no son features de conveniencia – son señales de seguridad percibida. Cuando María abre ADEN y ve el prompt biometrico, el mensaje implícito es: “nadie más puede ver esto”. En un contexto donde los datos de salud son clasificados como “datos sensibles” bajo la Ley 1581 de 2012, esa señal no es decorativa – es regulatoria y emocional a la vez.
Social login existe, pero es secundario, no primario. Esta es una decisión deliberada. En wellness apps (fitness, meditación, nutrición), el social login es el patrón dominante porque reduce friction. Pero ADEN no es una wellness app. Es un copiloto clínico que procesa farmacogenómica, biomarcadores y scores poligenicos. Cuando un usuario asocia sus datos médicos con una cuenta social, esa decisión tiene implicaciones que no tiene asociar una app de meditación. Ofrecemos social login porque reducir friction importa (CleverTap documenta un 60% de boost en completion con social login). Pero lo posicionamos como alternativa, no como default, porque en salud el usuario debe sentir que su cuenta es un espacio dedicado, no una extensión de su ecosistema digital general.
Decisiones Clave
| Decisión | Por Qué | Dato que Respalda | Alternativa Descartada |
|---|---|---|---|
| Magic link como método primario | Elimina la carga cognitiva de contraseñas y comunica que ADEN asume la seguridad | Requerir signup antes de valor aumenta abandono 56% (CleverTap). Magic links tienen 2-3x mayor conversión que password-first en health apps | Password-first con requisitos de complejidad – comunica “esto es un sistema”, no “esto es tu espacio” |
| Modelo invite-only con código de 6 caracteres | Senala exclusividad médica, filtra a usuarios con intención real, crea sensación de pertenencia | 74% de usuarios abandonan si enfrentan friction al inicio (Reteno). El código reduce friction percibida porque reemplaza “registrate” con “te invitaron” | Registro abierto – diluye la señal de calidad médica y atrae usuarios sin intención de completar onboarding |
| Biometría prominente para sesiones recurrentes | Face ID/Touch ID son la señal más fuerte de seguridad percibida en mobile. Reducen login a 0 taps conscientes | 80% de usuarios LATAM no confían en apps con datos personales (Mobile Growth Association). Biometría es el único patrón que simultáneamente reduce friction y aumenta confianza | PIN de 4 dígitos – friction sin señal de seguridad. Contraseña – friction máxima, señal de seguridad media |
| Social login como opción secundaria | Ofrece alternativa de baja friction sin posicionar datos médicos como extensión de cuentas generales | 60% boost en completion con social login (CleverTap), pero en salud usuarios prefieren cuentas dedicadas (patrón validado por plataformas de salud preventiva) | Social login como CTA primario – reduce friction pero debilita la percepción de espacio médico dedicado |
| Foco automático en campo email (primera visita) | Reduce el tiempo a primer input. El usuario no tiene que buscar donde empezar | Cada campo requerido adicional cuesta 3-5% conversión (Dropbox research). Un solo campo con foco automático es el mínimo absoluto de friction | Formulario multi-campo visible desde el inicio – abruma al usuario antes de establecer intención |
| Estado “Sin Código” con redirect a solicitud | Convierte la barrera de acceso en una oportunidad de captura de leads. El usuario no se siente rechazado | Las plataformas de salud con waitlists aumentan perceived value. “ADEN es por invitación. Solicita tu acceso en aden.health” es más positivo que “No puedes registrarte” | Mensaje de error genérico – “Código inválido” sin alternativa cierra la puerta |
| Bloqueo tras 5 intentos con timer visible | Comunica seguridad activa sin frustrar al usuario. El timer de 15 minutos es suficiente para desincentivar ataques sin alienar al usuario real | Ley 1581 de 2012 requiere seguridad proporcional para datos sensibles. Timer visible reduce llamadas a soporte vs bloqueo indefinido | Bloqueo indefinido con “contacta soporte” – castiga al usuario real. CAPTCHA – friction que no comunica protección médica |
| Checkbox de terminos con links a modales | Consentimiento explícito requerido por Ley 1581 (datos sensibles necesitan consentimiento previo e informado). Modal en lugar de página nueva mantiene al usuario en el flujo | Ley 1581 de 2012: consentimiento debe ser explícito, previo e informado para datos de salud. Habeas data es derecho constitucional en Colombia | Terminos aceptados implícitamente al crear cuenta – ilegal para datos sensibles bajo regulación colombiana |
Flujo Emocional
El auth no es un proceso administrativo. Es un arco emocional de cuatro actos.
Acto 1: Curiosidad. María recibe el link de invitación. No sabe exactamente que hace ADEN, pero alguien en quién confía se lo envió. Abre la app. La pantalla de login es limpia, sin ruido. La curiosidad se mantiene porque nada la abruma.
Acto 2: Confianza. Ve el campo de email, el magic link, la biometría. No le piden contraseña. No le piden nombre completo, fecha de nacimiento, y número de cédula en una sola pantalla. Le piden un email. Eso es todo. La confianza se construye por ausencia – la ausencia de friction innecesaria es la señal más fuerte de que este servicio respeta su tiempo.
Acto 3: Compromiso. Ingresa su código de invitación. Crea su cuenta con nombre, email y código. Tres campos. Acepta terminos. La brevedad del formulario comunica: “no te vamos a pedir nada que no necesitemos”. Es un micro-compromiso – suficiente para activar el sesgo de consistencia (Cialdini) sin generar resistencia.
Acto 4: Anticipación. Verifica su email, configura MFA, y llega al Welcome screen. La transición de auth a onboarding no se siente como un cambio de fase – se siente como una continuacion natural. La anticipación se construye porque cada paso fue tan fácil que el siguiente parece igualmente accesible.
Este arco es deliberado. Cada pantalla de auth mueve a María un paso adelante en la escalera de compromiso. Para cuando llega al onboarding, ya invirtio 90 segundos y tres micro-decisiones. El costo hundido trabaja a nuestro favor, pero solo porque cada paso fue placentero, no porque atrapamos al usuario en un funnel.
Conexión con el Engine
María no sabe que existe el engine. No sabe que hay 1,620 cruces clínicos esperandola. No sabe que 19 algoritmos van a procesar sus biomarcadores en menos de 5 milisegundos. Y no debe saberlo todavía.
Pero el modelo invite-only es la primera manifestacion del engine en la experiencia de usuario. El código de invitación no es un mecanismo de growth hacking – es un filtro clínico. ADEN necesita datos reales de laboratorio, historial médico verificable, y compromiso con un protocolo de 90 días. Abrir el registro a cualquier persona generaria ruido: usuarios que descargan, curiosean, y abandonan antes de completar el onboarding. El invite-only asegura que cada usuario que llega al engine tiene intención real.
Esto importa porque el engine está calibrado para población latinoamericana con 30,000+ participantes latinos de cohortes MESA, PURE-LAC y CARMELA. Cada paciente que entra alimenta la precisión del sistema. Un paciente que abandona en el onboarding no es solo un churn – es un dato perdido. El invite-only protege la integridad del pipeline de datos antes de que el usuario sepa que el pipeline existe.
La otra conexión invisible: el magic link y la biometría establecen el canal de autenticación que después protegera los resultados del engine. Cuando María reciba su Health Score de 78, lo vera a través del mismo Face ID que configuró en el auth. La cadena de confianza empieza aquí.
Principio de Referencia: No Pedir Antes de Contextualizar
El patrón establecido por las grandes plataformas de salud es claro: nunca pedir algo antes de que el usuario entienda por qué lo necesitas. Los ecosistemas de salud consolidados no piden acceso a datos de frecuencia cardiaca cuando el usuario abre la app por primera vez. Lo piden cuando conecta un dispositivo y el contexto hace obvia la razón.
ADEN adopta este principio en auth. No pedimos datos médicos durante el registro. No pedimos acceso a plataformas de salud externas durante el login. Solo pedimos email, nombre y código – lo mínimo para establecer identidad. Todo lo demas llega en onboarding, cuando cada petición tiene contexto.
Donde divergimos del patrón estándar es en la prominencia de las señales de seguridad. Las plataformas consolidadas asumen confianza porque el usuario ya tiene un historial con el ecosistema. ADEN no tiene ese capital de confianza heredado. Operamos en Colombia, donde la confianza digital está erosionada por años de experiencias negativas con apps de EPS. Por eso nuestras señales de seguridad (biometría, magic link, invite-only) son explicitas y visibles, no implicitas y asumidas. Las plataformas globales pueden darse el lujo de la sutileza. Nosotros necesitamos la claridad.