Open Design

git clone https://github.com/nexu-io/open-design.git

Open Design es una colección abierta y gratuita para diseñar interfaces con la ayuda de un agente de línea de comandos. Combina dos piezas: una buena cantidad de sistemas de diseño inspirados en marcas conocidas y un conjunto de habilidades especializadas en formatos típicos como landings, paneles, páginas de precios o pantallas móviles. Es la alternativa abierta a herramientas comerciales similares, y está pensada para funcionar de forma local si así lo decides.

El problema que resuelve es doble. Por un lado, la pelea por mantener consistencia visual cuando se diseña asistido por IA: cada nueva pantalla suele tener su propio estilo si no se acuerdan referencias. Por otro, el coste creciente de generar diseños con modelos en la nube cuando se hacen muchas iteraciones. Tener un repertorio reutilizable de estilos y poder enchufar un modelo local cambia ambas ecuaciones.

Le rinde a personas con cierto nivel técnico que ya trabajan con un agente en la terminal y quieren elevar la calidad visual de lo que producen, a equipos pequeños interesados en mantener una identidad coherente sin depender de servicios cerrados, y a quien estudia diseño y quiere aprender por contraste cómo un mismo componente se resuelve en distintos sistemas.

Por qué importa

Antes, lo común era describir el estilo desde cero a la IA en cada nueva pantalla: “que se parezca a Linear”, “que tenga el aire de Notion”. La IA hacía una interpretación libre y los resultados variaban entre iteraciones, lo cual es frustrante cuando intentas dar coherencia a un producto. Además, generar mucha interfaz con un modelo de pago se notaba en la factura.

Con una biblioteca de sistemas ya formalizados, en lugar de explicar el estilo, lo eliges. El agente toma como referencia un sistema concreto, aplica sus principios (tipografías, escalas, colores, espaciados, esquinas, sombras) y produce pantallas que se parecen unas a otras de manera predecible. La conversación pasa de pelearse con el aspecto a centrarse en el contenido y la estructura.

A esto se suma el ahorro económico cuando se conecta un modelo local. Si tu equipo o flujo permite usar un modelo que corre en tu propia máquina, las iteraciones dejan de consumir tokens de pago. No es magia, hay un coste de hardware y configuración, pero a partir de cierto volumen el cambio es muy claro.

Cómo se usa en la práctica

El primer paso es clonar el repositorio y abrir la carpeta. Open Design no es una aplicación con interfaz propia: es un conjunto de recursos que un CLI compatible aprende a usar. La configuración consiste en indicarle a tu agente (Claude Code es el soporte principal, también es compatible con Codex, Cursor, Gemini CLI o Copilot CLI) que cargue esos recursos.

El primer caso útil es probar un sistema de marca con una pantalla sencilla. Pedir una página de aterrizaje con el estilo de un sistema concreto produce un resultado que ya viene con coherencia interna. Comparar varias versiones del mismo contenido con sistemas distintos enseña qué hace especial a cada uno: tipografía, ritmo vertical, color, densidad.

Refinar es el siguiente paso. La primera versión tiende a aplicar el sistema con bastante fidelidad, pero la realidad de tu producto puede pedir ajustes. Conversar con el agente para hacer esos cambios sin perder la lógica del sistema requiere pedir cosas específicas: “aumenta la escala tipográfica en una variante”, “añade un componente para mostrar planes con tres niveles”, “respeta los radios del sistema pero usa otra paleta de acento”.

Integrar Open Design con las skills temáticas del propio repositorio multiplica resultados. Las skills cubren formatos típicos: landing de software, panel de administración, página de precios, aplicación móvil, presentación, informe formal. Combinar “tal sistema” con “esta skill” produce piezas mucho más cercanas a un resultado profesional que pedir directamente “diseña algo bonito”.

Si quieres aprovechar la parte local, hay que conectar un modelo que corra en tu equipo. Eso convierte el adjetivo “local-first” en algo más que una etiqueta: si sigues con un modelo en la nube, vas a seguir gastando tokens. La conexión depende del CLI y del modelo elegidos.

