Yirewa
2026 · 9 min de lectura
Barreras invisibles
Yirewa es una ONG zamorana con proyectos de cooperación al desarrollo en Sierra Leona. Al auditar su web, encontré barreras de accesibilidad, fricciones de usabilidad y un rendimiento crítico en móvil: problemas que no siempre son evidentes, hasta que impiden donar, colaborar o involucrarse.
UX research
Accesibilidad
WordPress
Contexto
Yirewa es una asociación sin ánimo de lucro de utilidad pública, con proyectos activos en agricultura, educación, sanidad y acceso al agua potable en Mabongisseh, Sierra Leona, y sus alrededores. Su web, construida en WordPress con Elementor, era el principal canal para captar socios, donantes y voluntarios
Desde Yirewa, me comentaron que tenían estos problemas:
•
La web iba lenta, especialmente en móvil
•
Los correos del formulario de socios no llegaban
•
Los datos de "cuentas claras" estaban repartidos en varias secciones sin unificar.
La web llevaba tiempo sin actualizarse, así que decidí auditarla para hallar las causas y problemas por detectar
De la auditoría, los datos más relevantes fueron estos:
•
Accesibilidad (WAVE): ratio de contraste de 1.98:1, muy por debajo del mínimo de 4.5:1 exigido por el nivel AA, sobre todo en botones CTA y footer. También faltaban encabezados H1 y alt text en las imágenes
•
Usabilidad (heurísticas de Nielsen): fricciones en los dos flujos de conversión más sensibles:
◦
En la página "hazte socio": un formulario con más campos de los necesarios para asociarse, con feedback de error pero fuera del viewport y con botones de envío activos en hover aunque faltaran campos obligatorios.
◦
En la página "haz una donación": una imagen con instrucciones para donar por Bizum que parecía un formulario pero no era interactiva
Rediseño
Contraste
Para resolver el problema de contraste detectado en la auditoría, amplié la paleta a partir de los colores identitarios:
•
Del verde #6EBA6D extraje una versión clara, el #B8E6BE, y una versión oscura, el #203826
•
Del naranja #DC812A extraje una versión clara, el #E6CEB8, y una versión oscura, el #382C20
Navegación: menú y footer
•
Menú: en móvil se mostraban todos los submenús desplegados a la vez, resultando abrumador. Lo rediseñé para que colapsen por defecto y solo se abra el submenú que la persona esté explorando
•
Footer: la información legal e institucional estaba repartida en dos columnas sin relación aparente, dificultando encontrar los datos de contacto o los avisos legales. Los reorganicé en una estructura de bloques.
Tono y contenido: ni lástima ni heroísmo
Antes de ajustar textos e imágenes, definí tres líneas rojas que no quería reproducir:
•
Pornografía de la pobreza: cualquier recurso que explote la precariedad de las personas para generar más donaciones o alcance
•
Fatiga del donante: desgaste que sienten los donantes al saturarse de información o percibir que sus aportaciones no generan cambios reales, lo que acaba reduciendo o frenando su implicación
•
Complejo de salvador blanco: narrativa condescendiente en la que una persona blanca de un país desarrollado trata de ayudar a comunidades marginadas, con frecuencia buscando validación social al obtener una imagen de altruismo. Se da por herencia colonial y por una comprensión superficial de las causas estructurales de la pobreza
Formulario de socio
El formulario de "Hazte socio" pedía 19 campos, generando fricción evidente en el punto de conversión más sensible de toda la web. La propia asociación me indicó qué datos eran realmente imprescindibles para dar de alta a un socio y qué método de pago era preferible: la domiciliación bancaria frente a la emisión de recibos, ya que la segunda requiere que los futuros socios faciliten su IBAN y solían ser reticentes a ello. Con esa información, reduje el formulario a los nueve campos imprescindibles, dando el IBAN de la asociación en el email generado tras enviar el formulario.
Lo implementé con Contact Form 7 y CSS personalizado para unificar su apariencia de foco y error con el formulario de contacto y maqueté también los mails que este formulario envía tanto a la asociación como al usuario
Donaciones
Las tres vías (Bizum, transferencia bancaria y PayPal) ya estaban en la página, pero las dos últimas apenas eran perceptibles: se camuflaban en texto corrido con hipervínculos, y la de Bizum ni siquiera era texto, sino una imagen sin interactividad, tal y como detectó la auditoría. Convertí las tres en tarjetas de donación con Elementor, cada una con su propia llamada a la acción, para que su affordance se percibiera.
Cuentas claras
La propia asociación había señalado que los datos de "cuentas claras" estaban repartidos en varias secciones sin unificar, y en efecto encontré la información de transparencia dividida entre páginas duplicadas y unos PDFs sueltos sin relación aparente entre sí. Fusioné las páginas duplicadas y sustituí los PDFs por un widget de visualización de datos interactivo: se puede consultar la información financiera de un vistazo, sin descargar nada ni buscar en varias secciones, además de filtrar por año o ver las cifras históricas acumuladas.
Rendimiento
Gran parte de la mejora vino del propio rediseño, sumada a la optimización de imágenes, tiempos óptimos de caché y la desinstalación de plugins en desuso.
Queda pendiente una limpieza de CSS y JS que debería seguir bajando los tiempos de carga
Otras mejoras técnicas
Correo institucional
Mientras verificaba que el formulario de socios funcionaba, comprobé que los envíos llegaban con normalidad a través del webmail. La causa real de por qué Yirewa afirmaba que los correos de este formulario no llegaban apareció más adelante: en la asociación intentaban acceder a ese correo desde Outlook, no desde el webmail de Webempresa, su hosting y, al no tener esa cuenta configurada en Outlook, no podían acceder. Como solución rápida, empecé redirigiendo el correo institucional a una cuenta de Outlook de uso frecuente, pero acabé sustituyendo esa redirección por la configuración de la propia cuenta como IMAP en Outlook, es decir, sincronizando Outlook directamente con el servidor de Webempresa
Newsletter
En esta misma fase de verificación detecté que el formulario de newsletter no funcionaba: solo guardaba el email en una lista de contactos de Flamingo, sin enviar correo alguno ni activar ninguna suscripción. Para solucionarlo, diseñé dos automatizaciones con Make conectadas a la API de Brevo:
•
Una, envía el email de bienvenida: un webhook recibe el aviso de que hay un nuevo suscriptor, consulta el feed RSS del blog y llama a la API de Brevo, lo que activa en Brevo el envío del correo al recién suscrito dándole la bienvenida y mostrándole las tres últimas entradas de blog.
•
Otra, genera el resumen semanal: recupera las entradas publicadas en los últimos siete días del feed RSS, las une en un bloque HTML y llama dos veces a la API de Brevo. La primera, para crear la campaña de email insertando ese bloque dentro de una plantilla ya maquetada; la segunda, para disparar su envío a la lista de suscriptores
Conclusiones
El proyecto cubrió el ciclo completo de un proyecto de rediseño, de la auditoría a una implementación que sigue en producción, y resolvió casi todos sus hallazgos: solo quedan pendientes un FAQ para donantes y un buscador en el menú.
Empecé sin conocer el alcance real del proyecto, más allá de los problemas que la propia asociación había señalado; precisamente por no tener ese plan cerrado de antemano, la auditoría se convirtió en la herramienta que me permitió dimensionar el trabajo y defenderlo con datos.
Pero no todo se ve en una auditoría: el problema de los formularios lo descubrí en fase de testeo, al comprobar que las respuestas no llegaban a la asociación. De nada sirve rediseñar un formulario si quien debe responder no puede leer el mensaje: entender dónde se rompe el flujo de información fue tan importante como el rediseño visual.
El siguiente paso ya está en marcha: implementé Site Kit by Google con Google Analytics en la web para validar los cambios con datos reales de uso en lugar de estimaciones de terceros como Similarweb. Con esos datos, iteraré sobre el diseño actual