Volver a proyectos

ChileCompra

Rediseñé la base de la plataforma modular de compras públicas del Estado de Chile para convertirla en un sistema configurable y escalable.

Cliente

Dirección ChileCompra — Mercado Público

Vía

Babel Group

Rol

Senior Product Designer · Diseño funcional

Duración

1,5 años

Estado

V1 en producción

Este caso también se juega

Lo más relevante

Una reforma a la Ley de Compras Públicas obligaba al Estado a estrenar un mecanismo de compra que nunca había existido, con un plazo legal que no se movía. Pero la apuesta de fondo era más grande que ese mecanismo: en vez de programar una solución para ese único caso, construir una base capaz de sostener todos los que vinieran después. Yo entré, en teoría, solo a acompañar los diseños que ya estaban. Terminé replanteando la estructura sobre la que hoy funciona la plataforma.

Diseñada para escalar al universo completo de Mercado Público: unos 120.000 proveedores y 850 organismos públicos, según cifras de ChileCompra.
52,6% de ahorro fiscal en la primera Subasta Inversa Electrónica del Estado, construida sobre esta base.
Sobre esta misma base ya opera un segundo mecanismo —Consulta al Mercado— y ChileCompra comprometió el tercero, Licitaciones Simples, para 2026: mecanismos que se suman sin rehacer la plataforma.

Resumen ejecutivo

Rediseñé la base de la nueva Plataforma Modular de Compras Públicas del Estado de Chile: una estructura genérica pensada para que distintos mecanismos de compra puedan montarse sobre la misma base, en lugar de construir una plataforma nueva para cada uno. Sobre ella operó la primera Subasta Inversa Electrónica del Estado.

Jugable Interactivo

No quería que solo entendieras el caso. Quería que pudieras vivirlo.

Transformé las decisiones que tomé en ChileCompra en algo completamente diferente: una analogía jugable con los mismos desafíos y restricciones, en un contexto distinto, para que cualquiera pueda tomar esas decisiones en primera persona.

Jugar Operación Horizonte

Contexto y qué estaba en juego

ChileCompra es la plataforma por donde el Estado de Chile compra a escala nacional. Una reforma a la Ley de Compras Públicas exigía un mecanismo inédito —la Subasta Inversa Electrónica— y ChileCompra puso un requisito claro: que la plataforma fuera modular y genérica, capaz de albergar distintos mecanismos de compra sobre una misma base, con tres niveles de usuario (compradores, proveedores y administradores). El plan de la institución es público: la primera fase arrancó con la Subasta Inversa y ChileCompra ya levantó la licitación de la segunda, una fase que —en sus palabras— «fortalece la columna vertebral iniciada en la fase uno». Su horizonte declarado es que todo Mercado Público termine operando sobre esta base: unos 120.000 proveedores y 850 organismos públicos. En juego había plata pública, escala nacional y un dominio altamente normado: un error de diseño podía derivar en problemas legales y en un impacto fiscal directo, no solo en una experiencia confusa.

El problema real

El requisito era claro, pero los diseños que ya existían no conversaban con él: estaban pensados ad hoc, para casos puntuales. Si se implementaban tal cual, la plataforma no iba a poder montar distintos mecanismos de compra — y ese era justo el corazón del proyecto. Ese fue el riesgo que detecté: el problema no era de pantallas, era que la base no iba a poder ser genérica.

Cómo lo abordé

Antes de tocar una pantalla, estudié a fondo el negocio y la normativa, y entendí cómo lo iban a usar los tres niveles de usuario. El equipo del cliente llevaba tiempo investigando y definiendo la experiencia que querían lograr; lo que no sabían era cómo hacer que eso pasara siendo genérico. Ahí entré yo: tomé sus insights de usuario y los traduje a forma funcional, cuidando lo que querían —su panel, su navegación— pero logrando que todo se mantuviera genérico y funcionara igual de un mecanismo a otro. Me volví el puente entre lo que el usuario necesitaba, lo que el equipo de UX del cliente ya había definido, y lo que la arquitectura técnica permitía. Hubo tensión real: el equipo de UX del cliente quería conservar ciertas decisiones de pantalla que, tal cual estaban, rompían la genericidad. No se trataba de imponer mi criterio sino de mostrar el costo concreto de cada opción para que la decisión se tomara con esa información sobre la mesa — y la mayoría de las veces encontramos una tercera vía que conservaba lo que ellos querían sin sacrificar la base.

