01 — Contexto
Compu-Med Vocational Careers (CMVC) es una escuela de formación en salud para público hispano en Estados Unidos, con campus en Florida y Texas y una oferta de diez programas, desde asistente dental hasta enfermería.
El sitio tenía que ordenar programas, campus, servicios estudiantiles y mensajes institucionales sin volverse pesado, y que la versión móvil no diluyera la propuesta. Diseñé la experiencia UX/UI y desarrollé el sitio en WordPress y Elementor, formularios incluidos.
02 — Mi rol
Definí la arquitectura de información, diseñé los patrones de bloques de programa, formularios y llamadas a inscripción, y los implementé en WordPress. Instrumenté GA4 y revisé mapas de calor en Clarity. Trabajé en el proyecto a través de Aquinas Network SAS. El copy y las fotos los aportó el cliente.
03 — Diagnóstico
Pocas acciones concretas entre mucha información
Era un sitio nuevo, sin una versión anterior que corregir, así que el problema estaba en el encargo y en cómo plantear el sitio. Al mismo sitio llegan dos públicos: quien está eligiendo programa y campus, y quien ya estudia. Mi lectura fue que los dos vienen con unas pocas acciones concretas en mente (aplicar, hablar con un asesor, pedir una transcripción) y que, en un único menú largo, esas acciones quedarían enterradas entre las páginas institucionales.
Plantearlo mal le dolería a los dos lados. Al futuro estudiante, que probablemente llega desde el móvil y no debería recorrer demasiado para pedir información. Y a admisiones, que necesitaba saber a qué campus y a qué programa correspondía cada consulta.
04 — Decisiones
A. Pedir información sin salir de la home
- Problema
- Quien llega ya decidido no debería tener que buscar una página de contacto para dejar sus datos.
- Decisión
- Un formulario de cinco campos en la primera pantalla, junto a la promesa y a los botones "Inscríbete ahora!" y "Examen". El patrón se repite en la plantilla de landing de campaña.
- Por qué esa
- Valoré mandar todo el tráfico a una página de admisión aparte; preferí el formulario en la home porque quien ya decidió deja sus datos sin salir de la primera pantalla. El coste: un hero más cargado, donde el formulario compite con el mensaje.
- Qué esperaba
- Capturar la consulta de quien ya decidió en el primer scroll, sin perderlo en la navegación.
B. Acciones directas arriba, información institucional debajo
- Problema
- Prospectos y estudiantes llegan con acciones concretas en mente, y en un único menú esas acciones se perderían entre las páginas de la escuela.
- Decisión
- Una barra superior con las acciones directas de los dos públicos: Aplicar Ahora, Exámenes de admisión, Hablar con un asesor y el botón "Solicitar asesoría" para el prospecto; Marketplace, Solicitar transcripciones y Estudiantes, el acceso a Canvas, para quien ya estudia. Debajo, el menú institucional: Sobre CMVC, Campus, Servicios estudiantiles, Ayuda financiera, Admisión y Blog. En móvil, cuatro de esas acciones pasan a botones al pie del panel.
- Por qué esa
- Valoré un único menú con todo; preferí separar por tipo de tarea, hacer algo ahora o informarse, porque quien viene a aplicar o a pedir una transcripción no necesita recorrer las páginas institucionales. El coste: el header ocupa dos barras y resta altura a la primera pantalla, y en la barra superior conviven acciones de dos públicos.
- Qué esperaba
- Que prospectos y estudiantes encontraran su acción en un clic, sin recorrer la oferta, y que el menú institucional quedara corto.
C. Un índice de programas donde todos pesan igual
- Problema
- Con diez programas, destacar unos pocos escondería al resto, y una lista con descripciones se haría larga.
- Decisión
- Una grilla de tarjetas iguales con icono y nombre, que en móvil mantiene dos columnas; cada tarjeta lleva a la página de su programa.
- Por qué esa
- Valoré un carrusel y una lista con descripciones; preferí la grilla porque se lee de un vistazo y ningún programa queda detrás de un gesto. El coste: la home pierde el detalle de cada programa, que vive en su página.
- Qué esperaba
- Que cada visitante encontrara su programa en la home y llegara a la página de ese programa en un clic.
D. Campus y programa antes que los datos personales
- Problema
- Con varios campus, una consulta sin campus ni programa obligaría a admisiones a averiguarlo en la primera llamada.
- Decisión
- El formulario de admisión abre con dos selectores, campus y programa, y después pide nombre, teléfono, código postal y correo. Se reutiliza en contacto.
- Por qué esa
- Valoré un formulario por pasos; preferí una sola pantalla que empieza por una elección, porque con seis campos los pasos no compensaban y elegir campus y programa baja la barrera del primer campo. El coste: los seis campos se ven de golpe, y el formulario parece más largo que uno por pasos.
- Qué esperaba
- Consultas que llegaran ya asignadas al campus y al programa correctos.
05 — Sistema
Quedó un header de dos niveles (Fig. 1), cuyas acciones directas pasan en móvil a botones al pie del menú, un índice de programas en tarjetas (Fig. 2), una plantilla de landing de campaña con formulario en la primera pantalla (Fig. 3) y un formulario de admisión con campus y programa que se reutiliza en admisión y contacto (Fig. 4).
El alcance cerró en entrega e instrumentación, no en reporting de impacto, así que este caso no reporta cifras.
06 — Qué probaría ahora
El formulario de la home pide nombre y teléfono, pero no campus ni programa, a diferencia del de admisión (Fig. 0 frente a Fig. 4). Probaría a darle a la home la misma primera fila.
- Hipótesis
- Si el formulario de la home empieza por campus y programa, la tasa de envío no baja y más consultas llegan listas para que admisiones las atienda.
- Métrica primaria
- Envíos del formulario por sesión que entra por la home, en GA4.
- Secundaria
- Porcentaje de consultas que admisiones contacta en el primer intento, medido en su CRM.
- Control
- El formulario actual de la home. Reparto 50/50 hasta el tamaño de muestra calculado sobre la línea base, con la tasa de envío como métrica de guarda: si cae, se descarta la variante.