Patrones de interfaz: soluciones probadas

Un patrón de interfaz es una solución reutilizable a un problema de diseño recurrente. No inventas cómo funciona un formulario de registro cada vez que lo necesitas: aplicas el patrón establecido, lo adaptas a tu contexto y documentas las decisiones que tomaste al hacerlo.

Los patrones existen porque los usuarios han interiorizado expectativas sobre cómo funciona cada tipo de interfaz. Romperlas tiene un coste de aprendizaje real.

Formularios

Los formularios son el patrón más complejo de diseñar bien porque concentran todos los puntos de fricción: entrada de datos, validación, errores, confirmación y accesibilidad.

Principios para formularios

Un campo, un propósito. No combines nombre y apellidos en un campo si los vas a tratar por separado. No pongas nombre de empresa y cargo en el mismo input.

Etiquetas visibles siempre. Los placeholders no son etiquetas. Desaparecen cuando el usuario empieza a escribir y generan amnesia del campo: el usuario ya no sabe qué estaba rellenando. Usa siempre etiquetas visibles por encima del campo.

Validación en el momento correcto. No valides en tiempo real mientras el usuario escribe (excepto en contraseñas, para mostrar requisitos progresivamente). Valida al perder el foco (blur) o al enviar el formulario. Un error que aparece mientras escribes es agresivo.

Mensajes de error útiles. “Este campo es obligatorio” no ayuda. “Introduce tu dirección de correo (ej: nombre@empresa.com)” sí. El mensaje de error debe decir cómo corregirlo, no solo que hay un error.

Orden lógico de los campos. El usuario escanea de arriba a abajo. Los campos más importantes y esperados van primero. La información sensible (contraseña, datos de pago) va después de que el usuario haya invertido tiempo en el formulario.

Acciones del formulario. El botón de envío debe estar cerca del último campo, no perdido en otra zona de la pantalla. El botón de cancelar o descartar va después del de enviar, en secundario, y con la redacción correcta: “Cancelar”, no “No”.

Tablas

Las tablas son para datos comparables en columnas. No son para cualquier lista de items.

Principios para tablas

Alineación tipográfica.

• Texto: alineado a la izquierda.
• Números: alineados a la derecha (para que las unidades y decimales estén en la misma posición vertical).
• Booleanos e iconos: centrados.

Encabezados de columna. Siempre visibles. En tablas largas, el encabezado debe ser sticky para que el usuario sepa qué columna está leyendo al hacer scroll.

Ordenación. Si la columna es ordenable, el ícono de ordenación aparece en el encabezado. Cuando está activo, muestra claramente la dirección (ascendente/descendente).

Filas de acción. Las acciones por fila (editar, eliminar, ver detalle) van al final de la fila, en una columna de acciones o en un menú contextual (kebab menu). No mezcles acciones en distintas posiciones de la fila.

Paginación vs scroll infinito. La paginación da al usuario control y referencia (“estoy en la página 3 de 12”). El scroll infinito es mejor para feeds de consumo, peor para tablas de gestión donde el usuario necesita volver a una posición concreta.

Empty States (estados vacíos)

El estado vacío es la pantalla que se ve cuando no hay datos. Es una oportunidad de diseño que casi siempre se olvida hasta que el desarrollador pregunta “¿qué pongo aquí?”.

Tres tipos de empty state

Primera vez (zero state). El usuario acaba de entrar y todavía no ha creado nada. Es el momento ideal para guiarle hacia la primera acción y explicar qué va a conseguir cuando lo haga.

Estructura:

• Ilustración o ícono que contextualiza visualmente.
• Título: qué verá aquí cuando tenga datos.
• Subtítulo: por qué es útil o qué puede hacer.
• CTA principal: la primera acción que debe tomar.

Sin resultados (no results state). El usuario buscó algo y no hay coincidencias. La causa más común es que el usuario escribió mal o buscó por términos que el sistema no indexa.

Estructura:

• Frase que confirma que no hay resultados para esa búsqueda concreta.
• Sugerencias: ¿quizás quisiste decir X? ¿Prueba con términos más generales.
• Botón para limpiar la búsqueda o los filtros.

