Escritorio para Proveedores
Mercado Público
Más de un millón de proveedores usan Mercado Público para hacer negocios con el Estado. Su escritorio de inicio era el primer lugar que veían cada mañana — y no les decía nada útil. Este proyecto cambió eso.
Un escritorio que no sabía para qué existía
En Mercado Público, los proveedores son las empresas y personas que venden al Estado. Cada vez que entran a la plataforma, lo primero que ven es su escritorio: un panel de inicio con resúmenes, accesos y notificaciones.
El problema era que ese escritorio mostraba información sin jerarquía. Todo tenía el mismo peso visual. Una licitación que vencía en dos horas aparecía igual que una estadística mensual que podía revisarse cualquier día. Para entender qué tenían pendiente, los proveedores tenían que navegar entre secciones, hacer clic en varios lugares, recordar rutas.
Una plataforma que se supone hace más eficiente el negocio de los proveedores les estaba robando tiempo desde el primer segundo.
Entender antes de rediseñar
Antes de tocar Figma, necesitaba entender cómo los proveedores realmente usaban el escritorio — no cómo asumíamos que lo usaban. Realicé entrevistas en profundidad con proveedores de distintos rubros y tamaños, desde microempresas hasta empresas medianas con equipos dedicados a compras públicas.
Las preguntas giraron en torno a su rutina diaria: ¿qué es lo primero que revisan al entrar?, ¿qué información buscan activamente?, ¿qué se pierden o descubren tarde?, ¿qué les genera ansiedad o incertidumbre?
”Entro y lo primero que hago es ir directo a licitaciones, porque el inicio no me dice nada.”
Proveedor de servicios tecnológicos
”A veces me entero de que perdí una licitación por el correo, no por la plataforma.”
Proveedor de insumos de oficina
”Las órdenes de compra son lo más crítico para mí. Si no las acepto a tiempo, pierdo el negocio.”
Proveedor de servicios de mantención
”No sé cuándo vence mi habilidad para contratar. Me doy cuenta cuando ya no puedo operar.”
Proveedor del rubro construcción
”El escritorio me muestra cosas de hace meses. Para qué quiero ver eso primero.”
Proveedor de servicios de limpieza
”Tengo que acordarme yo de revisar si hay algo nuevo. La plataforma no me avisa bien.”
Proveedor de alimentos
El patrón era claro: el escritorio existente no priorizaba. Mostraba todo por igual, sin distinción entre lo urgente y lo informativo, entre lo que requería acción inmediata y lo que podía esperar. Los proveedores habían desarrollado workarounds — iban directo a otras secciones, usaban el correo como sistema de alertas, se acordaban ellos mismos de las fechas.
La plataforma les estaba transfiriendo su propia carga cognitiva.
El principio que ordenó todo el diseño
De lo más urgente para el negocio, a lo menos crítico.
No se trata de mostrar más información — se trata de mostrarla en el orden correcto. El escritorio tiene que saber qué es urgente antes de que el proveedor llegue a preguntarse.
A partir de las entrevistas, construí una jerarquía de necesidades del proveedor. No todas las informaciones valen lo mismo. Una orden de compra pendiente de aceptar tiene consecuencias inmediatas. Una estadística de ventas del trimestre puede revisarse con calma cualquier tarde.
El nuevo escritorio se estructuraría siguiendo esa jerarquía: primero lo que requiere acción hoy, después lo que requiere atención pronto, al final lo informativo.
Acciones pendientes
Órdenes de compra sin aceptar, licitaciones con plazo próximo a vencer, documentos requeridos. Todo lo que tiene una fecha límite visible.
Estado de habilitación
Vigencia de inscripción en ChileProveedores, documentos próximos a vencer. Lo que afecta la capacidad de operar en la plataforma.
Licitaciones relevantes
Licitaciones activas en el rubro del proveedor, con filtros por monto y fecha. Lo que puede convertirse en negocio.
Estado de propuestas
Resumen de licitaciones en curso, adjudicadas y en evaluación. Para hacer seguimiento sin navegar entre secciones.
Estadísticas y resumen
Montos facturados, historial de contratos, evolución del negocio. Útil, pero no urgente.
Iterar para encontrar la forma correcta
El prototipo pasó por varias iteraciones antes de llegar al testing formal. Cada versión se revisó con el equipo y con usuarios clave, ajustando la jerarquía visual, el peso de cada sección y los patrones de interacción.
Una de las decisiones más discutidas fue cuánta información mostrar en cada card. La tensión era constante: más contexto ayuda a tomar decisiones, pero demasiado contexto paraliza o abruma. El criterio fue siempre el mismo — mostrar lo mínimo necesario para que el proveedor sepa si necesita actuar o no.
Paralelamente al prototipado visual, trabajé la arquitectura de contenido: cómo nombrar cada sección, qué etiquetas usar, cómo redactar las notificaciones y estados para que fueran accionables y no solo informativos.
La estructura detrás de la interfaz
El diseño visual de un dashboard puede ser perfecto y aun así fallar si el contenido está mal estructurado. Trabajé la arquitectura de información en paralelo al diseño: qué mostrar, cómo llamarlo, en qué orden presentarlo.
Validar con usuarios reales antes de lanzar
Las sesiones de prueba de usabilidad compararon el escritorio anterior con el nuevo prototipo. Los participantes realizaron tareas concretas: encontrar una orden de compra pendiente, verificar su estado de habilitación, identificar licitaciones relevantes para su rubro.
El criterio de evaluación fue doble: eficiencia (tiempo en completar cada tarea) y confianza (si el usuario sabía que había encontrado la información correcta).
Hallazgo clave del testing: en el escritorio anterior, varios participantes completaban la tarea pero expresaban duda sobre si la información era la correcta o si debían seguir buscando. La nueva jerarquía redujo esa incertidumbre — los usuarios llegaban antes y con más seguridad.
Antes y después
Sin jerarquía clara. Todo con el mismo peso visual. Información histórica mezclada con acciones urgentes. El proveedor tenía que descifrar qué requería su atención.
Estructura por criticidad. Lo urgente, visible desde el primer scroll. Las acciones pendientes destacadas. El proveedor sabe en segundos si hay algo que necesita atención hoy.
Lo que aprendimos después del lanzamiento
El diseño no termina cuando se lanza. Una vez en producción, monitoreamos el comportamiento real de los proveedores para entender si el rediseño cumplía su promesa en condiciones reales — no de laboratorio.
Hotjar — mapas de calor y sesiones
Analizamos grabaciones de sesión y mapas de calor para entender dónde hacían clic los proveedores, hasta dónde scrolleaban, qué secciones ignoraban. El comportamiento real a veces difiere del comportamiento en testing — y esas diferencias son las más valiosas.
Encuesta de salida
Implementamos una encuesta de salida para recoger la percepción directa de los usuarios sobre la nueva experiencia. Queríamos saber si la jerarquía que diseñamos correspondía con la jerarquía que ellos experimentaban — si lo que pusimos primero era realmente lo primero que necesitaban.
Lo que cambió para los proveedores
Acceso inmediato a lo urgente
Las acciones pendientes ahora son visibles desde el primer scroll, sin necesidad de navegar a otras secciones.
5 secciones por criticidad
Una estructura clara que va de lo urgente a lo informativo, siguiendo la lógica real de trabajo de los proveedores.
Notificaciones accionables
En lugar de alertas genéricas, cada notificación indica qué hay que hacer y cuándo — no solo que algo ocurrió.
Validación con datos reales
El comportamiento post-lanzamiento se monitoreó con Hotjar y encuestas para iterar sobre la base de uso real, no supuestos.
Lo que me llevé
Este proyecto me enseñó que el principal problema de muchos dashboards no es que muestren poca información — es que la muestran sin criterio. Agregar más datos no resuelve nada si no hay una jerarquía que le diga al usuario qué mirar primero.
La decisión de diseño más importante no fue visual: fue definir qué es urgente y qué no lo es para un proveedor de Mercado Público. Todo lo demás fluyó desde ahí.