Ministerio de Desarrollo Social y Familia

Definición de la experiencia de una plataforma de datos abiertos para reunir, en un solo portal, la información que generaban distintas áreas del ministerio.

Vía

Babel Group

Rol

Senior Product Designer · Research y arquitectura de información

Estado

Producción

Lo más relevante

Este portal no es un sitio informativo más: es la fuente desde donde se toman decisiones de política social a nivel país. Que la información fuera encontrable de verdad no era un detalle de usabilidad — era una condición para que esas decisiones se tomaran bien informadas.

El portal centraliza la información que hoy se usa para tomar decisiones de política social a nivel país.
La mayoría de los usuarios encontró lo que buscaba en la segunda ronda de tests, después de ajustar la arquitectura con los hallazgos de la primera.
La arquitectura de información (definida con card sorting y validada con usuarios) sigue en producción hoy, incluso después de un cambio de design system a mitad de proyecto.

Resumen ejecutivo

Participé en la definición de experiencia de una plataforma de datos abiertos que debía reunir, en un solo portal, datos generados por distintas áreas del ministerio. Trabajé junto a una UX a cargo, partiendo de los arquetipos de usuario que el ministerio ya tenía, y combinando research, validación con usuarios y arquitectura de información implementable.

Contexto y qué estaba en juego

El Ministerio de Desarrollo Social y Familia generaba información pública en distintas áreas, pero dispersa, sin un lugar único donde encontrarla. Por eso se decidió construir una plataforma de datos abiertos que reuniera todo en un solo portal. Este portal es la fuente desde la que se toman decisiones de política social a nivel país — si la información no fuera encontrable de verdad, esas decisiones podían tomarse con datos incompletos o mal interpretados, simplemente porque nadie pudo encontrarlos a tiempo.

El problema real

No se trataba de "hacer un portal". El desafío real era definir cómo una institución debía estructurar, publicar y hacer encontrable información pública dispersa, para que la gente realmente pudiera dar con los datos que buscaba.

Cómo lo abordé

Hicimos benchmarking internacional y entrevistas con usuarios. Validé con el equipo técnico para entender los alcances, lo que implicó sentar en una misma sala a gente con prioridades distintas —negocio, tecnología, usuarios finales— y traducir entre esos tres lenguajes hasta encontrar un punto en común: el equipo definió usar CKAN, así que aprendí sus librerías para que lo que diseñara fuera implementable, sin rodeos ni diseños imposibles. Levantamos hipótesis sobre cómo los usuarios querían encontrar los datos y las validamos con tests y entrevistas; hicimos card sorting para construir la arquitectura de información. Tras los primeros tests de usabilidad, ajustamos la arquitectura con esos hallazgos y volvimos a testear: en esa segunda ronda, la mayoría de los usuarios encontró lo que buscaba.

Explorador de rutas

Interactivo

El camino real que recorre quien busca un dato en el portal público del ministerio. Las ocho categorías están verificadas contra el portal; dos llegan hasta el archivo concreto y las demás se detienen donde alcanzaba la evidencia pública.

Elige una categoría de «Datos abiertos» y sigue su ruta hasta donde llega.

Explorador de rutas del portal BIDAT

La decisión

El encargo podía resolverse como "hacer un sitio web" — pero el problema real era otro: cómo estructurar y hacer encontrable información pública dispersa entre distintas áreas del ministerio. Decidimos no diseñar un portal, sino un sistema de acceso: reorganizar la arquitectura de información en torno a las necesidades reales de consulta de los usuarios, no a la estructura administrativa interna. Esa misma vara definió la lógica de búsqueda y filtrado — las categorías reflejan cómo la gente busca, no cómo el ministerio se organiza puertas adentro.

La solución

Definí navegación y estructura, prototipé en baja y en alta usando el design system gubernamental. A mitad de camino, ese design system cambió y la capa visual tuvo que mutar. Lo que no podíamos darnos el lujo de rehacer era la estructura, así que defendí esa parte del trabajo frente al cambio y la adapté a la nueva piel visual sin perder lo ya validado con usuarios — y la estructura que definimos sigue siendo la que hoy está en producción.

Complejidad del proyecto

Múltiples stakeholders con criterios distintos
Información dispersa en distintas áreas
Distintos criterios de publicación
Necesidades de usuarios y negocio no siempre alineadas
Restricciones técnicas
Necesidad de encontrabilidad real

Mi rol y contribución

  • Benchmarking internacional
  • Levantamiento de hipótesis
  • Arquitectura de información
  • Workshops con stakeholders
  • Validación con usuarios
  • Definición de búsqueda, filtros y estructura
  • Prototipado funcional

Decisiones clave

No diseñar un portal, sino un sistema de acceso

El equipo replanteó el enfoque de 'hacer un sitio web' hacia diseñar un sistema que permitiera encontrar, navegar y comprender datos públicos de manera efectiva.

Ordenar la información según necesidades reales de consulta

A través de research identificamos patrones reales de búsqueda y consulta, y reorganizamos la arquitectura de información en torno a las necesidades de los usuarios, no a la estructura interna del ministerio.

Definir lógica de búsqueda y filtrado

Definí una lógica de búsqueda y filtros que reflejara las categorías relevantes para los usuarios, no las divisiones administrativas internas.

Validar supuestos antes de producción

Validamos supuestos con usuarios reales antes de entrar en producción, lo que permitió ajustar decisiones de arquitectura y navegación con evidencia.

Alinear institución, usuarios y tecnología

Trabajé con el equipo para alinear expectativas institucionales, necesidades de usuarios y posibilidades técnicas, hasta llegar a una solución viable y útil.

Resultado e impacto

La mayoría de los usuarios encontró lo que buscaba en la segunda ronda de tests, tras ajustar la arquitectura con los hallazgos de la primera.
Producto en producción, usado para tomar decisiones de política social a nivel país.
Arquitectura validada con usuarios reales antes de producción.
La estructura definida sobrevivió a un cambio de design system a mitad del proyecto.

Qué demuestra este proyecto

Demuestra cómo uso research, arquitectura de información y validación para estructurar servicios digitales útiles, encontrables e implementables — diseñando con la tecnología en mente, no contra ella.

Fuentes verificables

Siguiente proyecto

ChileCompra