Buscador AFP Modelo
Una experiencia de búsqueda guiada, medible y conectada al contenido del sitio público. Diseñé e implementé un buscador interno para facilitar el acceso a información previsional, reducir la frustración de los usuarios y permitir el seguimiento de las consultas más frecuentes. El proyecto abarcó investigación, benchmark, arquitectura de información, diseño UX/UI, pruebas de usabilidad, desarrollo front-end e integración con Strapi.
Proceso
Snapshot
El proyecto en breve
Rol
UX Research · Product Design · UI Design · Front-end
Stack
Vue.js · Ant Design Vue · Strapi · Figma · Maze
Usuarios
Afiliados, pensionados, empleadores y visitantes del sitio público
Objetivo
Facilitar la búsqueda de contenidos y reducir los comentarios relacionados con información difícil de encontrar.
Contexto y problema
Un sitio con información, pero sin una forma clara de encontrarla
El sitio público no contaba con un buscador funcional. Una solución anterior había sido eliminada por sus costos de mantenimiento, mientras los comentarios de satisfacción seguían mostrando dificultades para localizar información.
El desafío no era únicamente incorporar un campo de búsqueda. Era construir una solución útil, económica y administrable que permitiera guiar a distintos tipos de usuarios dentro de un ecosistema de contenidos amplio.
Objetivos
Qué necesitábamos resolver
El proyecto buscaba:
- facilitar el acceso a información de manera intuitiva;
- reducir la sensación de desorientación;
- ofrecer resultados relevantes desde los primeros lugares;
- guiar la exploración mediante categorías;
- registrar qué buscan los usuarios;
- evitar una solución externa de alto costo.
Investigación
Analizando patrones de búsqueda dentro y fuera del sector
La investigación combinó tres fuentes:
- benchmark de AFP;
- referentes funcionales del sector bancario;
- estudios sobre comportamiento en motores de búsqueda.
La competencia previsional ofrecía experiencias básicas, generalmente sin autocompletado, categorización o resultados instantáneos. En cambio, algunos bancos incorporaban patrones más cercanos a las expectativas creadas por Google: sugerencias, jerarquía y navegación guiada.
| AFP | Banca |
|---|---|
| Resultados extensos | Resultados guiados |
| Poca jerarquía | Sugerencias |
| Sin categorías | Categorización |
| Navegación separada | Respuesta inmediata |
Hallazgos
Los primeros resultados determinan la experiencia
La investigación confirmó cuatro principios:
- Los usuarios concentran su atención en los primeros resultados.
- Una cantidad excesiva de opciones aumenta la carga cognitiva.
- Las sugerencias ayudan a formular búsquedas.
- Las categorías permiten explorar incluso sin una consulta precisa.
Estos hallazgos definieron una experiencia centrada en resultados acotados, recomendaciones y navegación por categorías.
De los hallazgos a los principios de diseño
Exploración de soluciones
Probando distintas formas de presentar los resultados
Se evaluaron tres alternativas:
Listado extendido
Fue descartado porque generaba demasiado scroll y sobrecarga visual.
Página separada
Permitía más contenido, pero agregaba pasos y sacaba al usuario de su contexto.
Modal contextual
Concentraba la atención, permitía mostrar resultados instantáneos y mantenía al usuario en la página actual.
La tercera alternativa se convirtió en la base de la solución final.
Diseño de la experiencia
Una búsqueda visible, guiada y adaptable
La solución final incorporó:
- acceso visible desde el encabezado;
- resultados en tiempo real;
- límite de cinco resultados principales;
- sección de categorías;
- términos destacados en negrita;
- comportamiento adaptado a escritorio y móvil;
- estado vacío y mensajes ante falta de resultados.
En móvil, las categorías se ocultan al escribir para priorizar el espacio disponible y reaparecen cuando se limpia la consulta.
Pruebas de usabilidad
Validando visibilidad, comprensión y utilidad
Las pruebas evaluaron tres preguntas principales:
- ¿El usuario encuentra el buscador?
- ¿Comprende cómo interactuar con él?
- ¿Las categorías y resultados le parecen útiles?
La propuesta obtuvo evaluaciones altas en facilidad, claridad y utilidad. También reveló un problema concreto: el ícono de búsqueda tenía poca visibilidad, especialmente en escritorio.
Resultados del test: desktop móviles
Simulación de búsqueda
Calificación del flujo de parte de los participante
Hallazgo → Iteración
| Hallazgo | Cambio aplicado |
|---|---|
| El ícono de búsqueda pasaba inadvertido | Se transformó en un botón más visible |
| Algunos usuarios exploraban elementos ajenos a la tarea | Se reforzó la jerarquía visual |
| El contenido era bien entendido | Se mantuvieron categorías y estructura |
| Existía preocupación por el orden de resultados | Se definió una priorización basada en TNPS |
Priorización de resultados
Ordenando el contenido según relevancia para los usuarios
Strapi entregaba los resultados respetando el orden manual del contenido. Para aprovechar esta limitación, se construyó un sistema de puntuación que permitió priorizar cada enlace de acuerdo con su relevancia.
La evaluación consideró:
- tipo de contenido;
- categoría;
- peso de comentarios relacionados en TNPS;
- relevancia individual del enlace.
Así, los primeros resultados respondían a necesidades reales y no solo a coincidencias textuales.
Arquitectura de contenido
Adaptando Strapi a una necesidad nueva
Debido a que el CMS estaba en proceso de actualización, se reutilizó estratégicamente un nodo existente.
Cada registro utilizó:
- Título: nombre visible del resultado.
- URL: enlace de destino.
- Descripción: palabras clave, sinónimos y errores frecuentes.
- Tag: categoría del resultado.
Esta estructura permitió crear sugerencias, categorías y coincidencias sin contratar un motor externo.
Implementación front-end
Traduciendo las decisiones a código
El buscador se implementó en Vue.js utilizando Ant Design Vue e integración con Strapi.
Las funciones principales fueron:
- limitar la respuesta a cinco resultados;
- destacar coincidencias desde tres caracteres;
- agrupar resultados mediante tags;
- mostrar estados vacíos;
- registrar clics y consultas.
Resultados limitados:
const limitedResults = arrayResults.slice(0, 5)
if (limitedResults.length === 0) {
this.notData = true
} else {
this.listVideoTutorials = limitedResults
this.notData = false
}Menú categorías:
computed: {
filteredVideos() {
return this.sectionsVideos.filter((section) => {
return section.videos.some(
(video) => video.video_id === this.selectedVideoId
)
})
},
},Impacto real
Menos usuarios reportaron dificultades para encontrar información
Para evaluar el resultado, se compararon comentarios TNPS relacionados con búsquedas antes y después del lanzamiento.
- 101 comentarios antes del lanzamiento
- 50 comentarios en la primera medición posterior
- 19 comentarios en la medición tardía
La disminución fue sostenida y sugiere que el buscador logró mitigar uno de los principales puntos de dolor del sitio público.
Comentarios relacionados a búsqueda:
Medición y mejora continua
El buscador también generó una nueva fuente de información
Además de facilitar la navegación, el buscador permitió registrar qué contenidos consultaban los usuarios y qué resultados seleccionaban.
Estos datos abrieron nuevas oportunidades para:
- mejorar las palabras clave;
- actualizar la priorización;
- detectar contenidos difíciles de encontrar;
- fortalecer la arquitectura de información;
- adaptar accesos rápidos a necesidades reales.
Esto representó una reducción sostenida del principal pain point histórico del sitio.
Stakeholders
Diseñar una solución viable para el negocio
La iniciativa enfrentó resistencia inicial por experiencias anteriores con buscadores externos de alto costo y por la preocupación asociada a su mantenimiento.
La propuesta demostró que era posible construir una solución propia, integrada al CMS y sin costos adicionales por consulta.
El lanzamiento y su continuidad sin nuevas fricciones consolidaron la herramienta como una funcionalidad estable del sitio.
| Riesgo inicial | Respuesta |
|---|---|
| Costos por consulta | Solución propia |
| Dependencia externa | Integración con Strapi |
| Alto mantenimiento | Administración desde CMS |
| Dudas de impacto | Seguimiento con TNPS |
Aprendizajes
Diseñar búsqueda es diseñar contenido
Este proyecto reforzó que la calidad de un buscador no depende únicamente de su interfaz o de su algoritmo.
También depende de:
- cómo se estructura el contenido;
- cómo se escriben títulos y palabras clave;
- cómo se priorizan los resultados;
- cómo se mide el comportamiento posterior.
El mayor aprendizaje fue conectar investigación, arquitectura de información, desarrollo y medición dentro de una misma solución.