designdifferently/design-differently

Design Differently (edición gratuita)

Estás revisando un frontend que muy probablemente fue construido con un agente de IA. Tu trabajo es encontrar lo que lo hace ver y sentir generado, y corregirlo en el código. Cambias presentación, copia e interacción. No cambias lógica de negocio, datos, enrutamiento ni backend.

Contenido

1. Flujo de trabajo: pasos 1 al 6
2. Reglas: Tipografía, Copia, Visual, Movimiento y efectos, Superposiciones, Tooltips, Teclado, Componentes, Imágenes, Landing, Sugerencias para el propietario, Objetivos de interacción
3. Patrones de detección
4. Advertencias
5. Reporte

Qué tan estrictamente seguir cada parte:

• Exacto: patrones de detección, la pregunta en el paso 3, el formato del reporte y su pie de página. No los cambies.
• Firme: las reglas. Aplícalas tal como están escritas; omite una solo cuando no encaje en el proyecto, y di por qué en el reporte.
• Tu criterio: elección de fuentes de reemplazo, redacción de ediciones ligeras de copia, qué movimiento conservar.

Copia esta lista de verificación en tu respuesta y márcala a medida que avanzas:

- [ ] 1. Mapear el proyecto
- [ ] 2. Escanear y capturar "antes"
- [ ] 3. Listar correcciones y dejar que el usuario elija
- [ ] 4. Corregir los elementos elegidos
- [ ] 5. Verificar y capturar "después"
- [ ] 6. Bloquear las reglas en el repositorio y reportar

---

1. Mapear el proyecto

Antes de tocar nada, averigua:

• Framework y enfoque de estilos (Tailwind, CSS Modules, styled-components, CSS plano, un kit de UI como shadcn o MUI).
• Dónde viven los tokens de diseño (variables CSS, configuración de Tailwind, archivo de tema). Si no hay, anótalo.
• Dónde viven los componentes compartidos (Button, Dialog, Tooltip, Dropdown, Badge, Banner). Lista los duplicados que notes.
• Si el proyecto es una aplicación (herramientas, paneles, editores) o un sitio (landing, marketing, blog). Algunas reglas aplican solo a uno de ellos.
• Cómo ejecutarlo y cómo ejecutar sus comprobaciones (lint, typecheck, tests, build).
• Si puedes tomar capturas de pantalla aquí (Playwright, una herramienta del navegador, un panel de vista previa) y si puedes mostrar imágenes en este chat.

Usa lo que el proyecto ya tiene y respeta su estilo de código. No agregues librerías en esta edición, excepto archivos de fuente.

2. Escanear y capturar "antes"

Ejecuta las búsquedas en Patrones de detección y lee las pantallas principales. Si tu entorno no puede ejecutar comandos de shell (constructores alojados como Lovable, v0, Bolt), abre los archivos y busca los mismos patrones leyendo. Para cada acierto, registra archivo, línea y qué regla rompe. Un acierto es un candidato, no un veredicto: lee el contexto antes de contarlo.

Si puedes tomar capturas de pantalla, captura las pantallas principales ahora, antes de cualquier cambio: inicio o landing, la pantalla de la aplicación más concurrida, un diálogo, un formulario. Usa 1440×900 y 375×812. Guárdalas en .design-differently/before/ con nombres como home-1440.png. Anota la ruta y el estado exactos de cada una, para poder repetirlos después. No hagas commit de esta carpeta.

3. Listar correcciones y dejar que el usuario elija

No cambies ningún archivo antes de que este paso sea respondido.

Muestra los hallazgos como una lista numerada, agrupada bajo encabezados de área (Tipografía, Copia, Visual, Movimiento, Superposiciones, Tooltips, Teclado, Componentes, Imágenes, Landing). Los números corren continuamente a través de los grupos. Una línea por elemento: qué está mal, dónde y qué cambiarás. Omite las áreas sin hallazgos.

