# Prompts de diseño UI — INV-2026 Tres prompts, uno por superficie. **Pega siempre el BLOQUE COMÚN al inicio**, luego el prompt de la superficie que quieras. El bloque común es lo que hace que las tres se vean como un mismo producto en vez de tres apps sueltas. | Prompt | Vista | Dispositivo | Archivo de entrega | Estado | |---|---|---|---|---| | A | Cliente — QR y previsualización | Móvil | `captura.html` | **Construido** | | B | Colaborador — bandeja de órdenes | Tablet / PC en tienda | `ordenes.html` | **Construido** | | C | Analista — inventario y mermas | Escritorio | `inventario.html` | **Construido** | **Un prototipo es una iteración de diseño completa, no una pantalla.** Las tres vistas viven dentro de `prototipos/prototipo-01/`, comparten los mismos cuatro archivos de CSS base y se enlazan entre sí desde el sidebar. Cuando cambie la dirección de diseño, se crea `prototipo-02/` con sus tres vistas — nunca una carpeta por pantalla. Antes de generar cualquier prototipo nuevo, lee `prototipo-01/` y hereda de él. ## Defectos recurrentes que debes evitar Salieron de la verificación en navegador de estos tres prototipos. Los tres son el mismo error de fondo: - **Declara `display` explícitamente.** Un `` con `width`/`height` no hace nada: es `inline`. Rompió una barra de progreso (renderizó a 0×0) y juntó título y detalle en una sola línea, dos veces. - **Dale tamaño por omisión a los SVG.** Un ícono sin regla propia adopta el tamaño intrínseco del viewport (300×150) y revienta el layout. Pon `svg { width: 16px; height: 16px }` en la base y deja que los componentes lo sobrescriban. - **`white-space: nowrap` en identificadores.** Un folio como `ORD-26-0431` se parte en tres líneas si no se lo impides. - **Nunca escribas directo sobre un nodo opcional.** `$('#algo').textContent = x` con `#algo` ausente lanza excepción y aborta la inicialización, dejando la página pintada pero sin eventos. Es el peor modo de fallo porque parece correcta. Usa una guarda. --- # TAREA 0 — Identidad corporativa (prerrequisito) > Ya ejecutada. El resultado vive en `docs/marca/identidad-innovasport.md`. > Repítela solo si cambia la marca o se incorpora otra enseña del grupo. ``` Antes de diseñar nada, levanta la identidad corporativa real del cliente y déjala documentada. No estimes colores a partir de una captura de pantalla: extrae los valores que el propio sitio declara. 1. Abre el sitio del cliente en un navegador con sesión real. Los sitios de este grupo responden 403 a curl, fetch programático y cualquier petición que no venga de un navegador; tenlo previsto. 2. Lee las custom properties declaradas en :root recorriendo document.styleSheets. Ahí están los colores y la escala tipográfica de producción. 3. Descarga los logotipos a assets/brand/ en sus tres variantes: horizontal sobre fondo claro, versión en blanco para fondos oscuros, e isotipo para el menú colapsado. 4. Escribe docs/marca/identidad-.md con: la paleta tal como la declara el sitio, la tipografía, y una sección que traduzca esa paleta de e-commerce a una consola administrativa. En esa traducción resuelve explícitamente el conflicto que casi siempre aparece: el rojo de marca suele estar muy cerca del rojo de error. Si el botón primario y el estado de error son el mismo color, el usuario deja de distinguir "acción" de "problema". Reserva el rojo de marca para acción primaria y estado activo, y usa un rojo más profundo y desaturado para error. Si algún asset no se puede descargar, dilo en el documento, indica la ruta exacta donde debe colocarse manualmente, y deja el código referenciándolo para que aparezca solo en cuanto exista. No inventes un logotipo. ``` --- # BLOQUE COMÚN > Pega esto antes de cualquiera de los tres prompts. ``` Actúa como un Diseñador UX/UI Senior y Arquitecto Frontend experto en software empresarial. El resultado debe leerse como un producto corporativo maduro: consistente, sobrio, denso en información y sin adorno. No un mockup bonito, sino algo que un director pueda ver y creer que ya está en producción. Y debe estar preparado para crecer desde la concepción: cada decisión que tomes será heredada por otras dos superficies y por cinco enseñas comerciales distintas. ## Contexto del producto Sistema de Gestión de Inventario y Personalización de jerseys deportivos para Grupo Innovasport: ~600 puntos de venta en México, Ecuador, Perú, Chile y Bolivia, bajo cinco enseñas (Innovasport, Innvictus, Over Time, Rookie Kids y Marathon). Digitaliza un proceso que hoy es de papel: órdenes escritas a mano, tickets que se pierden entre turnos, e inventario de vinil contado a mano una vez al mes con Forms y Excel. Tres frentes acoplados: 1. El cliente escanea un QR del ticket y captura él mismo su personalización. 2. La tienda gestiona una cola de trabajo con prioridades y tiempo estimado. 3. El material se descuenta del inventario carácter por carácter. ## Glosario de dominio (úsalo con precisión, es vocabulario del cliente) - Personalización AUTÉNTICA: el estampado que usan los clubes. Lo surte un proveedor externo, precortado. Su disponibilidad depende del JUGADOR, no del material. Se inventaría por paquete. - Personalización OFICIAL: estampado licenciado del club o selección. Piezas precortadas. Se inventaría por pieza. - Personalización GENÉRICA: réplica cortada en tienda con plotter a partir de rollos de vinil de 50 o 100 metros. Se inventaría por METROS. - Merma: de 1 metro salen 8 personalizaciones teóricas, pero el estándar operativo es 6. Las 2 restantes son merma contable. - Licencia restringida: algunos clubes solo permiten caracteres de su abecedario oficial precargado. Ahí no se puede ofrecer vinil genérico. - Material sin rotación: stock que lleva más de N meses sin moverse. El cliente le dice "caducado" aunque no caduque físicamente. Es propiedad del ROLLO, no del material. - Plantilla: disposición del estampado sobre el jersey. Cuatro variantes: nombre recto o curvo, arriba o abajo del número. ## Reglas de negocio que la interfaz DEBE hacer visibles - Todo el texto se imprime en MAYÚSCULAS. El input lo fuerza y lo muestra así. - Los signos de puntuación se respetan tal como se capturan (¿ ? ¡ ! . - ' &) y los acentos también (Á É Í Ó Ú Ñ Ü). - El texto impreso será idéntico al registrado. No hay cambios ni devoluciones, PERO si el error es del personal, la empresa repone el producto. Por eso la confirmación del cliente es un acto deliberado y con evidencia, no un botón más. - Si el material de un carácter está agotado en esa sucursal, se alerta y se BLOQUEA la confirmación. No se permite capturar una orden imposible de surtir. - Cada plantilla impone un máximo de caracteres para el nombre y de dígitos para el número. El límite se muestra siempre, no solo al excederlo. - Metros y piezas nunca se suman ni se muestran sin unidad. Confundirlos es exactamente el error que el sistema existe para evitar. ## Referencia visual El lenguaje objetivo es el de una consola administrativa empresarial densa, no el de un sitio de marketing: - Sidebar oscuro de ancho fijo, con el ítem activo resaltado en el rojo de marca, agrupación por secciones con etiquetas en versalitas, acordeones para el segundo nivel, y un selector de tenant fijo al pie. - Topbar claro con búsqueda global, alternancia de tema, notificaciones con contador y avatar. - Encabezado de página con título en versalitas, ruta de migas y las acciones alineadas a la derecha, terminando en un botón primario sólido. - Tira de contadores por estado que funciona como filtro, con la cifra coloreada según su semántica y el total activo destacado. - Barra de filtros con entrada de chips, selectores compactos y búsqueda. - Tabla densa de encabezado fijo, filas de altura contenida, badges de estado con color + ícono + texto, y columnas numéricas con cifras tabulares. - Avisos apilados en la esquina inferior derecha, con barra de acento a la izquierda según severidad. ## Design System ### Principio rector El contenido de esta app SON los colores de los equipos: amarillo del América, azul de Cruz Azul, verde de México. El cromado de la interfaz es neutro para no competir con ellos; el color vivo lo pone el producto, no la interfaz. ### Paleta — valores reales, extraídos del sitio de Innovasport Fuente: docs/marca/identidad-innovasport.md. No los sustituyas por estimaciones. | Rol | Light | Dark | |---|---|---| | Marca / acción primaria | #E21736 | #F0344F | | Marca hover | #C2122D | #FF4747 | | Sidebar fondo | #16100F | #0E0B0B | | Fondo de página | #F4F5F7 | #0F1113 | | Superficie | #FFFFFF | #181B1F | | Borde | #E4E6EA | #2A2F36 | | Texto | #14161A | #ECEDEE | | Texto secundario | #646B76 | #9BA3AE | | Info | #2563EB | #60A5FA | | Éxito | #0E9F6E | #34D399 | | Advertencia | #D97706 | #FBBF24 | | Error | #B42318 | #F87171 | El error NO usa el rojo de marca. #E21736 es acción; #B42318 es problema. Todos los pares cumplen WCAG AA. Ningún estado se comunica solo con color: siempre color + ícono + etiqueta de texto. ### Tipografía Inter, que es la familia corporativa declarada por el sitio. | Nivel | Tamaño / interlineado | Peso | |---|---|---| | Display | 28 / 34 | 700 | | H1 | 20 / 28 | 700 | | H2 | 16 / 24 | 600 | | Body | 14 / 21 | 400 | | Small | 13 / 18 | 500 | | XS | 12 / 16 | 500 | | Label | 11 / 14 | 700, versalitas, tracking .08em | En móvil el body sube a 16px para evitar el zoom automático de iOS. Toda cifra en tablas y contadores usa tabular-nums. La tipografía del jersey es CONTENIDO, no interfaz: se renderiza con la fuente licenciada del equipo y jamás se mezcla con la tipografía de la UI. ### Espaciado, forma y movimiento - Escala de 4px. Radio 6px en controles, 8px en botones, 12px en tarjetas. - Elevación por borde y fondo, no por sombras pesadas. - Transiciones de 160ms solo en opacidad y transform. Respeta prefers-reduced-motion. ### Accesibilidad y ergonomía (obligatorio) - Área táctil mínima 44px; 48px en la vista de tienda, que se opera de pie. - Foco visible siempre, con anillo de 2px en el color de marca. - Contraste alto real: la tienda tiene reflejos y el cliente puede estar a contraluz. - Todo ícono que sea acción lleva aria-label. - Los estados de carga usan skeletons, no spinners que tapen el contenido. ## Arquitectura de entrega (obligatoria) Escribe el prototipo 100% en HTML, CSS y JavaScript puros. Sin framework, sin preprocesador, sin paso de compilación, sin dependencias. La única petición externa permitida es la tipografía desde Google Fonts. Entrégalo en esta estructura. Una carpeta por ITERACIÓN DE DISEÑO, con las tres vistas dentro: prototipos/prototipo-NN/ ├── index.html Portada · punto de entrada de la demo ├── captura.html Vista cliente ├── ordenes.html Vista tienda ├── inventario.html Vista corporativo ├── css/ │ ├── tokens.css Variables de diseño, claro y oscuro. Única fuente │ ├── base.css Reset, tipografía, accesibilidad │ ├── layout.css Shell y regiones estructurales │ ├── components.css Componentes │ └── .css Solo lo específico de una vista, cargado encima ├── js/ │ └── .js Estado → filtrado → render, en un solo sentido ├── data/ │ ├── .json Datos simulados. Fuente de verdad │ └── .data.js Envoltorio generado del JSON ├── assets/brand/ Logotipos └── README.md Cómo abrirlo, qué es funcional, decisiones tomadas Las tres vistas comparten los CSS base — no copias por vista — y se enlazan entre sí desde el sidebar, para que se lean como un producto y no como tres apps. Reglas no negociables de esta arquitectura: - **Ningún componente usa un color literal.** Todo pasa por tokens.css. Habilitar otra enseña del grupo debe ser sobrescribir --brand y --sidebar-bg, sin tocar nada más. Eso es lo que significa estar preparado para crecer, y es verificable: busca un HEX fuera de tokens.css y no debe haber ninguno. - **Un solo diccionario de presentación.** Cómo se ve cada estado, prioridad y tipo se define en un objeto al inicio de app.js. Agregar un estado nuevo es agregar una entrada ahí, nunca tocar la función de render. - **Debe abrirse con doble clic**, sin servidor. Ojo: file:// bloquea fetch() de archivos locales por CORS, así que el JSON no se puede cargar con fetch. Mantén el .json como fuente de verdad y genera un envoltorio .js que lo asigne a una variable global. Documenta en el README cómo regenerarlo. - **Datos simulados creíbles**: volumen suficiente para que la tabla se vea real (20+ registros), con nombres, licencias y materiales del dominio, y al menos un caso de cada estado incluyendo los de excepción. ``` --- # PROMPT A — Cliente: captura por QR y previsualización ``` [Pega aquí el BLOQUE COMÚN] Entrega en: prototipos/prototipo-02/ ## 1. Contexto y Audiencia Objetivo de negocio: trasladar la captura de la personalización al cliente final para eliminar los errores ortográficos que hoy comete el colaborador al teclear, y convertir un trámite en una experiencia que justifique el precio del servicio. Hoy el cliente dice "Alejandra" y el colaborador escribe "Alexandra"; la disputa que sigue la paga la empresa. Usuario final: comprador en una tienda deportiva, usando SU PROPIO teléfono, de pie, con la prenda en la mano y gente esperando detrás. Uso único en su vida: no habrá tutorial, no habrá segunda oportunidad, no hay cuenta ni login. Tono: confiado y celebratorio, no burocrático. El jersey es el héroe de la pantalla. Modo claro por defecto — se usa en interiores iluminados y a veces a contraluz de un aparador. ## 2. Requisitos Técnicos y de UI - Estrictamente mobile-first. Diseña a 390px y deja que escale. - La previsualización del jersey es el corazón del producto. Al cliente le han dicho durante años que "es muy complicada". Debe actualizarse en vivo mientras el usuario teclea y soportar las cuatro plantillas. Resuélvela con SVG, y el texto curvo con sobre un arco real, no simulando la curva con letras rotadas una por una. - Sin scroll horizontal jamás. La acción de confirmar vive en una barra fija inferior que respeta el área segura del dispositivo. - Las acciones irreversibles nunca quedan al alcance natural del pulgar sin una confirmación explícita. ## 3. Entregables Esperados (en este orden exacto) 1. Arquitectura de la Información: rutas del flujo completo, del escaneo al comprobante. Incluye los estados de error: QR vencido, QR ya usado, orden ya capturada. 2. Design System: consume el del bloque común. Documenta SOLO lo propio de esta superficie: tamaño del input de nombre, tratamiento del contador de caracteres, y cómo se ve un carácter no disponible. 3. User Flow Principal (Happy Path): escanea QR → valida token → elige tipo (Auténtico / Oficial / Genérico) → captura nombre y número → ve la previsualización en vivo → acepta explícitamente → recibe folio y tiempo estimado. Documenta también el camino alternativo crítico: el cliente teclea un carácter cuyo material está agotado en esa sucursal. El sistema lo marca en el propio input, explica por qué, y deshabilita la confirmación. 4. Wireframe Detallado: disposición espacial de la pantalla de captura y previsualización. Header, lienzo del jersey, bloque de formulario, contador de límite, selector de plantilla y barra fija de acción. 5. Prototipo funcional en prototipos/prototipo-02/ siguiendo la arquitectura de entrega del bloque común. Debe incluir el SVG con texto curvo real, el input forzando mayúsculas, el contador de caracteres y un carácter marcado como no disponible para demostrar el bloqueo. ## Decisiones ya tomadas — no las preguntes - Tres tipos de personalización: Auténtico, Oficial, Genérico. - El texto va en mayúsculas y conserva acentos y signos. - No hay login: el token del QR es la única credencial, y expira. - El tiempo estimado de entrega se calcula y se muestra al confirmar. Si algo te bloquea de verdad, haz máximo 2 preguntas antes de empezar. Si no, empieza directo por el punto 1. ``` --- # PROMPT B — Colaborador: bandeja de órdenes ``` [Pega aquí el BLOQUE COMÚN] Entrega en: prototipos/prototipo-01/ ← YA CONSTRUIDO Úsalo como referencia de acabado. Si te piden extenderlo, respeta sus tokens y su estructura en lugar de rehacerlo. ## 1. Contexto y Audiencia Objetivo de negocio: eliminar los tickets físicos. Hoy las órdenes se imprimen en papel, se apilan en una mesa, se caen, se pierden entre turnos y se tiran por error. Un cliente llegó a recoger un jersey que nadie sabía que estaba pendiente. Además el colaborador no sabe cuánto tarda realmente la fila: en el mundial decía "tres días" cuando el cálculo real eran seis horas, y perdía la venta. Usuario final: colaborador de tienda, de pie frente a un plotter, en tablet o PC, turnos de ocho horas, alta rotación de personal y capacitación mínima. Varios colaboradores comparten el mismo tablero en el mismo turno. Tono: operativo y denso, legible de un vistazo a un brazo de distancia. Modo claro por defecto con alternancia a oscuro, porque el área de impresión suele estar muy iluminada pero los turnos son largos. ## 2. Requisitos Técnicos y de UI - Desktop y tablet primero, de 1024px hacia arriba. Debe degradar con dignidad a 768px colapsando el sidebar a solo íconos. - La bandeja es el producto: tabla densa con filtros combinables, contadores por estado que funcionan como filtro, y panel lateral de detalle. - Toda acción frecuente se alcanza en un toque. Nada de menús anidados. - Áreas táctiles de 48px. - Estados sin ambigüedad: color, ícono y etiqueta, siempre los tres. ## 3. Entregables Esperados (en este orden exacto) 1. Arquitectura de la Información: navegación de la vista de tienda, rutas y vistas secundarias — detalle de orden, recepción de material, conteo rápido. 2. Design System: consume el del bloque común. Documenta SOLO lo propio: anatomía de la fila de orden, codificación visual de prioridad, y el tratamiento del indicador de tiempo de fila. 3. User Flow Principal (Happy Path): entra una orden confirmada por el cliente → aparece en la bandeja con su posición y tiempo estimado → el colaborador la toma y pasa a En proceso → imprime → la marca como terminada → se descuenta el material. Documenta también: subir una orden a urgente, y qué ve el colaborador cuando una orden se quedó sin material. 4. Wireframe Detallado: header con indicadores del turno, sidebar, tira de estados, barra de filtros, tabla y panel de detalle. 5. Prototipo funcional en prototipos/prototipo-01/, con al menos 20 órdenes repartidas entre todos los estados, una urgente, una bloqueada por falta de material, el desglose de consumo carácter por carácter en el detalle, y el indicador de tiempo estimado de la fila en el pie de la tabla. ## Decisiones ya tomadas — no las preguntes - Estados: Pendiente cliente, Confirmada, En cola, En proceso, Bloqueada, Terminada, Entregada. - Prioridades: Urgente (para hoy), Normal, Programada. - El tiempo estimado sale de la fila real por minutos por pieza entre colaboradores en turno. Arranca en 15 min por pieza y se calibra con los tiempos reales observados. - El descuento de material ocurre al imprimir, no al confirmar. Si algo te bloquea de verdad, haz máximo 2 preguntas antes de empezar. Si no, empieza directo por el punto 1. ``` --- # PROMPT C — Analista: inventario, mermas y rotación ``` [Pega aquí el BLOQUE COMÚN] Entrega en: prototipos/prototipo-03/ ## 1. Contexto y Audiencia Objetivo de negocio: dar visibilidad del material que hoy no existe en ningún sistema. El vinil no se recibe ni se registra en tienda: llega por paquetería y se deja en el área de impresión. Conocer las existencias cuesta dos semanas al mes entre una convocatoria por Forms, un Excel que hay que depurar y llamadas tienda por tienda. Las tiendas avisan que se quedaron sin material cuando ya están en cero y con el cliente enfrente. Cada quien mide los rollos a su manera: unos los pasan por el plotter, otros los extienden en el pasillo. Usuario final: analista de inventario corporativo. Monitor de escritorio, sesiones largas, alta competencia con hojas de cálculo. Es quien justifica la compra del sistema ante su dirección, así que la vista debe demostrar valor en los primeros diez segundos. Tono: corporativo y sobrio, alta densidad de datos, cero adorno. Modo oscuro por defecto con alternancia a claro para imprimir y presentar. ## 2. Requisitos Técnicos y de UI - Desktop-first, optimizado para data grids, de 1440px hacia arriba. - La tabla es el componente central: encabezado fijo, primera columna fija, ordenamiento, filtro por sucursal, enseña, país y material, y densidad conmutable. - Las cifras usan tabular-nums y alineación a la derecha. Unidades siempre visibles. - Exportación a Excel y CSV en un lugar evidente: es la salida hacia SAP y el sistema NO se integra con SAP en esta fase. Registra el archivo con su hash. - Nada de gráficas decorativas. Cada visual responde una pregunta concreta. ## 3. Entregables Esperados (en este orden exacto) 1. Arquitectura de la Información: existencias, kardex de movimientos, alertas, conteos, traspasos entre sucursales y exportaciones. 2. Design System: consume el del bloque común. Documenta SOLO lo propio: anatomía de la tarjeta de indicador, densidad de la tabla, semáforo de nivel de stock y tratamiento de las cifras negativas. 3. User Flow Principal (Happy Path): la analista abre el panel → detecta por alerta que tres tiendas están bajo el mínimo de vinil rojo → verifica que otras cinco tienen ese mismo material parado sin rotación → genera un traspaso entre sucursales en lugar de una orden de compra → exporta el movimiento para cargarlo a SAP. 4. Wireframe Detallado: header con filtros globales, sidebar, franja de indicadores, panel de alertas y tabla principal de existencias. 5. Prototipo funcional en prototipos/prototipo-03/, con la franja de indicadores, un panel de alertas con los cuatro tipos (stock mínimo, sin rotación, agotado, diferencia de conteo) y una tabla de existencias de al menos doce renglones mezclando materiales medidos en metros y en piezas. ## Decisiones ya tomadas — no las preguntes - Unidades distintas conviven: vinil réplica en metros, número oficial en piezas o paquetes. La interfaz nunca los suma. - Merma estándar: 6 personalizaciones aprovechables por metro, de 8 teóricas. - "Sin rotación" es propiedad del rollo, no del material. - Tipos de alerta: stock mínimo, sin rotación, agotado, diferencia de conteo. - No hay integración con SAP en esta fase. La salida es un archivo tabular. Si algo te bloquea de verdad, haz máximo 2 preguntas antes de empezar. Si no, empieza directo por el punto 1. ```