Diseño de formularios UX

1) Principios

1. Primero la tarea, luego los campos. Formularios: continuar con la secuencia de comandos personalizada, no con la lista DB.
2. Una pantalla es un objetivo. Retire todo lo que no conduzca a la finalización de la tarea.
3. Nunca pierda datos. Auto Seave, recuperación del borrador, repeticiones seguras.
4. Muéstrele «cómo es correcto». Reglas y ejemplos antes del error; validar cuidadosamente.
5. Disponibilidad predeterminada. Etiquetas, enfoque, contraste, navegación por teclado.
6. Velocidad predecible. Primera respuesta ≤ 100 ms, envío con un estado y progreso explícitos.

2) Arquitectura de la información del formulario

El objetivo → los pasos de → del campo. Comience con el resultado (por ejemplo, «desembolso») y asigne un conjunto mínimo de campos.
Agrupación en el sentido de: «Datos personales», «Pago», «Confirmación». Cada grupo ≤ 6 campos.
Divulgación progresiva: mostrar campos adicionales por condición (toggle/selección de país).
El orden de los campos es como en la cabeza del usuario: de lo conocido a lo complejo.

3) Diseño y cuadrícula

Un altavoz para móviles y la mayoría de las tareas son más rápidas en cuanto a la mirada y el orden.
Las dos columnas son adecuadas para campos interconectados cortos (fecha/hora, nombre/apellido).
Altura de línea 40-48 px, distancia entre los campos 8-12 px (relacionados )/16-24 px (grupos).
Alineación de etiquetas en la parte superior del campo; derecha: para formularios estrechos, no utilice.

4) Etiquetas, playsholder, helpers

El sello es obligatorio. Playsholder es un ejemplo, no un reemplazo.
Coloque el texto helper debajo del campo: reglas, formato, referencia de ejemplo.
Los campos opcionales marcan «(opcional)» en lugar de «» en los obligatorios.

Ejemplo:

html
<label for = "iban"> IBAN <span class = "muted"> (optional) </span> </label>
<input id="iban" aria-describedby="iban-help">
<small id = "iban-help "> Format A-Z, 0-9; example: DE89 3704 0044 0532 0130 00 </small>

5) Pasos y progresos

Formularios de varios pasos (CUS/pagos): 3-5 pasos, progreso claro «Paso 2 de 4».
Guarde los pasos completados; Permita el retorno sin pérdida de datos.
Botones de navegación: «Atrás», «Siguiente», «Confirmar» final - siempre en el mismo lugar.

6) Administración de entrada

Teclados y atributos: 'tipo', 'inputmode', 'autocomplete' por tipo de datos.
Use las máscaras de entrada suavemente (teléfono, IBAN, PAN, fecha), mantenga los valores normalizados.
Autocomplete no se rompa: correcto' autocomplete =» given-name» | «cc-number» | «one-time-code», etc.
Presets de sumas/shortcats: «+ 50/+ 100/Todos» junto al campo de sumas.

Tabla de atributos (abreviado):

Campo	type	inputmode	autocomplete
Email	email	email	email
Teléfono	tel	tel	tel
Cantidad	text	decimal	off
PAN	text	numeric	cc-number
CVC	password	numeric	cc-csc
Fecha de la tarjeta	text	numeric	cc-exp
OTP	text	numeric	one-time-code

7) Validación y errores

Estrategia: antes de la entrada (helper), durante (indicaciones suaves), después (en blur/submit).
Validaciones asíncronas (singularidad de inicio de sesión, límites, riesgo) - con debouns de 250-400 ms.
Texto de error: la razón → cómo corregir → alternativa.
Resumen-panel sobre el formulario para varios errores + enfoque al primer error.
Idempotency-Key para actividades críticas (apuesta/pago) y retiros seguros.

8) Botones y envío

El CTA primario está resaltado en color/tamaño, disponible por Enter.
'Busy' -coexistencia y bloqueo de repetición de clic; con retraso> 3-5 s - «Esperamos confirmación»....
Después del éxito - estado explícito (tostada/pantalla «Listo») + lo que viene después.

9) Accesibilidad (A11y)

Las conexiones correctas son 'label → input', errores a través de 'aria-describedby', las críticas son 'role =' alert '.
Visible ': focus-visible', el orden Amb corresponde al visual.
Contraste de texto/iconos ≥ AA; el significado no es sólo de color.
Soporte para 'prefers-reduced-motion': un mínimo de animaciones.
Para los grupos de radiocomunicaciones - 'fieldset/legend', para las pistas - 'role =' status '.

10) Localización y formatos internacionales

Fechas/Monedas/Números - Locales al ingresar, Almacenamiento - Unidades ISO/Menores.
Permita diferentes alfabetos en nombres/direcciones; no limite los guiones/apóstrofos.
Almacene el teléfono en E.164; el país se selecciona explícitamente o de '+ CC' cuando se inserta.

11) Performance y estabilidad

Primera respuesta visual ≤ 100 ms; comprobaciones asíncronas - no bloquean la pantalla.
Skeleton en lugar de spinner «colgante», fijar las alturas, evitar CLS.
Virtualice las listas largas (por ejemplo, países/bancos).
Animar sólo 'transformación/opacity', sin sombras/blur masivas.

12) Seguridad y privacidad