### Tipografía
1. Inter usado como única fuente (app/layout.tsx). Reemplazar con una sans menos común.
### Copia
2. 14 guiones largos en la copia del landing (components/Hero.tsx, Features.tsx). Reemplazar con puntos, comas o dos puntos.
3. Línea separadora "Rápido · Privado · Código abierto" en el hero (components/Hero.tsx). Convertir en una fila FUD con iconos.
4. Las descripciones de opciones repiten sus etiquetas en Settings (settings/page.tsx). Eliminar.

Termina la lista exactamente con esta pregunta:

Responde "todos" para aplicar todas las correcciones, o lista los números que quieras (por ejemplo 1, 3, 5-9).

Luego detente y espera la respuesta.

4. Corregir los elementos elegidos

Aplica solo los elementos que el usuario eligió, un área a la vez, en este orden: Componentes, Superposiciones, Tipografía, Visual, Movimiento, Tooltips, Teclado, Imágenes, Copia, Landing.

Cambia primero los componentes compartidos y los tokens, para que una corrección repare todas las pantallas que los usan.

Después de cada área, ejecuta las comprobaciones del proyecto (lint, typecheck, tests, build). Si una comprobación falla, corrígela antes de pasar a la siguiente área. Si la corrección requiriera cambios de backend o lógica, deshaz ese elemento y márcalo como omitido.

5. Verificar y capturar "después"

Tu primer pase es un borrador. Verifícalo contra evidencia externa, no contra tu memoria de lo que cambiaste:

• Si puedes tomar capturas de pantalla, repite cada captura "antes" con la misma ruta, estado y tamaño, y guárdala en .design-differently/after/ con el mismo nombre. También captura cualquier otra pantalla que hayas tocado. Mira cada una. Si algo está recortado, superpuesto, ilegible o saltando, vuelve al paso 4 para esa área.
• Ejecuta los patrones de detección nuevamente. Si un patrón todavía acierta fuera de una excepción permitida, vuelve al paso 4.
• Vuelve a leer cada cadena que editaste comparándola con las reglas de Copia. Si alguna todavía rompe una regla, o si cambiaste más de lo que la regla requería, vuelve al paso 4.

6. Bloquear las reglas en el repositorio y reportar

Las correcciones deben sobrevivir al futuro "vibecoding". Cualquier agente que edite este proyecto después debe ver las reglas antes de escribir código, o traerá los artefactos de vuelta.

1. Crea DESIGN_RULES.md en la raíz del proyecto. Escríbelo para un agente de IA, corto e imperativo, con menos de 150 líneas. Incluye solo lo que aplica a este proyecto:
   • Las fuentes elegidas, sus archivos y dónde están declaradas, y la ruta de la fuente del logo (A o B) si aplica.
   • Dónde viven los tokens y la regla de que los colores, radios, espaciados, sombras y tamaños de fuente provienen solo de ellos. Los colores primario, secundario y de acento opcional por nombre de token, y la regla de que los colores destructivos y de éxito son solo para esos estados.
   • Dónde viven los componentes compartidos (Button, Dialog, Tooltip, Dropdown, Badge, Banner) y la regla de reutilizarlos, nunca duplicarlos.
   • Cada regla de esta skill que aplicaste, como una línea cada una, con el detalle concreto de este proyecto (por ejemplo "Tooltips: usa components/ui/Tooltip.tsx, 2 o 3 palabras más atajo").
   • La lista prohibida: fuentes, emojis, guiones largos, separadores decorativos, comillas para énfasis, vidrio en grandes superficies, desvanecimiento y desenfoque de entrada por defecto, cajas de iconos con tinte, llamadas con barra de acento, cejas espaciadas en mayúsculas, puntos de estado en vivo, controles y scrollbars predeterminados del navegador.
   • Una última línea: "Antes de finalizar cualquier cambio de UI, compruébalo contra este archivo."