Mismas piezas, distinta navegación

Interactivo

Una base común se arma con piezas configurables y las reglas que las gobiernan. Desde esa misma base salen dos experiencias distintas: una para crear y publicar procesos, otra para participar en ellos.

Toca una pieza para resaltarla y seguirla por todo el recorrido.

Diagrama vertical sobre fondo blanco que explica una lógica de plataforma configurable. En la parte superior aparecen seis tarjetas de componentes: Bloque, Regla, Estado, Acción, Ruta y Vista. Algunas tarjetas están marcadas como seleccionadas, indicando que forman parte de la configuración elegida. Debajo, un ícono de usuario representa a quien define las reglas del sistema. A su lado aparece una tarjeta de "Reglas / Condiciones" con una lista de validaciones, mostrando que la configuración no solo selecciona piezas, sino que también establece criterios de funcionamiento. En el centro del diagrama aparece una ventana llamada "Base común", donde se muestran las piezas seleccionadas reutilizadas como parte de una estructura compartida. Desde esta base salen dos caminos. El primer camino muestra una experiencia para crear y publicar en base a las reglas definidas. Esta vista usa las mismas piezas de la base común en una interfaz orientada a gestión, con navegación lateral, listado de elementos y acciones de operación. El segundo camino muestra múltiples participantes usando la misma base. Esta experiencia presenta una navegación distinta, más guiada por pasos, con indicadores de avance y contenido organizado para participar en el proceso. En la parte inferior, el mensaje "Mismas piezas, navegación distinta" resume la idea principal: una misma configuración permite construir experiencias diferentes según el tipo de uso, manteniendo coherencia y reutilización de componentes.

La decisión

No fue una sola decisión, sino muchas y complejas: cómo interactuaban los módulos, cómo se armaba el menú, cómo era la navegación, qué funcionalidad iba en qué lugar — todo con la misma vara: que la base siguiera siendo genérica montara el mecanismo que montara. Una de esas decisiones fue definir el MVP: sé acotar un primer release y ayudé a priorizar qué entraba sin romper la base, pero las decisiones se tomaron entre todos y varias de mis propuestas fueron las que se llevaron adelante. Yo no tenía autoridad formal sobre el equipo de desarrollo ni sobre el de UX del cliente — la única forma de que mis propuestas avanzaran era que el razonamiento detrás se sostuviera solo, así que cada decisión la llevé con el costo y la alternativa ya pensados, no solo con la conclusión.

La solución

El trabajo fino fue definir qué funcionalidades se usaban, en qué lugar y cómo, para que no chocaran entre sí y cada módulo mantuviera su propia acción sin pisar a los demás. Cada uno debía poder montarse en un mecanismo y en otro, y seguir siendo genérico. Traduje los insights de usuario y el modelo de variables de salida de un módulo a otro en requerimientos concretos para desarrollo: qué se conectaba, cómo y con qué datos, partiendo siempre del negocio. Un reto grande fue el cronograma: que la plataforma avanzara de forma configurable y agnóstica al mecanismo —que pudiera ajustarse para uno u otro sin perder lo genérico—. El mejor ejemplo de por qué eso importaba lo dio el segundo mecanismo: Consulta al Mercado necesita que las respuestas de los proveedores puedan ser públicas o privadas según el proceso, algo que la subasta inversa nunca pidió. No hubo que abrir la plataforma para agregarlo — la visibilidad de una respuesta es una variable del mecanismo, no una pantalla nueva. Hoy los dos mecanismos están configurados y operando sobre la misma base, y recorriéndolos no se nota que son cosas distintas: un cambio de configuración basta para que la misma estructura se comporte de otra manera. Que la costura no se vea es justamente el resultado que buscaba.

La misma base, distintas configuraciones

Interactivo

Regla, Estado, Acción y Ruta son siempre las mismas cuatro piezas. Sobre ellas se monta el mecanismo de compra, y basta cambiar una para que el sistema se comporte de otra manera o deje de funcionar.

Cambia la configuración y mira cuándo el sistema queda funcionando y cuándo desconectado.

Al inicio

Solo se podría armar un mecanismo de compra modular y no escalaría.

Con la solución

Se separaron las responsabilidades y negocios y se podrían armar diferentes mecanismos de compra con la misma base.

