Ejemplos de diseño de interfaz de sistemas públicos: botones, formularios, errores y tablas

Lee la regla detrás de cada ejemplo de diseño de interfaz

Los ejemplos de diseño de interfaz suelen ser capturas: una pantalla limpia, una paleta agradable y un pie que dice por qué es buena. La captura no puede decir qué descartó el diseñador ni qué pasó cuando usuarios reales la encontraron. Una pantalla es fácil de admirar y difícil de reutilizar, porque el lector copia el aspecto y pierde la razón.

Los sistemas de diseño públicos dan la razón por escrito. El Sistema de Diseño de GOV.UK y el Sistema de Diseño Web de EE. UU., USWDS, publican cada componente con pautas sobre cuándo usarlo, cuándo no y qué escribir dentro. Se hicieron para servicios públicos que deben funcionar para todos, así que sus reglas son conservadoras, y las reglas conservadoras son un buen primer borrador para una app de negocio. Siempre puedes aflojar una regla cuando tengas datos de tus usuarios, pero es más difícil añadir cuidado a una pantalla diseñada sin él.

Botones: una acción principal y una etiqueta honesta

El Sistema de Diseño de GOV.UK dice que se use un botón predeterminado para la llamada a la acción principal de la página y que se eviten varios, porque tener más de una llamada principal reduce el impacto de cada una. Los botones secundarios son para llamadas secundarias. La página advierte además de que las páginas con demasiadas llamadas dificultan saber qué hacer después.

Las etiquetas merecen el mismo cuidado. GOV.UK pide mayúscula solo en la primera palabra y que describan la acción, con ejemplos como Start now, Sign in, Save and continue y Sign out, y admite palabras adicionales por claridad, como Add another address. Un botón que dice Enviar no explica nada de lo que ocurrirá. Un botón que dice Guardar y continuar explica ambas cosas.

Conviene adoptar dos reglas más. Los botones de advertencia son para acciones con consecuencias destructivas graves que el usuario no puede deshacer fácilmente, y GOV.UK dice que solo funcionan si se usan con mucha moderación. Y los botones desactivados deben evitarse si es posible, porque tienen mal contraste y pueden confundir; se usan solo si la investigación muestra que hacen la interfaz más comprensible.

Formularios: un patrón vertical con controles agrupados

USWDS da su guía de formularios en líneas breves y comprobables. Mantén los bloques del formulario en un patrón vertical, que conviene a personas con visión limitada. Marca los campos obligatorios con un asterisco rojo y explica la marca con texto al inicio del formulario. Etiqueta los campos opcionales con la palabra optional entre paréntesis. Un formulario de un solo campo no necesita marcador de obligatorio.

La estructura importa tanto como el aspecto. USWDS dice agrupar cada conjunto de controles temáticamente relacionados en un fieldset con una leyenda, y mostrar los controles en el HTML en el mismo orden en que aparecen en pantalla, porque los lectores de pantalla leen en orden HTML. Un diseñador que lo sabe dibuja el formulario de modo que el desarrollador lo construya bien a la primera.

Mensajes de error que dicen qué hacer a continuación

GOV.UK trata el mensaje de error como una pieza de interfaz con reglas propias. Se muestra junto al campo y en un resumen de errores al inicio de la página, con el mismo texto en ambos sitios. Explica qué salió mal y cómo corregirlo, en lenguaje llano y en términos positivos. Evita frases genéricas como An error occurred o This field is required.

La página distingue dos casos. Para un campo vacío, da una instrucción, como Enter your first name. Para una entrada incorrecta, da una descripción, como Name must be 35 characters or less. También pide a los redactores evitar palabras como please, sorry, valid, invalid y oops, porque añaden ruido o culpan al usuario.

La ubicación forma parte de la regla: el mensaje va tras la pregunta y el texto de ayuda, en rojo, con un borde rojo que lo une a la pregunta. Y el formulario no debe borrar los campos. Conserva las respuestas correctas y las incorrectas, para que el usuario vea y edite lo que escribió. Este único comportamiento separa un formulario amable de uno que castiga.

Tablas de datos: comparar en filas y columnas

El componente de tabla de GOV.UK sirve para que los usuarios comparen información en filas y columnas, y la página dice que nunca se use para maquetar contenido. Toda tabla lleva un título, escrito como se escribiría un encabezado, y cabeceras que digan qué representan filas y columnas. El atributo scope permite a las tecnologías de apoyo distinguir cabeceras de fila y de columna.

Hay un detalle fácil de pasar por alto y fácil de copiar: al comparar columnas de números, alinea los números a la derecha en sus celdas. Así el ojo compara cifras en la misma posición. En el teléfono las tablas anchas rara vez caben, por lo que conviene decidir pronto si la versión móvil es una tabla con desplazamiento o una lista de tarjetas, y diseñar ambas antes de desarrollar. Una tabla que luce bien con cinco filas inventadas puede fallar con cincuenta reales.

Objetivos táctiles: la única regla medible

El gusto no se mide, pero el tamaño del objetivo sí. El criterio de conformidad 2.5.8 de WCAG 2.2, de nivel AA, dice que el tamaño del objetivo para entradas de puntero es de al menos 24 por 24 píxeles CSS, con excepciones. Una cubre los objetivos pequeños situados de modo que un círculo de 24 píxeles centrado en cada uno no cruce otro objetivo. Las demás son equivalente, en línea, control del agente de usuario y esencial.

En la práctica, los botones de icono necesitan relleno y no solo un glifo pequeño, y los enlaces apretados en una fila necesitan espacio entre ellos. El mínimo es un suelo, no una recomendación, y un objetivo cómodo para el pulgar suele ser mayor. Pon el tamaño del objetivo en el sistema de diseño como un número, para que cada componente lo herede y cada diseñador no decida de nuevo. Un número también da a quien prueba la app terminada algo que comprobar.

Convierte cada ejemplo en una regla, una razón y una pantalla

Para usar los ejemplos de diseño de interfaz en un brief, escribe tres líneas por cada uno. Primero la regla, en una frase: un botón principal por pantalla. Luego la razón, tomada de la fuente: más de una acción principal reduce el impacto de cada una. Luego la pantalla de tu producto donde se aplica: el pago, el formulario de reserva, los ajustes. Los ejemplos sin tercera línea quedan como decoración.

Después enumera lo que la app debe mostrar además del camino feliz. Todo formulario tiene un estado de error, toda lista un estado vacío, toda petición un estado lento. Los sistemas públicos describen algunos con detalle, y el resto lo escribes tú. Un diseñador que recibe las reglas, las razones y los estados construye un prototipo que responde preguntas reales, no uno que solo se parece a la galería.

Qué preparar antes de encargar el diseño UX y UI de una app

Prepara las tres a cinco tareas que un usuario debe completar, las personas que las harán, los dispositivos que usan y las reglas que tomaste de los ejemplos. Añade el contenido de cada pantalla, los mensajes de error que puedas escribir hoy y las integraciones de las que dependen las pantallas. Decide quién puede aprobar una pantalla y con qué rapidez, porque esperar respuestas es una causa común de retraso.

Si quieres que lo haga un estudio, App UX/UI design de VITON13 Studio cubre hasta 3 flujos de usuario, 15 pantallas principales con sus estados, 30 componentes y un prototipo clicable. Cuesta desde $93 con IA o $113 con trabajo humano, en 8–15 días laborables. Cuantas más reglas y estados traigas, menos de ese tiempo se gasta en preguntas.