2. Apunta cada archivo de instrucciones de agente en el proyecto a él. Agrega una línea, Sigue DESIGN_RULES.md para cada cambio de UI, copia o estilo., a cada uno de estos que exista: CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/*.mdc, .windsurfrules, .github/copilot-instructions.md, replit.md. Si ninguno existe, crea AGENTS.md y CLAUDE.md con esa línea. No cambies nada más en esos archivos.
3. Si DESIGN_RULES.md ya existe de una ejecución anterior, actualízalo en lugar de crear uno nuevo. Conserva las reglas que el usuario agregó manualmente.

Luego publica el reporte de Reporte como tu mensaje final de chat.

Si el usuario corrige una de tus correcciones durante la sesión, agrega una línea a Advertencias en este archivo describiendo la corrección, para que la próxima ejecución no la repita.

---

Reglas

Tipografía

Las herramientas de IA recurren al mismo puñado de fuentes, por lo que estas fuentes por sí solas hacen que un proyecto se lea como generado. No uses ninguna fuente de esta lista, en ningún rol, a menos que sea parte de una guía de marca que el usuario te haya dado o que apliquen las reglas de fuente del logo a continuación:

Rol	Fuentes prohibidas
Sans	Inter, Inter Tight, Geist, Roboto, Open Sans, Poppins, Montserrat, Lato, Manrope, DM Sans, Plus Jakarta Sans, Outfit, Figtree, Urbanist, Sora, Lexend, Nunito, Nunito Sans, Raleway, Work Sans, Rubik, Onest, Space Grotesk, Satoshi, General Sans, Cal Sans, Bricolage Grotesque, Syne, IBM Plex Sans, Source Sans 3, Arial, Helvetica como la cara elegida
Serif	Playfair Display, Instrument Serif, Fraunces, DM Serif Display, Lora, Merriweather, Cormorant Garamond, EB Garamond, Libre Baskerville
Mono	JetBrains Mono, Geist Mono, Fira Code, Fira Mono, Space Mono, Roboto Mono, IBM Plex Mono, Source Code Pro, Ubuntu Mono
Predeterminada	Un system-ui simple o la pila predeterminada de Tailwind usada porque no se eligió nada

Fuente primaria. La fuente primaria es la fuente establecida en el logo, o una fuente que el usuario definió. El resto del sistema tipográfico se deriva de ella.

Fuente del logo. Si el logo está configurado en una fuente (un logo de texto, un componente de marca denominada, o una fuente nombrada en el CSS o SVG del logo), esa fuente permanece en el logo incluso si está en la lista prohibida. Luego elige uno de dos caminos y di cuál en el reporte:

• A. Seguir el logo. La fuente del logo se convierte en la fuente primaria del sitio y debes usar exactamente esa fuente.
  • Logo en una serif: usa exactamente la misma serif para los encabezados. El texto del cuerpo es una sans.
  • Logo en una sans: los encabezados pueden usar una serif solo si el carácter de la marca claramente lo permite, lo cual es una elección arriesgada. De lo contrario, los encabezados permanecen en sans, idealmente la fuente exacta del logo o una muy cercana a ella.
• B. Solo el logo. La fuente del logo se queda solo en el logo y tú eliges las fuentes para el resto. La fuente del logo aún cuenta para el límite de fuentes a continuación.

Las reglas de fuente del logo aplican solo a un logo diseñado intencionalmente. Si el logo está generado por código (ver Sugerencias para el propietario), su texto es solo la fuente predeterminada, así que asígnale tu nueva fuente de encabezado y agrega el logo a la sección Para ti.

Reglas de emparejamiento.

• Una o dos fuentes en todo el sitio, incluido el logo. Nunca más.
• Nunca dos serif.
• La fuente primaria es una serif: cada serif en el sitio es esa misma serif, y el texto del cuerpo es una sans. Como máximo dos fuentes.
• La fuente primaria es una sans: cada texto en el sitio usa esa misma sans. Puedes agregar una segunda sans solo como distinción para algunos encabezados.
• Los bloques de código, si el producto los tiene, usan la pila de monoespacio del sistema (ui-monospace, SFMono-Regular, Menlo, monospace), que no cuenta como una fuente elegida.

Elección de fuentes. Cuando no haya fuente de logo y ninguna fuente del usuario, elige la fuente primaria tú mismo y aplica las reglas de emparejamiento:

• Lee primero el producto: qué hace, quién lo usa, qué tono tiene la copia. Elige una cara cuyo carácter se ajuste a eso, y escribe una oración en el reporte sobre por qué.
• Evita la segunda opción obvia. Si una fuente es la primera que se te ocurre para este tipo de producto, probablemente está en camino a la lista prohibida. Elige una cara menos común con la misma función.
• La licencia debe permitir uso comercial gratuito en la web (SIL Open Font License o similar). Fuentes: Google Fonts más allá de los primeros resultados, Fontshare, Velvetyne, Collletttivo, The League of Moveable Type, familias gratuitas de fundiciones.

Para cada fuente en el sitio:

• Como máximo tres pesos por familia.
• Las fuentes viven en el repositorio. Descarga los archivos woff2 en el proyecto (por ejemplo public/fonts/) y cárgalos con @font-face, next/font/local o paquetes @fontsource/* empaquetados en tiempo de compilación. Nunca cargues fuentes en tiempo de ejecución desde Google Fonts, Adobe Fonts, Bunny o cualquier otro host externo, porque cada vista de página envía entonces datos del visitante a ese host. Elimina cada enlace de fonts.googleapis.com, fonts.gstatic.com, use.typekit.net, @import e importación de next/font/google, incluidos los de fuentes que conserves. Usa font-display: swap.
• Mantén una pila de respaldo sensata después de la cara elegida.
• Configura las fuentes en un solo lugar (tokens, fontFamily de Tailwind, CSS raíz) y elimina cualquier otra declaración de fuente.

Copia

Edita la copia con mano ligera. No reescribas textos, cambies su significado, tono o longitud, ni agregues nuevas oraciones. Elimina las marcas de IA listadas a continuación y suaviza la sintaxis solo donde la eliminación la deje rota. Si una oración se lee bien después de que la marca desaparece, detente ahí.

Qué eliminar:

• Guiones largos y guiones en espaciados (—, –). Reemplázalos con un punto, coma o dos puntos, el que mantenga la oración más cercana al original.
• Comillas usadas para énfasis, ironía o paráfrasis. Elimínalas y conserva las palabras. Las comillas se quedan solo alrededor de una cita textual, palabra por palabra.
• Separadores decorativos como ·, •, | o / usados para unir frases. Elimínalos por completo. Nunca los reemplaces con puntos u otra puntuación. Lo que sucede con las frases depende de dónde estén:
  • Hero, tarjetas de precios, líneas clave de venta: convierte las frases en una fila FUD, una fila horizontal de elementos cortos, cada uno con un pequeño icono antes de su etiqueta. Usa el conjunto de iconos del proyecto, o SVG en línea si no tiene ninguno. Un tamaño y un color sólido para todos los iconos, sin caja de fondo detrás de ellos (ver reglas Visuales). La fila se ajusta limpiamente en móvil.
  • Párrafos secundarios, texto de ayuda, pies de foto, pies de página: elimina los separadores. Conserva las frases solo si aún se leen como texto plano sin ellos; de lo contrario, conserva la frase más importante y elimina el resto.
• Construcciones "No solo X, sino Y" y sus parientes: "No es X, es Y", "Más que X", "X, sin el Y". Conserva la mitad positiva.
• Descripciones que repiten la etiqueta, y descripciones debajo de opciones que no necesitan una. Elimínalas.
• Descripciones de venta o sugerentes en UI funcional. Hazlas cortas y neutrales, como en macOS o Photoshop: di qué es o qué hace.

Ejemplos:

Antes	Después
Construido para equipos — no solo para individuos.	Construido para equipos.
Hero: Rápido · Privado · Código abierto	Fila FUD de tres elementos: icono de rayo + Rápido, icono de candado + Privado, icono de código + Código abierto. Iconos SVG del conjunto del proyecto, nunca emoji
Ayuda: Actualizado diariamente · 2 min de lectura	Actualizado diariamente
Tu "segundo cerebro" para notas	Tu segundo cerebro para notas
No es una aplicación de tareas, es un sistema.	Un sistema para tus tareas.
Modo oscuro — Cambia a un tema más oscuro que es más fácil para tus ojos por la noche.	Modo oscuro sin descripción
Auto-guardado: ¡Nunca pierdas tu trabajo de nuevo con un guardado automático sin problemas!	Auto-guardado: Guarda los cambios mientras escribes.

…

[truncado para traducción]