Diagrama interactivo que muestra por qué una base genérica se sostiene o se rompe según cómo se configure. Las piezas del sistema son cuatro y siempre las mismas: Regla, que fija las condiciones bajo las que algo puede ocurrir; Estado, que define en qué momento del proceso se encuentra; Acción, que es lo que un usuario puede hacer; y Ruta, que es el camino por el que avanza. Sobre ellas se monta una quinta pieza, Subasta, que representa el mecanismo de compra concreto. En pantallas anchas el diagrama aparece como una ventana de sistema con cinco variantes seleccionables: al elegir una, las mismas piezas se recombinan y la ventana muestra un indicador que cambia entre Funcionando y Desconectado según si la combinación es válida. En pantallas angostas el mismo contenido se presenta como un rompecabezas con un control de Armar sistema: las piezas encajan una a una y el indicador reporta el resultado. La conclusión es la misma en ambas versiones: el mecanismo no se programa de nuevo cada vez, se configura sobre las mismas piezas — y basta cambiar una para que el sistema se comporte de otra manera o deje de funcionar.

Cómo aseguré que se construyera

El reto no era solo de alcance: una reforma legal exigía un mecanismo inédito, con impacto fiscal directo si algo fallaba, sobre una plataforma genérica de 15 módulos y 3 niveles de usuario, con dependencias cruzadas entre módulos y datos compartidos, que además tenía que poder escalar a mecanismos futuros sin desarrollo nuevo. Y era un reto de tiempo: la entrega era de corto plazo, con negocio, diseño y arquitectura todavía sin alinear entre sí.

Como referente funcional del producto, traduje y alineé continuamente entre negocio, el equipo de UX del cliente y desarrollo: reestructuré los módulos, diseñé la experiencia multirol y redefiní el MVP sin sacrificar la genericidad que el proyecto necesitaba. Cuando detectaba un riesgo —un dato que no calzaba, una regla que chocaba con otro mecanismo— lo subía de inmediato al equipo en vez de esperar a la siguiente instancia formal; en un proyecto con plazo legal fijo, avisar temprano valía más que tener razón después.

Me hice cargo del QA funcional y de negocio: revisar si los servicios respondían, cuál se caía, qué dato traía cada uno, descifrar un token cuando hacía falta, para que lo construido respondiera a la normativa y a las reglas de cada mecanismo. En paralelo, el equipo UX del cliente validó la usabilidad con usuarios reales, lo que dio respaldo de cara al usuario a la estructura que yo estaba asegurando del lado funcional y técnico.

Decisiones clave

No construir para un solo mecanismo

Propuse replantear los diseños específicos de la subasta inversa como una base modular capaz de soportar mecanismos nuevos.

Las pantallas ya estaban definidas y aprobadas: no sólo por UX, también con negocio y validadas con usuarios. Abrirlas de nuevo significaba tocar mucho trabajo previo, sostenerlo con evidencia de la normativa y de cómo funcionaba lo que ya existía, y aceptar que en el corto plazo entorpecía la experiencia tal como estaba planificada. Hubo que rehacer.

Probar cada pieza contra mecanismos que no existían

La plataforma se diseñaba módulo a módulo. Para decidir si una funcionalidad debía vivir en un módulo o en otro, hacía el ejercicio de imaginar qué mecanismos de compra podrían crearse después y comprobar si esa función seguía teniendo sentido en ellos. Si quedaba vacía o fuera de lugar, no iba ahí.

En la práctica era quitarle funciones a un módulo para que vivieran en otro y funcionaran de otra manera: resolvía el problema de fondo, pero no en la forma en que estaba planificado. El ejercicio sólo sirve si entiendes el negocio a un nivel que no te piden como diseñador — la normativa, qué mecanismos son posibles, qué los distingue. Sin eso, es adivinar.

Que la plataforma entera fuera genérica

Empujé para que cada módulo fuera lo más agnóstico posible a cualquier mecanismo particular, y pudiera reutilizarse en la mayor cantidad de casos.

Del otro lado empujaban tres cosas a la vez: negocio y UX pidiendo la pantalla exacta, el plazo, y la deuda técnica que el equipo de desarrollo ya arrastraba. Ser el guardián de lo genérico es un rol impopular por definición: siempre le quita algo a alguien.

Un MVP viable y con futuro

Ayudé a acotar el primer release: entrar con lo imprescindible para la subasta, sin comprometer la base genérica que debía sostener lo que venía.

