Ejemplos de prototipos de Figma: cuatro tareas de recuperación

Los ejemplos de prototipos de Figma útiles permiten intentar una tarea, encontrar una alternativa relevante y recuperarse sin indicaciones. Empieza con cuatro ejercicios pequeños: quitar un filtro demasiado restrictivo, cancelar un borrado, reintentar un guardado fallido y volver desde el detalle al mismo punto de una lista. Cada uno pone a prueba una decisión diferente. Una transición vistosa, por sí sola, no demuestra que alguien haya entendido el resultado.

Los casos siguientes son propuestas de práctica para un espacio de proyectos ficticio; no son resultados de investigación ni archivos funcionales descargables. Construye la interacción necesaria para resolver tu pregunta y documenta los desenlaces preparados. Si necesitas una introducción, consulta cómo conectan pantallas e interacciones los prototipos de Figma.

Elige la pregunta antes de animar

Elige una pregunta que otra persona pueda responder con su comportamiento. Por ejemplo: cuando una búsqueda de proyectos no devuelve resultados, ¿puede recuperarse sin crear un duplicado? Escribe primero qué esperas observar. Así resulta más fácil quitar adornos que no contribuyen a la prueba.

Asigna a cada ejercicio una pantalla de entrada y una condición inicial conocida. Figma admite varios puntos de inicio de flujo; la documentación de reproducción de prototipos explica cómo determinan dónde empieza el recorrido. Pon nombres de tareas, como Encontrar un proyecto archivado, en lugar de Pantalla 4.

Ajusta la fidelidad visual a la pregunta. Un wireframe permite detectar una ruta poco clara antes de pulir un dashboard. Nuestra guía de wireframes como entregables UX ayuda a distinguir el resultado de la herramienta. Utiliza el mismo nombre de proyecto en todo el ejercicio para que cada decisión tenga un objeto concreto.

Ejemplo 1: recuperar una búsqueda vacía

Prepara una lista con proyectos activos y archivados. La persona busca el proyecto archivado Lanzamiento, pero también está seleccionado el filtro de estado Activos. Ningún proyecto activo coincide con esa búsqueda. El resultado vacío debe explicar esa restricción y ofrecer Quitar filtros. No debería invitar a crear un proyecto nuevo como si el espacio nunca hubiera contenido información.

La muestra real de chips EmviUI representa un filtro de servicios con opciones seleccionadas y sin seleccionar. Es una referencia visual, no una captura de búsqueda de proyectos. Adapta el tratamiento al estado del proyecto y prepara la lógica de resultados y la recuperación. Crea una pantalla con resultados y otra con el estado vacío tras filtrar. Conecta Aplicar filtros con la segunda; desde Quitar filtros vuelve a una pantalla con los resultados iniciales y los controles restablecidos. Esta versión con pantallas explícitas resulta fácil de revisar porque los desenlaces están a la vista. Simula un resultado preparado; no implementa un buscador.

Para reutilizar el control, la documentación de componentes interactivos describe Change to entre variantes de un mismo conjunto. Puedes usarlo para los aspectos seleccionado y sin seleccionar. Que una casilla parezca marcada no filtra automáticamente una lista: hace falta conectar el resultado o preparar un modelo de estado. Consulta cómo describir estados de interfaz con variantes para nombrar esos aspectos.

Plantea la tarea: encuentra el proyecto de lanzamiento archivado. No indiques que hay que quitar un filtro. Observa si la persona revisa la restricción activa, entiende el mensaje y utiliza la salida. Si intenta crear un proyecto, apunta la primera señal confusa. Puede aportar más reescribir el texto que añadir una animación.

En una segunda prueba, elimina todos los proyectos del caso inicial. Ahora sí encaja una invitación a crear el primero. Comparar ambas condiciones permite comprobar si el diseño confunde falta de datos con falta de coincidencias. Aunque las dos pantallas parezcan vacías, el siguiente paso es diferente.

Ejemplo 2: cancelar una acción destructiva

