Keralty · 2023–2024 · Sitio web y portal de pagos
Dental Clinics
Un pago que te mandaba de vuelta al inicio se convirtió en un flujo guiado que el 91% de los pacientes completó sin ayuda.
- 58% →91% completó el pago sin ayuda (pruebas en Maze)
- −45% tiempo para pagar un tratamiento
- 24 pacientes en 3 pruebas: pago, tratamientos y versiones
- 2 datos para encontrar tus tratamientos
- Producto
- Sitio web y portal de pagos
- Industria
- Salud
- Rol
- Product Designer
- Duración
- 3 meses
- Equipo
- Producto, negocio e ingeniería
- Alcance
- Benchmark, pruebas en Maze, UI, prototipado
Rediseñé el sitio y el portal de pagos de las Clínicas Dentales Keralty: de un sitio institucional y un pago que obligaba a empezar de cero, a una experiencia guiada que genera confianza.
El problema
Pagar era un ejercicio de memoria
Un error en el pago te mandaba de vuelta al inicio. Y tenías que recordar de memoria qué tratamiento pagar.
Antes
- Un sitio informativo, poco persuasivo
- Flujo de pago sin jerarquía ni guía
- Errores que obligaban a reiniciar todo
- Llamados a la acción débiles
Después
- Promociones, tratamientos y experiencia en primer plano
- Pasos claros: paciente → pago → pagador → confirmación
- Prevención y recuperación de errores
- “Agenda tu cita” siempre a la mano
El contexto
Un sitio pensado como folleto y un pago pensado como trámite
Las Clínicas Dentales Keralty atienden a miles de pacientes con tratamientos que se pagan por partes: ortodoncia, implantes, rehabilitación. El sitio era la puerta de entrada para agendar y pagar, pero se pensó como un folleto institucional, y el pago en línea como un trámite.
Las restricciones
Trabajé con producto, negocio e ingeniería en un proyecto de 3 meses: diez días de benchmark y heurística, dos semanas de diseño y prototipo, y el resto en pruebas, ajustes y entrega.
- Una pasarela de pagos existente que no se podía reemplazar.
- Quien paga no siempre es el paciente: padres, parejas, empresas.
- Tratamientos con abonos parciales y saldos pendientes.
- Una librería de marca sólida que había que respetar.
Investigación
Evidencia antes que opiniones
-
01
Heurística
Evaluación del sitio y del pago: navegación confusa, sin jerarquía ni prevención de errores.
-
02
Benchmark
Plataformas de salud y odontología nacionales e internacionales.
-
03
Wireframes
Recorrido reestructurado: menos pasos, más jerarquía y prevención de errores.
-
04
Pruebas en Maze
Tres pruebas no moderadas: pago, selección de tratamientos y versión anterior frente a la nueva.
Lo que encontramos
-
01
El sitio era más informativo que persuasivo y atraía pocos pacientes nuevos.
-
02
La navegación no respondía a lo que esperaban los pacientes.
-
03
El pago obligaba a reiniciar cuando había un error.
-
04
La competencia ofrecía experiencias más claras y atractivas.
-
05
Llamados a la acción débiles reducían citas y pagos.
El hallazgo que cambió el flujo
“No sé cómo se llama mi tratamiento. Solo sé que es el de los brackets.”
Por eso: el pago no podía depender de la memoria del paciente. Decidimos que la plataforma buscara los tratamientos a partir del documento.
Decisiones clave
Nada que recordar y nada que perder
Buscar con el documento, no con la memoria
- Problema
- Para pagar había que escribir el nombre del tratamiento y la clínica, y casi nadie los recordaba.
- Hallazgo
- Los pacientes reconocen su tratamiento cuando lo ven, pero no lo recuerdan cuando lo tienen que escribir.
- Decisión
- Con tipo y número de documento, la plataforma muestra los tratamientos pendientes o que admiten abonos.
- Por qué
- Reconocer es más fácil que recordar: pasamos de varios campos de memoria a 2 datos que todos tienen a mano.
Diseñar para cuando algo falla
- Problema
- Cualquier error en el pago mandaba al paciente de vuelta al inicio.
- Hallazgo
- Los errores más comunes no eran del paciente: la pasarela caída, respuestas lentas o datos que no se encontraban.
- Decisión
- Mapear cada caso alterno y de error con ingeniería, y darle a cada uno un mensaje y una salida sin perder lo ya ingresado.
- Por qué
- En un pago, la confianza se gana o se pierde cuando algo sale mal.
Los casos que diseñamos
-
01
Campos omitidos
Se señala el dato faltante sin borrar el resto.
-
02
Otro pagador
Quien paga puede ser distinto del paciente.
-
03
Cambio de opción
Volver atrás para elegir otro tratamiento sin empezar de cero.
-
04
Pago pendiente
Si hay un pago en proceso, se avisa antes de cobrar dos veces.
-
05
Servicio caído
Un mensaje claro y la opción de intentar más tarde.
-
06
Respuesta lenta
Estado de carga visible para que nadie pague dos veces.
-
07
Datos no encontrados
Qué revisar y cómo contactar a la clínica.
-
08
Transacción cancelada
Se retoma el pago con los datos ya ingresados.
Diseñar la experiencia
Un sitio que vende y un pago que acompaña
-
01
Un home que convence
Del tono institucional a uno centrado en el paciente: promociones, tratamientos, años de experiencia y el pago en línea a la vista.
-
02
Servicios que invitan a agendar
Estructura clara, beneficios concretos, buenas imágenes y “Agenda tu cita” a lo largo de la página.
-
03
Nada que recordar
Con el tipo y número de documento, la plataforma trae los tratamientos pendientes de pago o que admiten abonos. Paciente, tratamiento, clínica y valor se confirman antes de pedir los datos del pagador.
La marca, aplicada con sistema
Keralty tiene una librería de marca sólida que sus productos digitales no aplicaban de forma consistente. El rediseño la usó de manera sistemática: colores, tipografía y componentes al servicio de la confianza.
Tipografía
- H1 Título de ejemplo 48px · móvil 32px
- H2 Título de ejemplo 40px · móvil 28px
- H3 Título de ejemplo 32px · móvil 26px
- H4 Título de ejemplo 28px · móvil 24px
- H5 Título de ejemplo 24px · móvil 20px
- Body Título de ejemplo 16px · móvil 14px
Color
- Principal · 5.39:1
#0071A3 - Secundario · 4.5:1
#008767 - Secundario · 11.95:1
#002F87 - Texto
#212121
Degradados
- Azul verde
#389EE1 → #2DB789 - Azul
#0071CE → #60BEF0 - Verde
#008767 → #57DBA2
Validación
Tres pruebas en Maze con 24 pacientes
Probé el flujo en Maze con 24 pacientes, en tres pruebas no moderadas. Medí cuántos completaban cada tarea sin ayuda, cuánto tardaban y dónde hacían clic por error. Después de cada prueba ajusté el diseño.
- Prueba 1, el pago completo: muchos no veían la opción de abonar. La hicimos explícita junto al valor total.
- Prueba 2, la selección de tratamientos: los nombres técnicos confundían. Agregamos la clínica y la fecha de inicio para reconocerlos.
- Prueba 3, versión anterior frente a la nueva: 58% frente a 91% de pagos completados sin ayuda.
El resultado
Más pagos completados, en menos tiempo
-
58% →91%
completó el pago sin ayuda.
Cómo se midió: tasa de éxito de la misma tarea en Maze, versión anterior frente a la nueva.
-
−45%
tiempo para pagar un tratamiento.
Cómo se midió: mediana del tiempo en la tarea en Maze, versión anterior frente a la nueva.
-
2
datos para encontrar los tratamientos pendientes.
Cómo se midió: campos necesarios en el flujo nuevo frente al anterior, que pedía nombre del tratamiento, clínica y código.
-
8
casos alternos y de error con una salida clara.
Cómo se midió: casos de uso documentados con ingeniería y cubiertos en el prototipo.
De una plataforma institucional y cargada de información a una experiencia moderna y centrada en el paciente, que facilita agendar y pagar en línea.
Reflexión
Lo que me llevo de este proyecto
Lo que aprendí
Las pruebas no moderadas en Maze me dieron muchas respuestas en pocos días, pero los porqués llegaron de los comentarios abiertos. Formular bien las preguntas fue tan importante como diseñar las pantallas.
Lo que haría distinto
Haría una ronda moderada con pacientes mayores. Es el grupo que más paga tratamientos largos y el que menos aparece en las pruebas en línea.