Dejamos fuera, a conciencia, mucha experiencia de usuario. Soy UX y me dolió, pero la prioridad cero era que el producto funcionara. Hicimos vista gorda a cosas que en otro contexto no habría dejado pasar, para llegar al plazo.

Traducir en las dos direcciones

Convertí la lógica de negocio y el modelo de datos en requerimientos claros para desarrollo, cuidando que la base se mantuviera genérica.

Esta no tuvo tensión: fue la que destrabó al resto. UX llegaba con experiencia, navegación y flujos, pero no con cómo se armaba todo eso de forma genérica — dónde se guarda cada dato, dónde se usa y para qué, para poder pintar la pantalla que pedían y conservar la navegación que proponían. Y en la otra dirección, negociar con desarrollo cosas que costaban más tiempo, porque que funcionara no era lo único que había que defender. La voz del equipo técnico hacia negocio, y la de negocio hacia el equipo.

Lo que no salió bien

Una regla quedó donde probablemente no va

El criterio que aplicamos en todos los demás módulos —que cada uno fuera agnóstico al mecanismo— en éste se simplificó de más, y terminó absorbiendo una regla que seguramente no le correspondía. El cliente lo aprobó así y hoy funciona, pero no de la manera óptima: es probable que esa regla termine necesitando su propio módulo. No rompe nada —crear un módulo nuevo es justamente lo que la base permite—, pero es deuda que quedó.

Un problema de uso que introduje yo

Cumplir con mecanismos que todavía no existían obligó a soluciones complejas, y varias comprometían el funcionamiento de la base. Una de ellas, propuesta por mí, traía además un costo de usabilidad fuerte. El equipo técnico lo respaldó como no resoluble en ese momento, así que se avanzó con esa deuda encima y se arrastró bastante tiempo. Quedó resuelto en una tercera pasada — pero el tiempo, el rehacer y la deuda intermedia salieron de una decisión mía.

Evidencia en el tiempo

Operando

Subasta Inversa Electrónica (SIE)

Primer mecanismo montado sobre la base; corrió sobre el MVP, la primera versión en producción. Comunicado oficial ChileCompra, ago 2025

Operando

Consulta al Mercado

Segundo mecanismo, configurado sobre la misma base sin desarrollo adicional. ChileCompra, may 2026

Previsto

Licitaciones Simples

Tercer mecanismo, comprometido públicamente para 2026. Se monta configurando la misma base, sin desarrollo adicional. Cuenta Pública Participativa de ChileCompra, jul 2026

Resultado e impacto

Sobre la base operó la primera Subasta Inversa Electrónica del Estado: 52,6% de ahorro fiscal en su primera puja.
El MVP —primera versión en producción— sostuvo la Subasta Inversa Electrónica desde 2025; V1 llegó después, con una subasta más robusta y dos mecanismos nuevos sobre la misma base — el detalle y las fuentes están en la línea de tiempo, más arriba.
Los dos mecanismos conviven configurados sobre la misma base sin que se note que son cosas distintas: Consulta al Mercado sumó respuestas públicas y privadas —algo que la subasta nunca pidió— con un cambio de configuración, no de desarrollo.
Evitar construir una plataforma ad hoc por cada mecanismo ahorra al Estado el costo de desarrollar una solución nueva cada vez que aparece un mecanismo de compra distinto.

Qué demuestra este proyecto

Demuestra mi fuerte: entender un negocio complejo y normado y traducirlo en una estructura que el equipo puede construir y que crece sin rehacerse.

Qué aprendí

Aprendí que en proyectos así el mayor valor no está en la pantalla más bonita, sino en las decisiones de estructura que casi nadie ve. Sabíamos que era una fase 1: el objetivo no era terminarlo todo, sino dejar una base capaz de aguantar lo que viniera. ChileCompra ya levantó la licitación de la fase 2 sobre esa misma columna vertebral.

No es un juego sobre el caso, son las decisiones que tomé, contadas de una manera diferente, me propuse como desafío salir de la caja, para contar algo que muchas veces no cabe en un portfolio y texto, lo convertí en una experiencia que se puede recorrer, decidir y comprender.

Jugar Operación Horizonte

Se juega en el navegador, en escritorio: necesita una ventana de al menos 1280×720.

Fuentes verificables

Proyecto anterior

Ministerio de Desarrollo Social y Familia

Siguiente proyecto

Microcervecería AEC