No lógica PAN/CVC/pasaporte; no envíe a RUM/consola.
Enmascara los campos sensibles, no los guarde en la configuración automática.
No revele si existe una cuenta: «Si el correo electrónico está registrado, enviaremos un correo electrónico».
Almacenamiento - el mínimo necesario; muestre por qué se requiere KYC.

13) Patrones por escenario tipo

13. 1 Pago/Depósito

Campo de suma con presets, la moneda se especifica explícitamente.
PAN con máscara suave, comprobación de Luhn; CVC está oculto; fecha 'MM/YY' con auto- '/'.
El texto sobre comisiones/plazos está cerca, no en la herramienta.

13. 2 Retiros

Pasos: «Suma → Método → Confirmación».
Progreso y «Normalmente hasta N minutos/horas» (sin promesas duras).
Opciones de método por país; advertencias de límites.

13. 3 KYC

Cargador de archivos paso a paso: requisitos de formato/peso, vista previa, privacidad.
Fechas de verificación y canal de estado (correo/notificación).

13. 4 Límites y juego responsable

Unidades comprensibles (por día/semana/mes), preconcepciones, confirmación de cambios, «Entrará en vigor a través de»....

14) Antipattern

Placeholder en lugar del sello.
Errores «en cada símbolo» sin debauns.
Restablece el formulario en caso de error.
La instrucción crítica sólo está oculta en la herramienta.
Máscaras rígidas que prohíben los caracteres válidos/insertar.
Bloquea toda la página para verificar un campo.
Envío sin busy/progreso explícito.

15) Snippets de implementación

Resumen de errores + enfoque al primer problema

js function focusFirstError() {
const el = document. querySelector('[aria-invalid="true"]');
if (el) el. focus({ preventScroll:false });
}

Botón con busy instantáneo e idempotencia

js btn. addEventListener('click', async () => {
btn. classList. add('is-busy');
try {
const r = await fetch('/api/submit', {
method: 'POST',
headers: { 'Idempotency-Key': crypto. randomUUID() },
body: new FormData(document. querySelector('form'))
});
if (!r.ok) throw new Error();
// success UI
} catch {
// show retry
} finally {
btn. classList. remove('is-busy');
}
});

El marco HTML de un grupo de botones de radio disponibles

html
<fieldset>
<legend> How to get </legend>
<label><input type="radio" name="method" value="sepa"> SEPA</label>
<label><input type="radio" name="method" value="swift"> SWIFT</label>
</fieldset>

16) Tokens del sistema de diseño (ejemplo)

json
{
"form": {
"gap": 12,
"groupGap": 20,
"labelSize": 14,
"fieldHeight": 44,
"radius": 10
},
"motion": {
"pressMs": 90,
"hoverMs": 160,
"overlayInMs": 240
},
"validation": {
"debounceMs": 300,
"blurFeedbackMs": 100
},
"a11y": {
"focusRing": { "width": 2, "offset": 2 },
"contrastAA": true
}
}

Preajustes CSS

css
.form { display:grid; gap:12px; }
.form__group { display:grid; gap:20px; }
label { font-size:14px; }
.input { height:44px; padding:0 12px; border-radius:10px; }
.input:focus-visible { outline:2px solid var(--focus-ring); outline-offset:2px; }
.field-error { color: var(--role-danger); font-size:.875rem; margin-top:6px; }

17) Métricas y experimentos

Completion Rate, Time-to-Complete, Error Rate por campos.
Retry Success Rate, proporción de formularios abandonados, profundidad de paso.
CTR de consejos/ejemplos, proporción de autocompletados.
A/B: orden de los campos, presets de sumas, textos de error, división en pasos.

18) Lista de comprobación de QA

Significado y flujo

Los campos coinciden con el objetivo; No hay superfluos.
Los grupos son lógicos; un máximo de 6 campos por grupo.

la Introducción

Correcto 'tipo/inputmode/autocomplete'.
Las máscaras son suaves, la inserción no se rompe, caret es predecible.

Validación

Helper antes de la entrada; errores en blur/submit; debouns 250-400 ms.
Panel de resumen para errores múltiples; enfoque a la primera.

Disponibilidad

Etiquetas relacionadas; el contraste ≥ AA; ': focus-visible' es visible.
Navegación desde el teclado; grupos de radio con 'fieldset/legend'.

Performance

Primera respuesta ≤ 100 ms; no hay spinners «colgantes».
No CLS; las listas largas están virtualizadas.

la Seguridad

No hay registros de campos sensibles; PAN/CVC no está en autoservicio.
La idempotencia y los retiros seguros están incluidos.

19) Especificidad de iGaming

Apuestas: campo de suma + presets, 'busy' instantáneo, confirmación optimista con opción undo (si el reglamento lo permite).
Pagos/conclusiones: tarifas y plazos explícitos cerca de los campos, no sólo en las pistas; comprobar los límites y el estado de KYC.
Torneos: formulario de registro con un conjunto mínimo de datos, reglas y casillas de verificación acordadas sin «patrones oscuros».
Juego responsable: formularios para establecer límites a intervalos claros y previsualizar el resultado («Tu límite diario será de 2.000 ₴ a partir de mañana»).

Resumen breve

Una buena forma es un objetivo claro, un conjunto mínimo de campos, reglas claras antes del error, respuesta instantánea y datos almacenados. Diseñe la estructura desde el escenario, respete la disponibilidad y la localización, incluya retraídas seguras e idempotencia. Es así como las formas se sienten rápidas y confiables, especialmente en escenarios críticos de iGaming.