Sistema de Diseño de Formularios

¿Qué hace Sistema de Diseño de Formularios?

Propósito

El skill Sistema de Diseño de Formularios proporciona una metodología para diseñar el marco visual y espacial de formularios web. Mientras que la implementación técnica maneja el "cómo" y la optimización del crecimiento maneja el "por qué", el sistema de diseño define el "qué" y el "dónde". Garantiza que los elementos del formulario (etiquetas, campos, opciones y acciones) se organicen en una interfaz predecible, accesible y de alta confianza que reduce la carga cognitiva y previene errores del usuario.

Casos de Uso

• Diseñar una biblioteca de componentes de UI o sistema de diseño para formularios.
• Establecer estándares visuales para interfaces complejas de entrada de datos en múltiples pasos.
• Auditar formularios existentes en busca de inconsistencias visuales o fricción espacial.
• Diseñar diseños de formularios responsivos que mantengan la jerarquía en todos los dispositivos.
• Estandarizar patrones de visualización de errores y validación.

Cuándo NO Usar

• Barras de Búsqueda Genéricas: Los campos de búsqueda simples de una sola entrada rara vez necesitan el tratamiento completo del sistema de diseño.
• Medios Interactivos Experimentales: Donde la interacción similar a un formulario es secundaria a una experiencia narrativa o artística.
• Micro-interacciones de Bajo Riesgo: Como un "Pulgar Arriba/Abajo" o un interruptor simple sin entrada de datos asociada.

Entradas

1. Anatomía de la Información: Los puntos de datos específicos a recopilar y sus relaciones.
2. Puntos de Ruptura del Dispositivo: Requisitos responsivos del sistema-de-cuadrícula-responsivo.
3. Estilos de Marca: Escalas tipográficas, paletas de colores y tokens de espaciado (del sistema-de-espaciado-fluido).
4. Requisitos de Interacción: Si el formulario requiere validación en tiempo real, carga de archivos o selecciones de opciones complejas.

Salidas

1. Especificación de Anatomía de Entrada: Definiciones visuales para etiquetas, campos, texto de ayuda, iconos y mensajes de error.
2. Plano de Diseño: Reglas espaciales para agrupación de campos, alineación (superior vs. izquierda) y colocación de acciones.
3. Mapa de Componentes de Elección: Definiciones de cuándo usar Radio, Casilla de Verificación, Interruptor o Selección.
4. Matriz de Retroalimentación y Estados: Tratamientos visuales para los estados de Hover, Foco, Deshabilitado, Éxito y Error.

Flujo de Trabajo

1. Definir la Anatomía del Componente

Establecer una estructura consistente para cada "Grupo de Campos". Un campo debe consistir en:

• La Etiqueta: Texto claro y conciso que identifica el campo.
• El Campo: El contenedor interactivo (texto, selección, etc.).
• Texto de Ayuda/Instrucción: Orientación persistente (por ejemplo, "La contraseña debe tener 8 caracteres").
• Mensaje de Error: Retroalimentación contextual que aparece solo cuando falla la validación.

2. Establecer el Diseño Espacial y la Alineación

Determinar la relación entre etiquetas y campos:

• Etiquetas Alineadas Superiormente (Recomendado): Mejor para escaneabilidad y capacidad de respuesta en móvil.
• Etiquetas Alineadas a la Izquierda: Solo para interfaces de escritorio con muchos datos donde el espacio vertical es crítico.
• Agrupación: Usar espaciado lógico (ej., --espacio-l) entre grupos y espaciado más pequeño (ej., --espacio-s) dentro de los grupos.

3. Seleccionar Patrones de Interacción

Asignar patrones de UI a tipos de datos:

• Opciones Binarias: Usar Casillas de Verificación para "Sí/No" o selección múltiple.
• Exclusividad Mutua: Usar Botones de Radio para 2–5 opciones; usar Selección para 6+ opciones.
• Interruptores Inmediatos: Usar Interruptores para configuraciones que surten efecto inmediatamente sin una acción de "Enviar".

