Design System
Mercado Público
Construir un sistema de diseño no es solo ordenar componentes. Es decidir quién habla, cómo suena, y qué dice cuando alguien necesita entender algo urgente en una plataforma que mueve miles de millones de pesos en compras del Estado.
Una plataforma crítica con un lenguaje roto
Mercado Público es donde el Estado de Chile compra. Hospitales, municipios, ministerios — todos pasan por ahí para adquirir desde insumos médicos hasta servicios tecnológicos. Es una plataforma que no puede darse el lujo de ser confusa.
Cuando llegué a liderar el Design System, lo primero que encontré no fue un problema de componentes. Fue un problema de voz. Cada equipo escribía a su manera. Algunos flujos sonaban a resolución judicial. Otros, a correo corporativo de los años 90. Muy pocos sonaban a una conversación entre personas reales.
El sistema existente tenía componentes, sí. Pero no tenía criterio compartido sobre qué decir en cada uno de ellos. Eso es un vacío que se nota: en los botones que generan duda, en los mensajes de error que señalan sin orientar, en las etiquetas que solo entiende quien lleva años dentro del equipo.
Lo que encontramos al mirar con cuidado
Antes de proponer cualquier solución, hice un diagnóstico del estado actual del contenido. Revisé flujos completos, etiquetas, mensajes de sistema, CTAs y documentación interna. Lo que encontré fue revelador.
”Cancelar” en un botón que en realidad confirmaba un pago.
Hallazgo en flujo de adquisición directa
Abreviaturas internas —CM, RFI, OOPP— sin contexto ni glosario.
Hallazgo en módulo de licitaciones
Mensajes de error que describían el problema pero no ofrecían ninguna salida.
Hallazgo en validaciones de formulario
El mismo concepto nombrado de tres formas distintas en tres pantallas consecutivas.
Hallazgo en flujo de órdenes de compra
Anglicismos como backoffice mezclados con tecnicismos legales, sin jerarquía clara.
Hallazgo en documentación del sistema
Instrucciones redactadas en voz pasiva que diluían la responsabilidad del sistema.
Hallazgo transversal en más de 12 pantallas
El diagnóstico confirmó lo que intuía: el problema no era la ausencia de contenido, era la ausencia de criterio. Nadie sabía qué palabras usar porque nadie había definido cómo debía sonar esta plataforma.
La pregunta que lo ordenó todo
Necesitaba un filtro simple, aplicable por cualquier persona del equipo, que permitiera evaluar cualquier pieza de contenido sin necesidad de ser escritora profesional.
¿Existen personas que hablen así?
Si la respuesta era no, había que reescribir. Esta pregunta se convirtió en el norte de todo el proyecto.
Desde ahí, trabajé junto al Departamento de Comunicaciones de ChileCompra para definir los principios que guiarían todo el contenido del sistema. No como una lista de reglas, sino como una forma de pensar antes de escribir.
Claro
El usuario entiende qué está pasando y qué puede hacer. Sin ambigüedad, sin jerga innecesaria, sin frases que requieran ser leídas dos veces.
Conciso
Solo lo necesario. El contenido que sobra no es neutro: distrae, dilata y genera fricción. Cada palabra tiene que ganar su lugar.
Útil
El contenido orienta, no solo informa. Le dice al usuario qué hacer, no solo qué pasó. Anticipa dudas y ofrece salidas.
La estructura del sistema
El Design System se organizó siguiendo los principios de diseño atómico, con una capa adicional que no suele estar en los sistemas tradicionales: los lineamientos de contenido como parte constitutiva del sistema, no como anexo.
Tokens de diseño
Colores, tipografía, espaciado, radios, sombras. Los valores primitivos que alimentan todo lo demás.
Componentes base
Botones, inputs, etiquetas, iconos, badges. Los bloques más pequeños con sus estados y variantes.
Patrones compuestos
Formularios, tarjetas, modales, tablas, navegación. Componentes que combinan átomos con lógica.
Lineamientos de contenido
Principios, patrones de escritura, tono por contexto, guía de CTAs, manejo de errores, glosario.
Un sistema de valores que escala
Para establecer un sistema visual consistente y sostenible, definimos una arquitectura de tokens en tres niveles. La lógica: que cualquier cambio global —un rebrand, una nueva temática— pudiera propagarse desde un solo lugar.
Tokens primitivos
Los valores brutos: todos los colores, tamaños tipográficos, unidades de espaciado y radios posibles. No tienen semántica aún — son el vocabulario completo del sistema.
color.blue.500spacing.4font.size.lgTokens semánticos
Los valores con propósito. Le dan significado a los primitivos y comunican la intención de uso. Son los que usa directamente el equipo de diseño.
color.action.primarycolor.feedback.errorspacing.component.gapTokens de componente
Los más específicos. Definen los valores de cada componente individual, mapeados a los semánticos. Son el puente entre diseño y desarrollo.
button.primary.backgroundinput.border.focusbadge.text.colorCada componente es una decisión de contenido
Lo que aprendí construyendo esta librería es que un componente sin criterio de contenido es solo una cáscara. Un botón sin guía de etiquetado puede generar confusión. Un mensaje de error sin patrón de redacción puede frustrar en el peor momento.
Cada componente en la librería se diseñó con sus estados, variantes e interacciones — pero también con sus lineamientos de contenido integrados directamente en la documentación.
Configurables
Cada componente expone sus propiedades en Figma para que los equipos puedan configurar variantes, estados y contenido desde un solo panel, sin romper la estructura.
Con estados completos
Default, hover, focus, disabled, error, loading. Cada estado documentado con su comportamiento visual y su criterio de contenido.
Accesibles
Contraste validado según WCAG 2.1 AA, etiquetas ARIA documentadas, jerarquía de foco definida. La accesibilidad como criterio de diseño, no de revisión final.
Escalables
Construidos con auto-layout y tokens para que funcionen en distintos contextos sin perder coherencia. Diseñados para cinco productos distintos, con una sola fuente de verdad.
Lineamientos de contenido: la capa que cambia todo
Esta fue la parte del sistema que más me costó argumentar y que más impacto tuvo. Los lineamientos de contenido no vivieron en un documento separado de Drive. Se integraron al sistema con el mismo peso que la tipografía o los colores.
Preferir el pasado simple
La solicitud ha sido procesada correctamente.
La solicitud fue procesada correctamente.
El pasado simple es más directo y más humano. La voz pasiva diluye y alarga.
CTAs como promesas
Continuar
Enviar solicitud
Un CTA es una promesa: le dice al usuario exactamente qué va a pasar. Esa promesa tiene que cumplirse.
Errores que orientan
Error al procesar la solicitud. Código: 403.
No tienes permiso para ver esto. Si crees que es un error, contacta al administrador de tu organización.
Los errores señalan el problema Y ofrecen una salida. El usuario no debería quedar sin opciones.
Ofrecer salidas
Para continuar, debes completar todos los campos obligatorios.
Falta completar el RUT de la empresa. También puedes guardar como borrador y retomar más tarde.
No todas las personas quieren seguir el camino que diseñamos. El contenido tiene que anticipar eso.
El matiz de lo técnico-legal
Mercado Público tiene una particularidad que complicó algunas decisiones: sus usuarios compradores son expertos en compras públicas. Eso significa que hay términos técnicos y legales que no se pueden eliminar. Licitación pública, trato directo, adjudicación — estos son conceptos del vocabulario profesional de quienes usan la plataforma.
El reto no era simplificar a cualquier costo. Era encontrar el punto de equilibrio donde el lenguaje técnico necesario coexiste con la mayor claridad posible para quienes recién se incorporan. Ese matiz se documentó explícitamente en el sistema.
Regla que definimos: si el término técnico existe porque es legal o regulatorio, se mantiene y se contextualiza. Si existe porque “siempre se ha dicho así”, se evalúa y probablemente se reemplaza.
Cómo se construyó
El sistema no se entregó todo de una vez. Se lanzó de forma incremental, priorizando los componentes de mayor uso y los lineamientos más urgentes primero. En cada etapa, se recogió feedback de los equipos que lo usaban.
Diagnóstico y principios
Auditoría del contenido existente, entrevistas con equipos, definición de principios junto a Comunicaciones.
Fundación del sistema
Definición de tokens primitivos y semánticos, paleta de color, tipografía, espaciado. La base sobre la que todo se construye.
Componentes atómicos
Botones, inputs, badges, iconos. Cada uno con estados completos y lineamiento de contenido integrado.
Patrones compuestos
Formularios, tablas, modales, navegación. Componentes con lógica más compleja y mayor dependencia de contenido.
Lineamientos de voz y tono
Guía completa de escritura, patrones de CTA, manejo de errores, glosario de términos técnicos y criterios de simplificación.
Lo que cambió
Los lineamientos de contenido se integraron al Design System con el mismo peso que la tipografía, los colores o los componentes. No como un anexo. Como parte viva del sistema, consultable en la misma herramienta donde los equipos diseñan.
Eso cambió algo concreto: los equipos dejaron de tomar decisiones de contenido de manera intuitiva y empezaron a tener criterios compartidos. Las revisiones llegaron antes en el proceso. La plataforma empezó a sonar más pareja, más coherente, más humana.
Una sola fuente de verdad
Cinco productos, un sistema. Los equipos saben exactamente dónde buscar el componente correcto y cómo escribir en él.
Contenido como criterio de diseño
Las decisiones de contenido se toman en el mismo espacio donde se diseña, no después ni aparte.
Iteración más rápida
Con tokens bien definidos, propagar cambios visuales dejó de ser una tarea de semanas.
Accesibilidad documentada
Cada componente con sus criterios WCAG verificados antes del lanzamiento, no como revisión final.
Lo que me llevé
Este proyecto me confirmó algo que creo profundamente sobre el diseño de sistemas: las decisiones de contenido son decisiones de arquitectura.
Definir cómo habla un producto no es un detalle de último minuto. Es una elección que atraviesa cada pantalla, cada flujo, cada momento en que un usuario necesita entender qué está pasando y qué puede hacer.
Cuando esa decisión se toma con cuidado y se documenta bien, el resultado no es solo una plataforma más consistente. Es una plataforma que se siente más confiable.