Otro patrón útil es trabajar por marcos: antes de empezar una serie de pantallas, define qué sistema vas a usar, qué skills vas a aprovechar y qué adaptaciones harás. Anotarlo en un archivo breve hace que las siguientes peticiones partan del mismo punto. Y conviene actualizar el repositorio cada cierto tiempo: la comunidad añade y refina sistemas y skills con frecuencia.

Casos de uso reales

Una desarrolladora indie que lanza productos pequeños lo usa como atajo visual. Antes pasaba horas con estilos genéricos; ahora elige un sistema, lo aplica a landing, panel y precios, y dedica el tiempo recuperado a mejorar el contenido.

Una agencia pequeña de diseño aprovecha la biblioteca como material didáctico interno. Cada semana eligen un sistema, lo estudian y replican un patrón clásico (formulario, listado, ficha) usándolo. El equipo amplía su criterio visual y descubre patrones que incorpora a su propio sistema.

Un estudiante de diseño de producto monta su portafolio con varias pantallas inspiradas en sistemas distintos, todas hechas con Open Design. Documenta las decisiones tomadas. Le sirve como pieza de portafolio y como reflexión sobre cómo funcionan los sistemas profesionales.

Un equipo técnico que ha levantado un modelo local en sus servidores lo combina con Open Design para generar prototipos sin restricciones de coste. Iteran decenas de veces por semana sobre pantallas internas y validan con usuarios reales.

Errores comunes y cómo evitarlos

• Confiar en que “local-first” significa gratis por defecto. Solo lo es si conectas un modelo local; con uno en la nube, vas a seguir gastando tokens.
• Tratarlo como un agente independiente. No lo es: necesita un CLI compatible ya instalado y configurado. Sin esa pieza, el repositorio por sí solo no produce nada.
• Saltarse el paso de elegir sistema antes de pedir pantallas. Si no indicas uno concreto, el resultado vuelve a ser genérico.
• Ignorar las skills temáticas. Pedir solo “una pantalla bonita” desaprovecha la mitad del valor; combinar sistema y skill da resultados más cercanos al uso real.
• Forzar una marca propia encima de un sistema sin reflexionar. Meter tus colores corporativos por encima puede producir un híbrido incoherente; conviene decidir qué se mantiene y qué se sustituye.
• Olvidarse de actualizar el repositorio. La comunidad añade mejoras con frecuencia; quedarse con la versión clonada hace meses es renunciar a parte del valor.

Cuándo NO usarla

Si tu nivel técnico no llega aún al uso fluido de un CLI con agente, conviene empezar por herramientas más asistidas. Open Design exige cierta soltura con la terminal y con la idea de combinar piezas (sistemas, skills, modelos) que no vienen empaquetadas en una sola aplicación con interfaz amable.

Tampoco es la mejor elección cuando necesitas producir una sola pantalla puntual y rápida; el coste de configuración no se amortiza para un caso único. Y si tu equipo prefiere una solución cerrada con soporte oficial, una alternativa comercial con respaldo puede encajar mejor a cambio del coste.

Combinarla con otras herramientas

Open Design encaja bien con un agente con interfaz como Cursor para retocar detalles de implementación, y con un constructor visual como Lovable cuando quieres llevar el resultado a algo publicable rápido. Si dispones de un modelo local, sumar un buen sistema de control de versiones y plantillas internas de proyecto te permite estandarizar todo el flujo. Para presentación, una herramienta de export y captura visual completa el círculo.

Mini-ejercicio

Clona el repositorio en tu equipo, configura tu CLI de cabecera (Claude Code si no tienes preferencia) y pide tres versiones de una misma página de aterrizaje para un producto inventado (por ejemplo, un servicio para reservar clases particulares). Cada versión debe usar un sistema de marca distinto del repositorio y la skill de landing de software como servicio. Después, anota en una lista corta qué te gusta y qué no de cada versión: tipografías, ritmo, color, densidad.

Sabrás que está bien si terminas con tres pantallas claramente diferenciables entre sí, cada una coherente con su sistema, y eres capaz de explicar en pocas frases por qué cada estilo serviría mejor para un público concreto.