18 de octubre de 2026
·
6 min de lectura
Prototipos en código: qué validar antes de entregar una interfaz
Qué revisar en un prototipo en código: responsive, estados, accesibilidad, contenido y rendimiento antes de entregar una interfaz.
Temas:
Prototipado
Product Design
Accesibilidad
Una interfaz puede verse resuelta en una presentación y seguir acumulando preguntas: ¿qué ocurre cuando el título ocupa tres líneas?, ¿cómo se corrige un error sin perder lo escrito?, ¿dónde queda el foco al cerrar un diálogo?
El prototipo en código permite investigar esas preguntas en el navegador. Su valor depende de las decisiones que ayuda a tomar. Antes de construirlo conviene definir qué incertidumbre queremos reducir, qué comportamiento necesitamos reproducir y qué evidencia consideraremos suficiente para avanzar.
Cuándo usar Figma y cuándo pasar a código
Figma resulta útil para explorar jerarquía, composición, alternativas visuales y recorridos. Si necesitamos comparar dos estructuras de navegación, una representación sencilla puede bastar. Programar cada variante demasiado pronto añade trabajo que quizá no aporte aprendizaje.
El código cobra valor cuando la pregunta depende del comportamiento real del navegador: escribir en un formulario, recorrer controles con teclado, adaptar contenido a distintos anchos o comprobar actualizaciones dinámicas con un lector de pantalla. GOV.UK destaca el realismo de estos prototipos para investigar interacciones en móvil y escritorio. Making prototypes.
Una regla práctica: elige el medio más ligero que reproduzca la dificultad que necesitas observar. Ambas herramientas pueden convivir. Es posible explorar la estructura en Figma y programar únicamente un selector complejo, sin reconstruir todo el producto.
Define el alcance antes de construir
Escribe una hipótesis concreta: «La persona podrá corregir su reserva después de un error sin volver a completar los datos». Delimita el recorrido, los estados simulados y las tareas de prueba. También aclara qué queda fuera, como autenticación, persistencia o disponibilidad real.
Ese acuerdo ayuda a distinguir un fallo del diseño de una limitación conocida del prototipo.
Responsive: comprobar lo que sucede entre dos pantallas
Dos capturas, una móvil y otra de escritorio, dejan mucho espacio sin explorar. Cambia el ancho de forma continua y observa cuándo se rompe la relación entre contenido, controles y espacio disponible.
Prueba títulos extensos, botones con etiquetas largas y filas con información desigual. Revisa si el orden visual conserva la prioridad de la tarea. Una barra fija puede parecer cómoda hasta que aparece el teclado virtual y reduce el área útil.
Incluye zoom. El criterio Reflow de WCAG contempla que el contenido de desplazamiento vertical pueda presentarse a un ancho equivalente a 320 píxeles CSS sin perder información o funcionalidad ni exigir desplazamiento en dos dimensiones, salvo excepciones como ciertos mapas o tablas. Understanding Reflow.
Como comprobación práctica, amplía una ventana de 1280 píxeles CSS al 400 %. Después prueba un dispositivo real: la emulación sirve para explorar, pero no reproduce todas las condiciones de interacción.
Estados: diseñar también la espera y la recuperación
Para cada acción importante, prepara al menos los estados relevantes de inicio, carga, éxito, vacío y error. Añade permisos insuficientes o pérdida de conexión cuando afecten al recorrido. No todos los componentes necesitan todos los estados.
La pregunta útil es qué podrá hacer la persona después:
Si la búsqueda no devuelve resultados, ¿puede modificar los filtros?
Si falla el envío, ¿se conserva lo escrito?
Si una operación tarda, ¿queda claro que sigue en curso?
Si se pulsa dos veces, ¿hay una respuesta comprensible?
Permite activar estos escenarios de forma repetible. Un pequeño selector de situaciones facilita mucho más la revisión que depender de que el error aparezca por casualidad.
Cuando un mensaje de estado se actualiza sin mover el foco, debe poder comunicarse a las tecnologías de asistencia. W3C explica este requisito para resultados, esperas, progreso y errores. Un aviso visible de «Cambios guardados» puede requerir una región de estado apropiada; mover el foco a cada aviso puede interrumpir la tarea. Understanding Status Messages.
Teclado y accesibilidad: recorrer la tarea completa
Desconecta el ratón y completa el recorrido. Comprueba que las acciones puedan realizarse con teclado, que el foco resulte visible y que el orden permita entender dónde estás. WCAG exige operabilidad mediante interfaz de teclado, con una excepción acotada para funciones que dependen de la trayectoria del movimiento. Understanding Keyboard.
Empieza con elementos HTML nativos cuando correspondan. Después revisa nombres accesibles, etiquetas y mensajes de error. Una auditoría automática ayuda a detectar problemas, pero conviene combinarla con pruebas manuales y, cuando sea posible, investigación con personas con discapacidad.
Presta atención a los diálogos
Un diálogo modal necesita decisiones sobre el foco: debe entrar en él al abrirse, permanecer dentro mientras esté activo y regresar a un lugar lógico al cerrarse. El patrón de WAI también describe el cierre con Escape y recomienda un control visible para cerrar. Dialog (Modal) Pattern.
Prueba estas transiciones con contenido corto y largo. Añadir atributos ARIA sin implementar el comportamiento correspondiente puede generar una experiencia engañosa.
Contenido realista: introducir variación sin exponer datos
Prepara datos ficticios verosímiles: nombres compuestos, direcciones extensas, importes diferentes, listas vacías y listas densas. Incluye una etiqueta traducida más larga si el producto tendrá varios idiomas.
El contenido revela decisiones pendientes. Un truncado puede esconder justo el dato que permite distinguir dos opciones. Un mensaje genérico puede obligar a adivinar cómo corregir un formulario.
Evita datos personales reales innecesarios y operaciones con consecuencias. Documenta qué información es ficticia y permite reiniciar el escenario para cada sesión.
Rendimiento: detectar riesgos sin prometer resultados
Prueba la carga con limitaciones de red y dispositivo. Observa cuándo aparece el contenido principal, cómo responde una interacción y si los elementos cambian de posición inesperadamente.
Esas dimensiones se relacionan con LCP, INP y CLS. web.dev distingue las mediciones de laboratorio de los datos de usuarios reales: las primeras sirven durante el desarrollo, pero no sustituyen las segundas. Además, una ejecución convencional de Lighthouse sin interacciones no mide INP. Web Vitals.
En un prototipo, registra riesgos y condiciones de prueba. Una API simulada, imágenes provisionales o la ausencia de servicios externos impiden extrapolar directamente el resultado a producción.
Ejemplo hipotético: cambiar una reserva
Imaginemos un flujo para modificar la fecha de una reserva. El equipo prepara tres situaciones: disponibilidad, ausencia de plazas y fallo al guardar.
La prueba pide elegir una fecha, confirmar y recuperarse del error. Se observa si la persona entiende qué ocurrió, conserva su selección y encuentra cómo reintentar. También se ejecuta con teclado y zoom.
Si el aviso queda fuera del área visible o la selección desaparece, hay una decisión concreta que revisar. La sesión debe aportar evidencia para ajustar el flujo. Después será necesario comprobar si los cambios mejoran la tarea.
Checklist para entregar el prototipo
Hipótesis, tareas y límites documentados.
Anchos intermedios, zoom y contenido variable revisados.
Estados relevantes reproducibles y recuperación definida.
Recorrido con teclado, foco y mensajes accesibles comprobados.
Datos ficticios y escenario reiniciable.
Riesgos de rendimiento registrados con sus condiciones.
Hallazgos, decisiones y dudas pendientes compartidos.
La entrega debe aclarar qué aprendimos y qué falta verificar. GOV.UK advierte que el código de un prototipo no debe copiarse sin más a producción. Seguridad, arquitectura, integración y calidad operativa requieren su propia revisión. Un prototipo bien delimitado permite tomar mejores decisiones sin confundir una demostración convincente con un producto listo.
Fuentes
GOV.UK Service Manual. Making prototypes.
W3C WAI. Understanding Success Criterion 4.1.3: Status Messages.
W3C WAI, ARIA Authoring Practices Guide. Dialog (Modal) Pattern.
web.dev. Web Vitals.
Más artículos
Trabajemos juntos
¿Buscas apoyo para tu producto o equipo? Cuéntame qué necesitas.
O si prefieres, puedes contactarme a través de:
Diseñador de producto e ingeniero de software. Transformo procesos complejos en experiencias claras para productos B2B, con foco en datos e interacción con IA.