Diseñar interfaces que no solo se ven bien: funcionan, escalan y se entienden.
Este manual es para aprender a convertir la arquitectura UX en una interfaz visual sólida: layout, jerarquía, componentes, estados, accesibilidad, responsive, sistemas y handoff. La UI Estratégica no empieza preguntando "qué queda bonito", sino "qué decisión necesita tomar la persona y cómo la interfaz la ayuda sin fricción".
Definición interna
Cómo lo llamaría
Diseño UI Estratégico o UI Estratégica para productos digitales. Es el servicio/capacidad que convierte una estrategia UX en un sistema visual ejecutable para webs, ecommerce, apps, plataformas o dashboards.
No es decoración
La UI no es "poner color y botones". Es transformar prioridad, contenido y flujo en una interfaz legible.
Es sistema
Define reglas reutilizables: tipografía, color, espaciado, componentes, estados, patrones y criterios de uso.
Es criterio de producto
Sirve para que cada pantalla se pueda justificar: por qué esto está aquí, por qué se ve así y qué debe hacer.
Marcos de referencia
Qué sistemas conviene conocer sin volverse dependientes de ellos
El objetivo no es copiar Material, Apple o cualquier librería. El objetivo es aprender cómo piensan: fundamentos, componentes, patrones, accesibilidad, adaptabilidad y consistencia.
Material Design 3
Base útil para entender color, tipografía, layout, componentes, estados, navegación y diseño adaptativo.
Apple HIG
Muy útil para apps iOS: patrones de plataforma, comportamiento esperado, navegación y calidad percibida.
WCAG 2.2
Marco base para accesibilidad: contraste, foco, navegación, etiquetas, errores, tamaños y comprensión.
MUI / librerías
MUI es herramienta técnica para React. Puede acelerar producción, pero no sustituye el criterio visual.
Regla KOA: podemos inspirarnos en sistemas consolidados, pero cada proyecto necesita su propio criterio: marca, público, dispositivo, contexto de uso, tecnología y nivel de madurez del cliente.
Ruta visual
De UX Estratégico a UI Estratégica
La UI Estratégica empieza donde la UX ya ha puesto orden. Si no hay arquitectura, contenido ni flujo, la UI se convierte en maquillaje. Si hay estrategia, la UI puede convertirse en sistema.
Entrada
Decisión UI
Salida
Riesgo si no se hace
Arquitectura UX
Mapa de páginas, pantallas, flujos y prioridades.
Layout y jerarquía
Qué se ve primero, cómo se agrupa y cómo progresa la lectura.
Wireframes UI-ready
Frames con estructura visual clara y zonas funcionales.
Pantallas bonitas pero confusas
Diseño estético sin lectura ni foco.
Identidad de marca
Personalidad, tono, recursos visuales, nivel de energía.
Dirección visual
Color, tipo, iconografía, estilo de cards, motion, density.
Estos steps sirven tanto para aprender internamente como para ejecutar proyectos reales. Cada fase debe producir decisiones visibles, no solo inspiración.
00
Inputs antes de diseñar
UX, marca, tecnología, contexto de uso y límites reales del proyecto.
Teoría clave
Una buena UI nace de restricciones claras. Antes de abrir Figma hay que saber qué tipo de producto estamos diseñando, quién lo usará, en qué contexto, qué tecnología lo soportará y qué decisiones UX ya están tomadas.
Tipo de producto: web corporativa, ecommerce, app, SaaS, dashboard, landing o área privada.
Contexto de uso: móvil rápido, escritorio de trabajo, compra comparativa, consulta recurrente, gestión compleja.
Nivel de sistema: pieza única, plantilla replicable, producto vivo o design system completo.
¿Qué pantalla o página sostiene más conversión o valor?
¿Qué debe entender la persona en menos de 5 segundos?
¿Qué componentes se van a repetir?
¿Dónde puede romperse el diseño cuando haya mucho contenido?
¿Qué partes deben poder editarse por el cliente?
01
Fundamentos visuales
Color, tipografía, espaciado, retícula, radios, sombras, iconos y motion.
Qué se define
Los fundamentos son las decisiones invisibles que hacen que una interfaz parezca sólida. No se definen para decorar, sino para reducir improvisación.
Color: roles, no solo paleta. Primario, superficie, borde, texto, error, éxito, aviso.
Tipografía: escala, peso, altura de línea, uso en headings, cuerpo, labels, ayudas y datos.
Espaciado: sistema modular para que todo respire con coherencia.
Forma: radios, bordes, sombras y densidad visual.
Iconografía: estilo, tamaño, grosor, función y cuándo no usar iconos.
Motion: transiciones con propósito, no animaciones por postureo.
Principio: si una decisión visual no se puede repetir, probablemente no es sistema; es ocurrencia.
Mini pantalla: cada pieza debe venir de un sistema de roles, no de decisiones aisladas.
02
Layout, responsive y diseño adaptativo
Diseñar cómo se organiza la interfaz según espacio, dispositivo y densidad.
Teoría clave
Responsive no es "que quepa en móvil". Es decidir cómo cambia la jerarquía cuando cambia el contexto. En una app o producto, el layout debe contemplar navegación, acciones principales, lectura, densidad de información y zonas de interacción.
Mobile first: obliga a priorizar lo esencial.
Breakpoints con intención: no solo 768/1024; pensar en contenido, no en dispositivos genéricos.
Densidad: una landing emocional no necesita la misma densidad que un dashboard.
Escaneabilidad: agrupaciones, headings, cards, ritmo y zonas de descanso visual.
Navegación: tabs, bottom nav, sidebar, breadcrumbs, filtros o buscador según uso.
Web
App
Dashboard
Lectura + conversión
Hero, bloques, prueba, CTA, formulario, SEO y contenido largo.
Tarea + hábito
Flujos cortos, navegación persistente, estados, feedback y retorno.
Datos + control
Tablas, filtros, paneles, jerarquía de datos y acciones masivas.
03
Componentes y patrones
Botones, formularios, cards, navegación, modales, tablas, filtros y mensajes.
Teoría clave
Un componente no es solo una pieza visual. Es una decisión funcional reutilizable. Debe incluir anatomía, variantes, estados, reglas de uso, contenido permitido y comportamiento.
Anatomía: qué partes lo componen.
Variantes: primary, secondary, ghost, destructive, compact, full width.
Contenido: límites de texto, iconos, ayudas, mensajes.
Accesibilidad: foco, contraste, labels, touch target y navegación por teclado.
Estados mínimos de un botón
Default
Hover
Focus
Loading
Disabled
Error
04
Pantallas clave y patrones de producto
Home, landing, ficha, checkout, onboarding, dashboard, ajustes y estados vacíos.
Teoría clave
La UI estratégica diseña patrones completos, no pantallas sueltas. Hay que pensar qué necesita una persona en cada momento: comprender, comparar, decidir, introducir datos, corregir, confirmar, esperar o volver.
Onboarding: explicar valor y reducir miedo antes de pedir esfuerzo.
Formularios: una pregunta por grupo, ayudas cerca del campo, errores accionables.
Checkout/reserva: claridad de pasos, resumen persistente y cero sorpresas.
Dashboard: datos jerarquizados por acción, no solo por disponibilidad.
Empty states: explicar qué pasa y cuál es el siguiente paso.
Error states: reconocer el problema, decir cómo resolverlo y no culpar al usuario.
Estado
Pregunta UI
Debe incluir
Carga
¿La persona sabe que algo está pasando?
Feedback
Skeleton, spinner, texto de espera o progreso.
Tiempo percibido
Comunicar sin bloquear más de lo necesario.
Vacío
¿Sabe por qué no hay contenido?
Orientación
Explicación breve + acción recomendada.
Próximo paso
CTA, ejemplo, ayuda o importación.
Error
¿Puede recuperarse sin frustración?
Solución
Mensaje claro, campo afectado, reintento.
Humanidad
Sin culpa, sin códigos raros, sin callejones.
05
Accesibilidad y calidad de interacción
Contraste, foco, tamaño, navegación, lectura, errores y consistencia.
Teoría clave
La accesibilidad no es una capa final. Es parte del criterio UI. Una interfaz que no se puede leer, navegar, tocar o entender no está bien diseñada, aunque sea preciosa.
Perceptible: suficiente contraste, texto alternativo, no depender solo del color.
Operable: foco visible, navegación por teclado, zonas táctiles cómodas.
Robusta: estructura compatible con diferentes navegadores, tecnologías y lectores.
Checklist de mínimos
Contraste de texto suficiente en todos los fondos.
Estados de foco visibles, no eliminados por CSS.
Labels persistentes en formularios; no solo placeholder.
Errores cerca del campo y con solución concreta.
Iconos acompañados de texto cuando la acción no sea universal.
Áreas táctiles cómodas en móvil y separación suficiente.
06
Design system, Figma y handoff
Variables, estilos, componentes, documentación, specs y criterios para desarrollo.
Teoría clave
Un sistema UI no tiene que ser enorme. Tiene que ser suficiente para que el diseño se pueda repetir sin perder calidad. En Figma, esto se traduce en variables, estilos, componentes, variantes, autolayout, nomenclatura y documentación.
Variables: color, spacing, radius, si procede modos claro/oscuro.
Text styles: jerarquía tipográfica completa y consistente.
Handoff: notas de comportamiento, responsive, estados y assets exportables.
Entrega ideal KOA
No entregar solo pantallas finales. Entregar una mini biblioteca que permita entender cómo se ha construido la interfaz: fundamentos, componentes, patrones, pantallas clave y documentación para implementar.
Recurso visual
Mapa de design tokens
Los tokens son valores reutilizables. Hacen que una interfaz pueda crecer sin que cada pantalla parezca de un padre y una madre.
Para KOA, un componente está completo cuando se entiende visualmente, se puede usar en distintos contextos, contempla estados y puede desarrollarse sin adivinar.
1. Anatomía
Contenedor
Texto principal
Texto auxiliar
Icono opcional
Acción principal/secundaria
2. Variantes
Tamaño: sm/md/lg
Prioridad: primary/secondary
Uso: informativo/comercial/crítico
Densidad: compact/comfortable
3. Estados
Default
Hover / pressed
Focus visible
Loading
Disabled
Error / success
Anatomía visual · Variantes y estados de botón
Sí
Diseñar componentes con reglas: cuándo se usan, qué texto admiten, qué variantes existen y cómo se comportan.
No
Duplicar una card o botón cada vez que "no encaja", porque eso destruye el sistema y complica el desarrollo.
Fundamento
Tipografía en UI: más que elegir una fuente
La tipografía es el componente más usado y el más ignorado. No se trata de elegir una fuente bonita: se trata de construir un sistema de roles que permita leer, escanear y entender sin esfuerzo.
Escala tipográfica
Una escala bien definida elimina la improvisación. Cada tamaño tiene un rol, un peso y un uso concreto.
Rol
Tamaño aprox.
Peso
Uso
Display / Hero
2.5–4rem
700–800
Títulos de sección o página de impacto.
H1
1.8–2.6rem
700–750
Título principal de página.
H2
1.35–1.85rem
700
Secciones o módulos.
H3
1rem–1.15rem
650–700
Bloques internos, cards.
Body
0.875rem–1rem
400
Texto de lectura.
Small / Caption
0.75–0.82rem
400–500
Labels, ayudas, metadatos.
Tiny / Label
0.65–0.72rem
600–800
Tags, badges, kickers, categorías.
Jerarquía tipográfica en la práctica
Máx. 2 familias tipográficas por interfaz. Una para títulos (con personalidad), otra para cuerpo (legibilidad).
Contraste de peso, no de tamaño. Un 700 sobre 400 crea más jerarquía que solo subir px.
Tracking negativo en titulares grandes (–0.03em a –0.05em): más apretado = más impacto y modernidad.
Line-height: 1.1–1.2 en titulares, 1.5–1.65 en cuerpo. Más apretado en displays, más abierto para leer.
Medida de línea: 60–75ch en cuerpo de texto. Más largo = fatiga de lectura.
Nunca usar más de 3 tamaños en una sola pantalla si no hay razón visual clara.
Color en tipografía
Color primario (100% opacidad): títulos y texto de acción crítica.
Color ink (~85–90%): cuerpo de lectura.
Color muted (~55–65%): texto auxiliar, metadatos, ayudas.
Nunca texto gris claro sobre fondo blanco sin comprobar contraste.
El contraste mínimo AA es 4.5:1 para texto normal, 3:1 para texto grande.
Geométrica + Humanista: moderna y legible. Ej: Sora + Source Sans.
Variable font solo: un weight range amplio permite jerarquía con una sola familia. Ej: Gordita, Inter Variable.
Display expresa + Neutral body: ej: Clash Display + DM Sans. Titulares con carácter, cuerpo sin ruido.
Errores comunes a evitar
Usar cursiva decorativa donde se necesita legibilidad.
Centrar texto de más de 3 líneas (fatiga de lectura).
Mezclar fuentes sin escala ni sistema: "tipografía accidente".
Todo en mayúsculas salvo labels o tags muy cortos.
Subrayar texto que no es enlace.
Placeholder como única etiqueta de formulario.
Principio KOA: la tipografía de una interfaz está bien cuando puedes ver la pantalla a 50% y aún entiendes qué es lo más importante sin leer nada.
Recurso visual · Escala de jerarquía
DisplayTítulo de impacto
H1Título de página
H2Sección o módulo
H3Bloque interno · Card
BodyTexto de lectura corriente. Altura de línea 1.55.
SmallLabel auxiliar, metadato, ayuda
TinyTAG · KICKER · BADGE
Recurso visual · Pesos y contraste
Display
H1
H2
Body
Small
Recurso visual · Contraste de color en texto
✓ 14.5:1Texto sobre oscuro
✓ 12.6:1Texto sobre blanco
✓ 5.2:1Texto sobre purple
✗ 2.1:1Falla WCAG AA
Webs y apps
Diferencias clave al diseñar UI para web y para app
Muchas reglas se comparten, pero el contexto cambia: una web suele combinar descubrimiento, contenido y conversión; una app suele vivir más cerca de la tarea, la recurrencia y la interacción táctil.
La percepción humana no es neutral. El cerebro tiene atajos, patrones y reacciones automáticas ante el estímulo visual. Conocerlos permite diseñar interfaces que guían sin forzar.
Leyes de la Gestalt
Proximidad: elementos cercanos se perciben como grupo. Úsalo para agrupar información relacionada.
Similitud: formas, colores o pesos iguales = misma categoría. Romper similitud = énfasis.
Continuidad: el ojo sigue líneas y flujos. El layout debe guiar la mirada, no cortarla.
Cierre: el cerebro completa formas incompletas. Útil para iconos y UI minimalista.
Figura / Fondo: separar lo interactivo de lo estructural para que todo tenga su plano.
Principios cognitivos clave
Ley de Hick: más opciones = más tiempo de decisión. Reducir el número de acciones visibles simultáneas.
Ley de Fitts: objetos más grandes y cercanos son más fáciles de tocar. Los CTAs deben ser cómodos.
Carga cognitiva: el cerebro tiene capacidad limitada. Simplificar = facilitar.
Efecto serial: se recuerda mejor lo primero y lo último de una lista. Pon lo importante ahí.
Von Restorff: lo diferente se recuerda. Un elemento que rompe el patrón llama la atención.
El contexto cultural importa. El blanco en cultura occidental = limpieza; en Asia puede = duelo.
Jerarquía visual y la mirada
El ojo sigue patrones predecibles en pantalla:
Patrón F: en páginas de texto y listados, la mirada escanea en F. Pon lo importante arriba a la izquierda.
Patrón Z: en layouts simples con pocos elementos, la mirada sigue una Z. Típico en landings.
Punto de entrada: el primer elemento grande, de alto contraste o diferente capta la atención primero.
Peso visual: elementos oscuros, grandes o saturados pesan más y anclan la vista.
Sesgos de diseño a aprovechar (con ética)
Social proof: ratings, testimonios y contadores de usuarios reducen fricción de decisión.
Escasez y urgencia: "solo quedan 3" o "oferta hasta hoy". Aumenta conversión, pero no abusar.
Compromiso progresivo: pedir poco al principio y más después. Ej: onboarding en pasos.
Default inteligente: pre-seleccionar la opción que beneficia al usuario más frecuente reduce fricción.
Reciprocidad: dar valor antes de pedir (ebooks, herramientas gratuitas) genera predisposición positiva.
El ojo sigue forma de F en páginas de texto
Patrón Z típico en landings y heroes simples
Ética en persuasión visual: hay patrones que manipulan (dark patterns): ocultar cancelaciones, hacer el "no" difícil de encontrar, crear urgencia falsa. En KOA no los usamos, pero sí los identificamos y alertamos al cliente.
UX Writing
Microcopy y UX Writing: las palabras son parte del diseño
El texto de una interfaz no es un relleno: es parte del diseño. Labels, mensajes de error, textos de botones y estados vacíos comunican tanto como el color o la tipografía. Un buen microcopy reduce soporte, aumenta conversión y genera confianza.
Principios de buen microcopy
Claro antes que creativo: el usuario quiere saber qué hace ese botón, no que seas ingenioso.
Activo y directo: "Guardar cambios" mejor que "Procesando tu solicitud de almacenamiento".
Sin jerga técnica a menos que el usuario sea técnico.
En primera persona del usuario para acciones: "Mi cuenta", "Ver mis pedidos".
Consistente: si dices "Continuar" en el paso 1, no pongas "Siguiente" en el paso 2.
Sin mayúsculas innecesarias en frases completas. Solo en labels cortos o inicios de oración.
Textos de botones
Verbos de acción: Enviar, Guardar, Crear, Continuar, Confirmar, Descargar.
Específicos: "Reservar mesa" mejor que "Confirmar". "Crear cuenta gratis" mejor que "Registrarse".
El botón destructivo debe advertir: "Eliminar cuenta" no "Aceptar".
El botón de carga debe cambiar: "Guardando…" mientras procesa.
CTAs secundarios: más suaves y sin el peso visual del primario.
Mensajes de error
Explicar QUÉ pasó, no solo que pasó algo.
Decir QUÉ puede hacer el usuario para resolverlo.
No culpar al usuario: "El email no es válido" mejor que "Error en el campo".
No usar códigos internos visibles: "Error 500" no ayuda a nadie.
Posicionar el error cerca del campo afectado, no arriba de todo.
Tono humano: no robótico ni alarmista.
Estados vacíos bien escritos
Un empty state bien diseñado incluye tres partes:
Qué está pasando: "Aún no tienes ningún proyecto."
Por qué puede importarle: "Crea tu primer proyecto para empezar a colaborar con tu equipo."
Qué puede hacer ahora: CTA claro. "Crear proyecto →"
Los empty states son oportunidades de onboarding oculto. Aprovéchalos.
Tooltips, placeholders y ayudas
Placeholder: ejemplo del formato esperado, no una descripción del campo. Ej: "ej. hola@koaestudio.com"
Label persistente: siempre encima del campo, no como placeholder que desaparece.
Helper text: una línea debajo del campo con formato esperado o restricción. "8 caracteres mínimo."
Tooltip: para aclarar términos no obvios, no para sustituir un label o un title.
Confirmación: tras una acción irreversible, el mensaje debe confirmar qué pasó y qué viene ahora.
Sí
"Tu contraseña debe tener al menos 8 caracteres, una mayúscula y un número."
"No hemos podido procesar el pago. Revisa los datos de tu tarjeta."
"¡Listo! Tu pedido llegará entre el 18 y el 20 de mayo."
No
"Campo incorrecto." (sin más información)
"Error al procesar. Código: PAYMENT_DECLINED_03"
"Operación completada satisfactoriamente." (robótico y frío)
Interacción
Motion y microinteracciones: la UI que responde
Las animaciones no son decoración. Son información. Una transición dice "aquí está pasando algo"; un micro-feedback dice "la acción funcionó". El movimiento con propósito reduce incertidumbre y hace que el producto se sienta vivo.
Cuándo usar motion
Feedback de acción: un botón que reacciona al hacer clic confirma que algo ocurrió.
Las herramientas no hacen al diseñador, pero el diseñador que conoce bien su stack toma mejores decisiones y entrega más rápido. Aquí están las que más valor aportan en el trabajo real de KOA.
Diseño y prototipado
Herramienta
Cuándo usarla
Figma
Diseño de sistemas UI, prototipado, handoff, variables y colaboración en tiempo real. La herramienta principal.
FigJam
Brainstorming, arquitectura de información, customer journey y flujos de usuario.
Figma Slides
Presentaciones de concepto o propuestas visuales a cliente.
Framer
Prototipos high-fidelity con interacciones avanzadas. También se usa para publicar webs desde diseño.
Whimsical
Wireframes rápidos, flowcharts y mapas de sitio cuando no hace falta fidelidad visual.
Handoff, especificación y desarrollo
Herramienta
Para qué
Figma Dev Mode
Inspección de specs, assets, tokens y CSS para desarrollo.
Zeroheight / Supernova
Documentación viva del design system: tokens, componentes y guidelines.
Storybook
Librería de componentes en código para equipos técnicos.
Lottie / Rive
Exportar animaciones diseñadas en After Effects o Rive para web y app.
Notion / Confluence
Documentación interna de proyecto, brief de diseño y decisiones.
Utilidades de diseñador UI
Herramienta
Uso
Coolors / Realtime Colors
Generar y probar paletas de color con roles semánticos en tiempo real.
Contrast (app)
Verificar ratios de contraste WCAG directamente en Mac.
Librerías de iconos coherentes, escalables y accesibles.
Unsplash / Pexels
Imágenes de referencia para mockups (no para producción sin licencia).
Muzli / Mobbin
Inspiración real de UI de apps y webs existentes.
Plugins de Figma imprescindibles
Plugin
Para qué
Contrast
Verificar ratios WCAG sin salir de Figma.
Tokens Studio
Gestionar design tokens y sincronizar con código.
Iconify
Acceder a miles de iconos desde Figma.
Unsplash
Insertar fotos reales directamente en mockups.
Content Reel
Rellenar diseños con contenido real (nombres, emails, avatares).
Stark
Simulación de daltonismo y comprobación de accesibilidad.
Breakpoints
Previsualizar diseños responsive sin salir de Figma.
Criterio KOA para elegir herramientas: la herramienta correcta es la que el equipo entiende bien, permite colaborar con el cliente y puede traducirse a código real. El stack más sofisticado que nadie usa bien no sirve de nada.
QA visual
Checklist de revisión antes de enseñar o entregar
Esta es la capa que evita que un diseño parezca bueno en Figma pero falle al llevarlo a producción.
Jerarquía
¿Se entiende qué mirar primero?
¿El CTA principal destaca sin gritar?
¿Hay demasiados pesos compitiendo?
¿Los bloques tienen ritmo?
¿La escala tipográfica es coherente en toda la pantalla?
¿Hay un punto de entrada claro en cada sección?
Consistencia
¿Los botones iguales hacen lo mismo?
¿Los espaciados siguen escala?
¿Los iconos tienen el mismo estilo?
¿Las cards comparten estructura?
¿Los colores de feedback son coherentes?
¿Los textos de CTA son consistentes entre pantallas?
Robustez
¿Funciona con textos largos?
¿Hay estado vacío y error?
¿Está resuelto en móvil?
¿Se puede desarrollar sin inventar?
¿Se contempla el estado de carga?
¿Funciona sin imagen si esta no carga?
Accesibilidad
¿El contraste de texto cumple AA (4.5:1)?
¿Los estados de foco son visibles?
¿Los iconos sin texto tienen aria-label?
¿Los errores no dependen solo del color?
¿Los touch targets son ≥ 44×44px?
¿Los formularios tienen labels persistentes?
Microcopy
¿Los botones usan verbos de acción?
¿Los errores explican la solución?
¿Los empty states tienen un próximo paso?
¿Los placeholders son ejemplos, no labels?
¿El tono es consistente con la marca?
¿No hay jerga técnica sin explicar?
Motion y feedback
¿Las acciones dan feedback visual inmediato?
¿Las duraciones son adecuadas (no demasiado lentas)?
¿Se implementa prefers-reduced-motion?
¿Los loaders no bloquean el contenido innecesariamente?
¿Los estados de transición son suaves y coherentes?
Prueba KOA de los 3 zooms: revisar la pantalla al 50% para jerarquía, al 100% para lectura real y en móvil para prioridad. Si solo funciona en desktop grande, no está cerrada.
Plantillas KOA
Plantillas descargables en PDF
Herramientas listas para usar en proyectos reales. Descarga, imprime o comparte con el equipo o el cliente.
Canvas de dirección UI
Tres preguntas clave por eje: marca, producto y usuario. Para definir el criterio visual antes de abrir Figma.
Checklist QA visual
Lista de revisión completa antes de entregar un diseño: jerarquía, consistencia, accesibilidad, microcopy y responsive.
Especificación de componente
Plantilla estructurada para documentar cualquier componente: anatomía, variantes, estados, reglas y notas de desarrollo.
Scorecard UI KOA
Evalúa la calidad de un diseño con 5 criterios puntuados de 0 a 2: jerarquía, consistencia, accesibilidad, responsive y handoff.
Mapa de design tokens
Plantilla para definir tokens base y semánticos: color, spacing, radius, shadow y tipografía con roles y ejemplos de uso.
Brief de proyecto UI
Documento de inicio para cualquier proyecto UI: tipo de producto, contexto, restricciones técnicas, marca y objetivos del diseño.
Cómo usarlas: descarga el PDF, imprímelo o ábrelo en Figma como referencia. Cada plantilla está pensada para rellenarse en taller con el cliente o de forma interna antes de empezar el diseño.
Recursos internos
Plantillas visuales para trabajar UI Estratégica
Estos recursos pueden convertirse luego en plantillas de Figma, Notion o Canva para sistematizar el servicio.
Canvas de dirección UI
Marca
Producto
Usuario
¿Qué energía visual necesita proyectar?
¿Qué tipo de tarea sostiene?
¿Qué nivel de conocimiento tiene?
¿Qué recursos visuales son propios?
¿Qué componentes se repiten?
¿Qué dudas o miedos aparecen?
Matriz: sistema vs custom
Situación
Decisión
App interna, dashboard o SaaS
Partir de sistema robusto tipo Material, Carbon, Fluent o librería técnica.
Marca editorial/comercial muy diferencial
Diseño custom con componentes propios y reglas claras.
Cliente con poco presupuesto técnico
Usar patrones estándar y personalizar solo lo que aporte valor.
Producto que crecerá mucho
Invertir más en tokens, componentes y documentación.
Plantilla de especificación de componente
Nombre del componente.
Función dentro del producto.
Anatomía.
Variantes.
Estados.
Reglas de uso.
Contenido permitido.
Notas responsive.
Notas de accesibilidad.
Scorecard UI KOA
Criterio
0
1
2
Jerarquía
Confusa
Correcta
Muy clara
Consistencia
Aislada
Parcial
Sistemática
Accesibilidad
No revisada
Básica
Integrada
Responsive
Adaptado tarde
Funciona
Diseñado por contexto
Handoff
Visual
Con notas
Operativo
Cómo explicarlo
Frases copiables para venderlo sin humo
Útiles para propuestas, llamadas o páginas internas de servicio.
La UI Estratégica no consiste en vestir una pantalla, sino en construir un sistema visual que ayude al usuario a entender, decidir y avanzar.
Diseñamos interfaces que respetan la marca, pero también la usabilidad: jerarquía, contraste, estados, responsive, accesibilidad y componentes reutilizables.
Una pantalla no está terminada cuando se ve bonita; está terminada cuando contempla qué pasa si carga, falla, no hay datos, el texto crece o el usuario necesita ayuda.
El objetivo es que el diseño no dependa de intuiciones sueltas, sino de reglas claras que el equipo pueda repetir y desarrollar.
El texto de una interfaz no rellena el diseño: es parte del diseño. Un botón bien escrito convierte más que uno mal etiquetado, sin importar lo bonito que sea.
Accesibilidad no es un checklist que se pasa al final. Es una forma de diseñar que hace que el producto funcione para más personas, en más contextos y con más garantías legales.
No entregamos solo pantallas finales. Entregamos un sistema que el equipo de desarrollo puede implementar y que el cliente puede entender: componentes, estados, reglas y documentación.
Un buen diseño UI se nota cuando nada llama la atención de forma innecesaria. La invisibilidad del sistema es el mayor indicador de que funciona bien.
Resumen KOA
La frase que resume todo
UX decide el camino. UI hace que ese camino se pueda leer, tocar, entender y repetir.
Claridad
Que el usuario sepa dónde está, qué puede hacer y qué pasará después.
Consistencia
Que las reglas visuales no cambien sin motivo y el producto pueda crecer.
Calidad
Que la interfaz contemple estados, accesibilidad, responsive y handoff real.
Fuentes base recomendadas para profundizar:Material Design 3: foundations, adaptive design y components · Apple Human Interface Guidelines · WCAG 2.2 · MUI Material UI · Figma Variables · Carbon Design System (IBM) · Fluent 2 (Microsoft) · Atlassian Design System · Polaris (Shopify) · Lightning Design System (Salesforce) · Primer (GitHub) · Radix UI · Headless UI.
Lecturas y recursos de referencia:«Refactoring UI» — Adam Wathan & Steve Schoger · «Don't Make Me Think» — Steve Krug · «The Design of Everyday Things» — Don Norman · «Laws of UX» — Jon Yablonski (lawsofux.com) · «Inclusive Design Patterns» — Heydon Pickering · Nielsen Norman Group (nngroup.com) · Smashing Magazine · CSS-Tricks · Every Layout (every-layout.dev) · Mobbin (mobbin.com) · Muzli Design Inspiration.