Añade a una fila de proyecto una acción Eliminar que abra una confirmación. La tarea consiste en revisar la consecuencia y conservar el proyecto. Muestra su nombre exacto y una salida explícita para cancelar. Aquí interesa comprobar si alguien puede dar marcha atrás con confianza, no si descubre un icono de cierre escondido.

En Figma, coloca la confirmación en su propio frame y usa Open overlay. Conecta Cancelar con Close overlay. La guía oficial de overlays documenta la posición, el cierre al pulsar fuera y la sustitución de superposiciones. Decide expresamente si el fondo cerrará este caso; mantén una acción Cancelar visible en cualquier configuración.

Prepara también la rama que confirma el borrado. Puede llevar a una lista sin ese proyecto, mientras Cancelar conserva la fila original. Utiliza copias distintas de la lista si facilitan entender el modelo. Indica que el borrado es simulado para que nadie interprete una transición convincente como una operación real sobre datos.

Observa si la persona lee la identidad del proyecto antes de decidir. Una confirmación que solo pregunta si está segura aporta menos información en este ejercicio que otra que identifica el objeto afectado. Es una decisión de contenido propuesta para probar, no una regla que obligue a poner un diálogo en todos los borrados.

Especifica por separado el comportamiento de teclado de la aplicación. El patrón de diálogo modal de WAI-ARIA describe la entrada del foco, el recorrido de Tab dentro del diálogo, Escape y la devolución lógica del foco. Una superposición visual no acredita esos comportamientos en producción. Anota las comprobaciones para la versión programada.

Ejemplo 3: recuperar un guardado fallido

Haz que la persona cambie el nombre de un proyecto y lo guarde. El primer intento mostrará un fallo preparado; el segundo terminará correctamente y conservará el nombre propuesto. El ejercicio permite observar si el mensaje explica la situación y si reintentar parece más seguro que empezar de nuevo.

Si solo necesitas un caso revisable, separa edición, guardado en curso, fallo y finalización en pantallas. Mantén el mismo borrador del nombre en edición y error. Usa una confirmación concreta, como Nombre del proyecto guardado, para distinguir la tarea completada de un botón que simplemente deja de mostrar actividad.

Si compartir estado mejora el caso, las variables de prototipo de Figma permiten mantener valores vinculados a propiedades visibles. Una cadena puede proporcionar el nombre mostrado y un booleano seleccionar un desenlace preparado. La documentación sitúa actualmente estas funciones en planes de pago. Comprueba el acceso del archivo; las pantallas explícitas siguen siendo una alternativa útil.

Para una versión condicional, evalúa una variable de escenario al activar Guardar. Dirige una rama al fallo y otra al éxito. Figma documenta acciones ordenadas y condiciones if/else; cambiar un valor antes de comprobarlo puede modificar la rama ejecutada. Deja la condición en las notas de autoría y verifica el orden real de las acciones durante la reproducción.

No presentes el ejercicio como una reproducción de una caída de servidor ni como validación de cualquier texto escrito. Ensaya una respuesta diseñada. Para probar errores de campo, identifica el campo afectado mediante texto: la guía WCAG de identificación de errores exige esa identificación y descripción textual cuando se detecta automáticamente un error de entrada. Un fallo de conexión necesita otro mensaje; no atribuyas a un nombre válido el problema de una red simulada.

Ejemplo 4: volver al mismo punto de la lista

Prepara una lista larga, abre un proyecto de su mitad inferior y vuelve. La persona debería poder seguir comparando los proyectos cercanos sin buscar otra vez la fila anterior. Escribe la posición de retorno prevista antes de conectar la navegación; un salto accidental puede pasar inadvertido en una demostración rápida.

El área visible debe ser menor que su contenido y tener configurado el desbordamiento adecuado. La documentación de scroll y desbordamiento explica que, para desplazarse, el contenido tiene que superar los límites del frame. Mostrar entero un frame muy alto no equivale a probar una ventana de tamaño limitado con desplazamiento.

Sigue las reglas actuales de conservación del scroll: la posición se memoriza por defecto, pero compartirla entre pantallas depende de capas coincidentes. Los objetos anidados necesitan el mismo nombre y estructura de padres; los frames principales pueden compartir un prefijo antes de una barra. Reset scroll position permite anular la conservación para una interacción. Revisa los nombres además de la conexión.

