KOA · Manual interno de UI Estratégica
UI Estratégica

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.

UI Kit inicial

Fundamentos visuales coherentes con la marca.

Marca forzada en interfaz

Look bonito pero poco usable o poco escalable.

Necesidades técnicas

CMS, app nativa, React, WordPress, ecommerce, dashboard.

Componentización

Qué piezas se repiten y cómo se documentan.

Sistema operativo

Componentes, estados, reglas y handoff.

Diseño imposible de desarrollar

Entrega visual sin lógica técnica ni estados.

ESTRATEGIA UX · Arquitectura FUNDAMENTOS Color · Tipo · Tokens COMPONENTES Sistema · Variantes PANTALLAS Flujos · Estados HANDOFF Specs · Documentación

Flujo completo: de la estrategia UX al handoff UI

Steps de aprendizaje y ejecución

Proceso completo de UI Estratégica

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.
  • Restricciones: Elementor, Shopify, WooCommerce, app nativa, React, Bootstrap, MUI, equipo interno.

Preguntas KOA

  • ¿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.
  • Estados: default, hover, focus, active, disabled, loading, error, success, empty.
  • Reglas: cuándo se usa y cuándo no.
  • 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.
  • Comprensible: labels claros, errores útiles, lenguaje directo.
  • 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.
  • Components: botones, inputs, cards, nav, accordions, modals, chips, alerts.
  • Variants: estados y tamaños.
  • Auto layout: diseño flexible, no estático.
  • 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.

Tokens base

Color

Roles: texto, superficie, borde, acción, feedback.

Spacing

Escala 4/8/12/16/24/32/48 según densidad.

Radius

Pequeño para inputs, medio para cards, alto para módulos editoriales. No mezclar sin criterio.

Shadow

Usar para jerarquía o elevación real; no para "decorar todo".

Tokens semánticos

TokenUsoEjemplo
color.action.primaryCTA principalBotón de compra, continuar, enviar
color.surface.raisedCard elevadaPanel, resumen, modal
color.feedback.errorErrorInput inválido, alerta crítica
space.section.mdSeparación entre bloquesLanding, página servicio
radius.component.mdComponentesInputs, cards, selects

Recurso visual · Escala de espaciado

sp-4
4pxGap mínimo, icono+texto
sp-8
8pxPadding de tags, chips, badges
sp-12
12pxPadding botones compactos
sp-16
16pxPadding estándar de componentes
sp-24
24pxSeparación entre bloques
sp-32
32pxSeparación entre secciones
sp-48
48pxSeparación entre módulos principales

Recurso visual · Roles de color

color.text.primaryTítulos, texto principal, contenido crítico
color.text.secondaryTexto auxiliar, metadatos, placeholders
color.action.primaryCTA principal, enlaces, interactivos
color.surface.defaultFondo general de página
color.surface.raisedCards, modales, paneles elevados
color.feedback.successConfirmaciones, estados positivos
color.feedback.errorErrores, alertas críticas
color.feedback.warningAvisos, confirmaciones reversibles
Componentes

Anatomía de un componente bien diseñado

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
PRIMARY SECONDARY DISABLED ESTADOS: Default Hover Focus Loading Disabled Error Success

Anatomía visual · Variantes y estados de botón

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.

RolTamaño aprox.PesoUso
Display / Hero2.5–4rem700–800Títulos de sección o página de impacto.
H11.8–2.6rem700–750Título principal de página.
H21.35–1.85rem700Secciones o módulos.
H31rem–1.15rem650–700Bloques internos, cards.
Body0.875rem–1rem400Texto de lectura.
Small / Caption0.75–0.82rem400–500Labels, ayudas, metadatos.
Tiny / Label0.65–0.72rem600–800Tags, 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.

Combinaciones que funcionan

  • Serif + Sans-serif: elegancia editorial. Títulos serif, cuerpo sans. Ej: Playfair Display + DM Sans.
  • 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

Display Título de impacto
H1 Título de página
H2 Sección o módulo
H3 Bloque interno · Card
Body Texto de lectura corriente. Altura de línea 1.55.
Small Label auxiliar, metadato, ayuda
Tiny TAG · KICKER · BADGE

Recurso visual · Pesos y contraste

Display
H1
H2
Body
Small

Recurso visual · Contraste de color en texto

✓ 14.5:1 Texto sobre oscuro
✓ 12.6:1 Texto sobre blanco
✓ 5.2:1 Texto sobre purple
✗ 2.1:1 Falla 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.

CriterioWebAppDecisión UI
Objetivo habitualInformar, convencer, posicionar, convertir.Activar, retener, facilitar una tarea repetida.Web: narrativa + CTA. App: flujo + feedback constante.
NavegaciónMenús, anchors, breadcrumbs, buscador, filtros.Bottom nav, tabs, gestures, barras superiores.No copiar patrones sin contexto de plataforma.
ContenidoMás texto, SEO, argumentario, prueba social.Microcopy corto, instrucciones contextuales, estados.En app, cada palabra compite con la tarea.
InteracciónClick, scroll largo, formularios, comparación.Touch, gestos, notificaciones, permisos, biometría.Diseñar feedback táctil y estados de sistema.
EscalabilidadPlantillas y módulos editables.Componentes vivos y patrones repetidos.Documentar reglas para no romper consistencia.
Teoría aplicada

Psicología visual aplicada a la UI

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.

Color y emoción en UI

  • Azul: confianza, tecnología, calma. Fintech, salud, SaaS.
  • Verde: éxito, naturaleza, permiso. Feedback positivo, ecológico.
  • Rojo/naranja: urgencia, energía, advertencia. CTAs de presión, alertas.
  • Morado: creatividad, premium, innovación. Educación, tech, marcas diferenciales.
  • Negro/oscuro: autoridad, lujo, seriedad. Moda, editorial, high-end.
  • 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.