Sin permisos (no access state). El usuario llega a un recurso que existe pero no puede ver. No le hagas adivinar por qué no tiene acceso.

Estructura:

• Explicación clara de por qué no puede acceder.
• Acción disponible: solicitar acceso, contactar con el administrador, volver atrás.

Navegación

La navegación es el sistema que permite al usuario orientarse y desplazarse por el producto.

Tipos principales

Barra de navegación principal (navbar/sidebar): Las secciones principales del producto. En desktop se usa sidebar vertical para productos complejos y navbar horizontal para productos más simples. En móvil se usa tab bar inferior (5 ítems máximo).

Breadcrumbs: Útiles en jerarquías profundas. Muestran la ruta al estado actual y permiten volver a cualquier nivel. No son necesarios en productos sin jerarquía.

Tabs: Para cambiar entre vistas del mismo contenido o contexto. Los tabs no son para navegación entre secciones distintas del producto. Son para cambiar la vista dentro de la misma entidad (ver “Detalles”, “Actividad”, “Comentarios” de un proyecto).

Back/Breadcrumb en móvil: En móvil siempre debe haber un mecanismo claro para volver atrás. El gesto del sistema (swipe back en iOS) no es suficiente: necesita un botón visible también.

Notificaciones y feedback

El usuario necesita saber que sus acciones tuvieron efecto. Sin feedback, no sabe si algo funcionó, si está cargando o si hay un problema.

Tipos de feedback

Toast / Snackbar: Notificación no intrusiva y temporal que confirma que una acción se completó. Aparece en una posición fija (normalmente inferior central o superior derecho), dura entre 3 y 5 segundos y desaparece sola.

Úsalo para confirmaciones de acciones reversibles: “Archivo eliminado. Deshacer.” No lo uses para errores críticos: el toast puede desaparecer antes de que el usuario lo lea.

Banner / Alert: Notificación persistente que el usuario debe leer y resolver activamente. Para errores de sistema, mensajes de mantenimiento o avisos importantes.

Tipos semánticos:

• Info (azul): información contextual no urgente.
• Success (verde): confirmación de una acción importante completada.
• Warning (amarillo/naranja): algo requiere atención antes de continuar.
• Error (rojo): algo falló o hay un problema que impide avanzar.

Inline validation: Feedback en contexto, dentro del componente que lo generó. Es la forma más eficaz de mostrar errores de formulario.

Loading states: Siempre que haya una operación asíncrona, el usuario necesita saber que algo está pasando. Usa skeleton screens para cargas de contenido y spinners para acciones puntuales.

Diálogos y modales

Un modal interrumpe el flujo del usuario para pedirle atención o una decisión. Por eso deben usarse con criterio.

Cuándo usar un modal:

• Confirmación de una acción destructiva o irreversible.
• Formulario corto que no justifica una página propia.
• Información crítica que requiere acción inmediata.

Cuándo no usar un modal:

• Contenido informativo que el usuario puede ignorar (usa un tooltip u un inline banner).
• Flujos largos o complejos (usa una página o un drawer).
• En móvil para contenido extenso (usa un bottom sheet o una página nueva).

Reglas de diseño:

• El botón de cerrar (X) debe ser visible siempre.
• El fondo oscurecido (overlay) debe poder cerrarlo con clic o Escape.
• El título del modal debe comunicar claramente qué decisión se pide.
• Las acciones van siempre al final del modal: la destructiva como secundaria, la de confirmación como primaria.

¿Qué hemos aprendido?

• Los patrones reducen el coste de decisión y mantienen expectativas consistentes para el usuario.
• Los formularios requieren etiquetas visibles, validación al blur y mensajes de error útiles.
• Los empty states son una oportunidad de diseño que no se improvisa.
• El feedback inmediato y los loading states son obligatorios, no opcionales.

Siguiente paso

En la próxima lección veremos Accesibilidad: cómo integrarla en el proceso de diseño desde el principio, qué criterios son mínimos irrenunciables y qué herramientas ayudan a validarla.