umairmsm/wp-design

Etapa 2: Diseño

Objetivo: el propietario ha aprobado un aspecto que ha visto en un teléfono y en un portátil. Está escrito como tokens, para que pueda convertirse en un skin de WordPress simplemente copiándolo y reemplazarse más tarde sin perder funcionalidades.

Pasos

1. Dirección. Completa el docs/DESIGN_DIRECTION.md del proyecto: estrella del norte, audiencia, aquello a lo que no debemos parecernos (competidores, plantillas) y lo no negociable. Ofrece dos o tres direcciones como máximo, en forma de pequeños moodboards o maquetas de héroe, no sitios completos.
2. Prototipo en static/. HTML y CSS simples. css/tokens.css usa los mismos nombres que el skins/default/tokens.css del tema. Los componentes usan solo tokens. Estructura real (encabezado, héroe, tarjetas, formulario, pie de página), texto de relleno, sin precios ni texto legal.
3. Accesibilidad desde el principio:
   • contraste ≥ 4.5:1 para el texto;
   • foco visible;
   • un H1;
   • un enlace de salto;
   • rutas de teclado;
   • respetar prefers-reduced-motion. Verifica el prototipo con axe (extensión del navegador) antes de mostrarlo.
4. Revisión del propietario. Capturas de pantalla de cada página en anchos de teléfono (375 px) y portátil (1440 px). Registra la fecha de aprobación en DESIGN_DIRECTION.md y guarda las capturas en docs/design/.
5. Fuentes: auto-aloja archivos .woff2, limítalos a los idiomas necesarios, verifica la licencia y precarga las una o dos caras de la primera pantalla (nómbralas como *-preload.woff2). Sin solicitudes a Google Fonts en ningún lugar.
6. Portar a WordPress (references/design-system.md):
   • copia los tokens en el skin;
   • mueve el CSS de los componentes a skin.css;
   • diseña las plantillas con las funciones de renderizado del núcleo;
   • añade anulaciones de partes del skin solo donde el marcado deba diferir. El aspecto cambia; los contratos de datos y marcado del núcleo no.
7. Rediseños posteriores son nuevos skins: copia skins/default a skins/<nombre>, cambia los tokens, previsualiza con ?skin=<nombre> (administradores), y cambia con la opción <prefijo>_skin una vez aprobado.

Puerta (marcar en SITE_STATUS.md)

• DESIGN_DIRECTION.md escrito; aprobación del propietario registrada con capturas de pantalla
• Tokens definidos; los componentes usan solo tokens
• Fuentes auto-alojadas; 0 solicitudes a Google Fonts

Lecciones

• El diseño bloqueado cambió cuando el socio comercial envió su propio rediseño. Como el aspecto era un skin, el cambio mantuvo cada funcionalidad. Construye cada diseño como un skin, incluso el primero.
• No copies la paleta, la combinación tipográfica o la disposición de un competidor. Los propietarios lo notan y los visitantes no te recuerdan.
• Un skin solo de prueba (dev-*) para probar ideas nunca se muestra en producción.
• Si las habilidades frontend-design o design-motion-principles están instaladas, úsalas para la dirección y el movimiento.