PATRÓN F · Texto y listados El ojo barre la primera línea, luego baja por la izquierda leyendo inicio de líneas

El ojo sigue forma de F en páginas de texto

PATRÓN Z · Landings y heroes CTA El ojo sigue una Z: inicio → fin de línea diagonal → inicio → CTA final

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.

  • "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ó.
  • Transiciones de estado: loading → success, abrir → cerrar, vacío → cargado.
  • Orientación: una página que entra desde la derecha indica que avanzas; desde la izquierda, que vuelves.
  • Entrada de contenido: fade o slide suave al aparecer elementos nuevos.
  • Atención controlada: animar solo lo que el usuario debe mirar ahora.

Duraciones y curvas

  • Micro-feedback (hover, ripple): 80–150ms. Casi imperceptible, solo confirma.
  • Transición de componente (modal, drawer): 200–300ms. Perceptible y fluido.
  • Transición de pantalla: 280–400ms. Más lento para navegar con contexto.
  • Curvas: ease-out para entradas. ease-in para salidas. ease-in-out para movimientos internos.
  • Nunca linear para movimientos de UI: parece mecánico y antinatural.

Errores comunes en motion

  • Animar todo porque se puede. El movimiento constante fatiga.
  • Duraciones demasiado lentas (>500ms) que bloquean la interacción.
  • Bounce o spring exagerados que parecen una web de 2012.
  • Animaciones que no se pueden cancelar o interrumpir.
  • Ignorar prefers-reduced-motion: hay usuarios sensibles al movimiento.
  • Usar motion para ocultar que algo tarda mucho en cargar.

Microinteracciones más útiles en UI

AcciónFeedback ideal
Clic en botónScale down sutil (0.97) + color feedback instantáneo.
Form submit con éxitoInput se vuelve verde + checkmark suave. Mensaje aparece con fade.
Error en campoShake sutil del campo + borde rojo + mensaje que aparece con slide down.
Toggle / switchThumb desliza con ease-out + cambio de color de fondo.
Copiar textoIcono cambia a "✓" brevemente + tooltip "Copiado".
Loading de páginaSkeleton loader (no spinner genérico) para preservar layout.
Like / favoritoScale pop (1 → 1.3 → 1) + cambio de color con ease-out.

Accesibilidad en motion

  • Siempre implementar @media (prefers-reduced-motion: reduce) para desactivar o reducir animaciones.
  • No usar parpadeo o flash rápido: puede causar convulsiones (WCAG 2.3.1).
  • Las animaciones de fondo en loop deben poder pausarse (WCAG 2.2.2).
  • El contenido que se mueve no debe interferir con la lectura del resto.
CSS útil: @media (prefers-reduced-motion: reduce) { * { animation-duration: 0.01ms !important; transition-duration: 0.01ms !important; } }
Stack de trabajo

Herramientas para UI Estratégica: el stack KOA

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

HerramientaCuándo usarla
FigmaDiseño de sistemas UI, prototipado, handoff, variables y colaboración en tiempo real. La herramienta principal.
FigJamBrainstorming, arquitectura de información, customer journey y flujos de usuario.
Figma SlidesPresentaciones de concepto o propuestas visuales a cliente.
FramerPrototipos high-fidelity con interacciones avanzadas. También se usa para publicar webs desde diseño.
WhimsicalWireframes rápidos, flowcharts y mapas de sitio cuando no hace falta fidelidad visual.

Handoff, especificación y desarrollo

HerramientaPara qué
Figma Dev ModeInspección de specs, assets, tokens y CSS para desarrollo.
Zeroheight / SupernovaDocumentación viva del design system: tokens, componentes y guidelines.
StorybookLibrería de componentes en código para equipos técnicos.
Lottie / RiveExportar animaciones diseñadas en After Effects o Rive para web y app.
Notion / ConfluenceDocumentación interna de proyecto, brief de diseño y decisiones.

Utilidades de diseñador UI

HerramientaUso
Coolors / Realtime ColorsGenerar y probar paletas de color con roles semánticos en tiempo real.
Contrast (app)Verificar ratios de contraste WCAG directamente en Mac.
Typescale.comGenerar escalas tipográficas modulares (Major Third, Perfect Fourth, etc.).
Iconify / Heroicons / PhosphorLibrerías de iconos coherentes, escalables y accesibles.
Unsplash / PexelsImágenes de referencia para mockups (no para producción sin licencia).
Muzli / MobbinInspiración real de UI de apps y webs existentes.

Plugins de Figma imprescindibles

PluginPara qué
ContrastVerificar ratios WCAG sin salir de Figma.
Tokens StudioGestionar design tokens y sincronizar con código.
IconifyAcceder a miles de iconos desde Figma.
UnsplashInsertar fotos reales directamente en mockups.
Content ReelRellenar diseños con contenido real (nombres, emails, avatares).
StarkSimulación de daltonismo y comprobación de accesibilidad.
BreakpointsPrevisualizar 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ónDecisión
App interna, dashboard o SaaSPartir de sistema robusto tipo Material, Carbon, Fluent o librería técnica.
Marca editorial/comercial muy diferencialDiseño custom con componentes propios y reglas claras.
Cliente con poco presupuesto técnicoUsar patrones estándar y personalizar solo lo que aporte valor.
Producto que crecerá muchoInvertir 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

Criterio012
JerarquíaConfusaCorrectaMuy clara
ConsistenciaAisladaParcialSistemática
AccesibilidadNo revisadaBásicaIntegrada
ResponsiveAdaptado tardeFuncionaDiseñado por contexto
HandoffVisualCon notasOperativo
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.