01 — Contexto
HireHealth es una agencia de reclutamiento de Coral Gables, Florida, especializada en salud y academia. Trabaja con dos públicos a la vez: instituciones que necesitan contratar y profesionales que buscan empleo.
El encargo era que un mismo sitio le hablara con la misma precisión a quien contrata y a quien busca empleo, sin partir la marca en dos ni perder confianza, y que cada público encontrara su siguiente paso sin rodeos. Diseñé la experiencia UX/UI y desarrollé el sitio en WordPress y Elementor.
02 — Mi rol
Trabajé en el proyecto a través de Aquinas Network SAS. Definí la arquitectura de información por público y el orden de la home, y diseñé e implementé la home y la página de contacto. Instrumenté GA4 y revisé mapas de calor en Clarity. El copy y las fotos los aportó el cliente.
03 — Diagnóstico
Dos públicos con intenciones opuestas en la misma puerta
Era un sitio nuevo, sin una versión anterior que corregir: el riesgo estaba en el encargo, en acabar con un sitio que le hablara a todos y a nadie. Mi lectura de la causa: quien contrata y quien busca empleo llegan con preguntas opuestas (¿me consiguen personal?, ¿tienen una vacante para mí?), y cada público se divide a su vez en salud y academia. Si la home no separa esos caminos pronto, cada visitante tiene que leer mensajes que no son para él antes de encontrar el suyo.
Le cuesta a los dos públicos: a quien dirige una clínica o una escuela, que probablemente decide en pocos segundos si la agencia entiende su sector, y al profesional, que busca vacantes y no un discurso comercial. Y le cuesta a HireHealth, que recibe consultas sin saber de qué lado vienen.
04 — Decisiones
A. Un botón por público en la primera pantalla
- Problema
- El sitio le habla a dos públicos con intenciones opuestas: quien contrata y quien busca empleo.
- Decisión
- El titular une talento y oportunidad, y el hero ofrece dos botones, uno por público: "Find the Best Talent", relleno, lleva a la página de empleadores, y "Explore Career Opportunities", en blanco, a la de candidatos.
- Por qué esa
- Valoré una pantalla previa para elegir perfil ("Soy empleador" o "Busco empleo"); preferí dos botones en el hero porque esa pantalla añadía un paso antes de ver la propuesta. El coste: un público pesa más que el otro, porque el botón relleno es el de empleadores.
- Qué esperaba
- Que cada visitante se reconociera en un botón y tomara su camino sin leer el resto de la home.
B. Un menú que nombra a los públicos, no los servicios
- Problema
- Un menú por servicios (staffing, reclutamiento académico) obliga a traducir la oferta antes de encontrar el propio camino.
- Decisión
- Cinco entradas: Home, About, Job Seeker, Employer y Contact Us, con las redes aparte. En móvil, las mismas cinco en un panel desplegable; en los dos casos el header queda fijo al hacer scroll.
- Por qué esa
- Valoré un menú por servicios; preferí nombrar a quién se dirige cada página porque el visitante sabe quién es antes de saber qué necesita. El coste: el menú no dice qué se le ofrece a cada público hasta que entra.
- Qué esperaba
- Que desde cualquier página cada público volviera a su camino en un clic.
C. Dos tarjetas paralelas, con el sector dentro de cada público
- Problema
- Cada público se divide a su vez en salud y academia; cuatro caminos en la home diluyen la elección.
- Decisión
- Un bloque con dos tarjetas del mismo peso, Employers y Job Seekers. Cada una separa salud y academia en dos párrafos y termina en un solo enlace: "Hire your next team member with us" o "Search for your next job".
- Por qué esa
- Valoré cuatro tarjetas, una por público y sector, y también pestañas por público; preferí dos tarjetas paralelas porque las primeras multiplicaban la elección y las segundas escondían a un público detrás de un clic. El coste: texto largo en cada tarjeta, que en móvil se apila en dos bloques altos.
- Qué esperaba
- Que el público fuera la decisión y el sector un detalle, con un solo enlace por público.
D. La misma bifurcación al final de la home, en orden inverso
- Problema
- Quien baja hasta el final sin haber elegido tiene que volver arriba para encontrar su camino.
- Decisión
- Antes del blog, un bloque repite los dos caminos como tarjetas con foto: primero "Job seekers", con "Explore job opportunities", y después "Employers", con "Discover staffing solutions".
- Por qué esa
- Valoré cerrar con un contacto genérico; preferí repetir la elección con el orden invertido porque así quien busca empleo, segundo en el hero, pasaba a ser el primero. El coste: la redundancia de presentar dos veces la misma elección en la home.
- Qué esperaba
- Que quien terminara de leer tuviera los dos caminos a mano sin volver al hero.
E. Un solo formulario, con el público como campo
- Problema
- Los dos públicos terminan en contacto, y el equipo necesita saber de qué lado viene cada consulta.
- Decisión
- La página de contacto pide nombre, teléfono, email, código postal y cargo, y un selector "Solution Of Interest" con dos opciones, Employer o Candidate. Al lado, teléfono, email y oficina de la empresa. Los tres botones de la página de empleadores llevan aquí.
- Por qué esa
- Valoré un formulario por público; preferí uno solo, con el público como campo, porque bastaba para etiquetar cada consulta sin duplicar páginas. El coste: los dos públicos responden las mismas preguntas, "Job Title" significa algo distinto para cada uno y el público se elige al final.
- Qué esperaba
- Consultas que llegaran etiquetadas por público, sin una llamada para averiguarlo.
05 — Sistema
Quedó una home ordenada por público: un hero con un botón para cada uno (Fig. 0), un menú que los nombra y queda fijo en desktop y en móvil (Fig. 1), un bloque de tarjetas paralelas (Fig. 2), una segunda bifurcación antes del blog (Fig. 3) y un formulario de contacto común, con el público como campo (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
Hoy los dos públicos terminan en el mismo formulario, y el público se elige en el último campo, con una etiqueta de producto: "Solution Of Interest" (Fig. 4). Probaría a que quien llega desde la página de empleadores encuentre esa elección ya hecha.
- Hipótesis
- Si los botones de la página de empleadores abren el formulario con "Employer" ya seleccionado, y el selector pregunta en lenguaje llano si la persona quiere contratar o busca empleo, suben los envíos de quienes llegan desde esa página y menos consultas llegan con el público equivocado.
- Métrica primaria
- Envíos del formulario por sesión que pasa por la página de empleadores, medidos en GA4.
- Secundaria
- Porcentaje de consultas con el público mal asignado, según la revisión del equipo.
- Control
- El formulario actual, con el selector vacío al final. Reparto 50/50 hasta el tamaño de muestra calculado sobre la línea base de GA4, no hasta una fecha.