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.
Participación de José
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.
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.
Decisiones
Un botón por público en la primera pantalla
El sitio le habla a dos públicos con intenciones opuestas: quien contrata y quien busca empleo.
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.
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.
Que cada visitante se reconociera en un botón y tomara su camino sin leer el resto de la home.
Un menú que nombra a los públicos, no los servicios
Un menú por servicios (staffing, reclutamiento académico) obliga a traducir la oferta antes de encontrar el propio camino.
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.
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.
Que desde cualquier página cada público volviera a su camino en un clic.
Dos tarjetas paralelas, con el sector dentro de cada público
Cada público se divide a su vez en salud y academia; cuatro caminos en la home diluyen la elecció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".
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.
Que el público fuera la decisión y el sector un detalle, con un solo enlace por público.
La misma bifurcación al final de la home, en orden inverso
Quien baja hasta el final sin haber elegido tiene que volver arriba para encontrar su camino.
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".
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.
Que quien terminara de leer tuviera los dos caminos a mano sin volver al hero.
Un solo formulario, con el público como campo
Los dos públicos terminan en contacto, y el equipo necesita saber de qué lado viene cada consulta.
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í.
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.
Consultas que llegaran etiquetadas por público, sin una llamada para averiguarlo.
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.
Hipótesis posterior: qué se podría probar
Propuesta de experimento del relato original. No es una intervención ejecutada ni un resultado obtenido.
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.
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.
Envíos del formulario por sesión que pasa por la página de empleadores, medidos en GA4.
Porcentaje de consultas con el público mal asignado, según la revisión del equipo.
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.