En este ejercicio puedes usar Lista / Inicial y Lista / Actualizada como nombres principales relacionados y mantener la estructura del contenido desplazable. Compara una versión que conserva la posición con otra que la reinicia deliberadamente. Pide revisar un proyecto y compararlo con el siguiente. Registra si la vuelta facilita continuar.

Comprueba también una ventana estrecha. Una barra de acciones fija puede ocupar buena parte de la lista visible aunque en escritorio resulte cómoda. Trata el caso móvil como otra condición de observación: el frame del prototipo no demuestra que la futura web se adapte correctamente a distintos anchos.

Prepara los casos con EmviUI

Usa EmviUI como punto de partida visual de los casos. Su muestra real de estados vacíos combina mensajes para crear el primer proyecto, ilustraciones y acciones de creación. Sirve para comparar un espacio todavía sin usar con la lista filtrada del primer ejercicio. Antes de representar una búsqueda sin coincidencias hay que cambiar el mensaje y las acciones.

El catálogo actual de EmviUI presenta componentes y plantillas editables de Figma. Reutiliza el lenguaje visual de botones, campos y listas y añade tus propios datos e interacciones. El kit permite concentrar el esfuerzo en la pregunta de la prueba sin volver a dibujar cada control.

Mantén un pequeño registro: componente de origen, adaptación local, condición inicial y recuperación esperada. Sustituye los textos genéricos por el proyecto de la tarea. EmviUI no aporta evidencia de que alguien entienda un mensaje concreto ni de que exista persistencia funcional. Esas conclusiones necesitan observación y, después, comprobaciones en la implementación.

Realiza una sesión de observación repetible

Antes de invitar a nadie, recorre cada caso desde su entrada prevista. Activa todas las ramas, incluidas Cancelar, Quitar filtros, fallo y reintento. Regresa al comienzo y comprueba de nuevo los valores iniciales. Evita que una persona herede el filtro seleccionado o el estado completado por quien revisó antes.

1. Explica el espacio ficticio y la tarea sin mencionar el control que se debe utilizar.
2. Deja actuar y anota la primera duda y la interpretación del resultado.
3. Pregunta qué cree que ha ocurrido antes de enseñar otra condición.
4. Registra si recuperó la tarea sin ayuda, con indicaciones o de forma incompleta.
5. Restaura la condición inicial documentada antes del siguiente intento.

Una nota breve puede decir: esperaba encontrar el proyecto; el mensaje vacío sugería crear otro; no vio Quitar filtros. Es más accionable que una valoración general del aspecto profesional de la pantalla. Separa lo observado de tu explicación posible y evita convertir una impresión en una conclusión sobre todas las personas usuarias.

Figma permite previsualizar y presentar, pero la escala de reproducción puede modificar qué queda visible. Mantén una configuración consistente y comprueba que las acciones importantes caben en pantalla. Explica qué entradas, guardados o borrados están preparados de antemano. Los desenlaces simulados también pueden revelar dificultades de comprensión cuando sus límites se entienden.

Convierte las observaciones en decisiones

Después de la sesión, relaciona cada observación con una decisión: revisar el mensaje vacío, renombrar la acción destructiva, conservar el borrador cuando falla el guardado o mantener el contexto de la lista. Cuando sea posible, cambia una causa importante cada vez y repite la misma tarea para comprobar si continúa la dificultad.

Entrega las transiciones de estado junto con los casos visuales. Incluye condición inicial, acción que las activa, resultado y salida de recuperación. Señala qué estaba simulado y qué requisitos siguen pendientes de pruebas en la aplicación: peticiones reales, datos persistentes, foco de teclado, salida del lector de pantalla y adaptación a diferentes tamaños.

El resultado útil es un conjunto de preguntas resueltas y una siguiente prueba concreta. Conserva las animaciones que expliquen continuidad o respuesta. Estos cuatro ejemplos funcionan como experimentos pequeños que facilitan una decisión de producto; una visita guiada muy pulida puede ocultar que todavía hay comportamientos sin probar.