4. Diseñar el Bucle de Retroalimentación

Crear una jerarquía visual para la validación:

• Estado de Foco: Usar un anillo de alto contraste para indicar el campo activo.
• Estado de Error: Usar color (generalmente rojo), iconos y grosor de borde para señalar errores.
• Estado de Éxito: Usar señales sutiles (como una marca de verificación verde) para campos de alto riesgo (ej., disponibilidad de nombre de usuario).

5. Planificar las Adaptaciones Responsivas

Mapear cómo el formulario sobrevive en viewports más pequeños:

• Apilamiento: Los diseños de múltiples columnas en escritorio deben apilarse en una sola columna en móvil.
• Objetos Táctiles: Asegurar que todas las zonas interactivas (radios, casillas de verificación, botones) tengan al menos 24x24px (WCAG 2.2 SC 2.5.8 mínimo); se prefiere 44x44px y debe ser el valor predeterminado para las acciones de envío principales.

Reglas de Decisión

• La Regla de la Columna Única: Usar un diseño de una sola columna para la mayoría de los formularios para mantener una ruta de escaneo vertical clara y reducir la fatiga de seguimiento ocular.
• Alineación de Etiquetas: Predeterminar etiquetas alineadas superiormente. Reducen el número de fijaciones oculares necesarias para procesar el formulario.
• Marcadores de Posición vs. Etiquetas: Nunca usar marcadores de posición como etiquetas. Las etiquetas deben permanecer visibles incluso después de que el usuario comience a escribir.
• Jerarquía de Botones: La acción principal "Enviar" debe ser la más prominente visualmente. Las acciones secundarias (ej., "Cancelar") deben ser enlaces de texto o botones de bajo contraste.
• Proximidad: Colocar el texto de ayuda y los mensajes de error lo más cerca posible del campo (generalmente directamente debajo).

Restricciones

• Accesibilidad: Las etiquetas deben estar programáticamente vinculadas a los campos (<label for> o envolver). Las relaciones de contraste para texto y bordes deben cumplir con WCAG AA (4.5:1 para texto, 3:1 para componentes de UI). Los mensajes de error deben estar programáticamente asociados con su campo mediante aria-describedby, y los campos no válidos deben establecer aria-invalid="true". Los indicadores de foco no deben ocultarse detrás de encabezados fijos, notificaciones toast o superposiciones (WCAG 2.4.11 Foco No Obscurecido).
• Responsividad: Los campos del formulario nunca deben desbordar su contenedor ni tener anchos fijos que excedan los viewports móviles.
• Jerarquía Visual: Los mensajes de error deben ser visualmente distintos del texto de ayuda para garantizar que no se pasen por alto.

Patrones de Fracaso Comunes

• La "Trampa de la Etiqueta Marcador": Usar marcadores de posición en lugar de etiquetas, lo que hace que los usuarios pierdan el contexto al escribir.
• Columnas Abrumadoras: Usar diseños de varias columnas que confunden la ruta de escaneo natural de arriba a abajo del usuario.
• Errores Vagas: Visualizar un error solo con color (ej., simplemente volviendo el borde rojo) sin un icono o mensaje de texto.
• Objetos Táctiles Pequeños: Diseñar radios o casillas de verificación demasiado pequeños para la interacción con el pulgar en móvil.
• El Foco "Invisible": No proporcionar un anillo de foco claro, lo que hace imposible la navegación para usuarios de teclado.

Criterios de Validación

• Cada campo tiene una etiqueta visible y persistente.
• El formulario sigue una ruta de escaneo vertical lógica de una sola columna.
• Los estados de error usan una combinación de color, iconos y texto.
• Los indicadores de foco son de alto contraste y claramente visibles.
• Los elementos interactivos (campos, botones) cumplen con el mínimo de 24x24px de objetivo táctil de WCAG 2.2 (44x44px preferido).
• La transición del diseño a una sola columna en viewports móviles es fluida.
• Las acciones primaria, secundaria y terciaria tienen una jerarquía visual clara.