Microinteracciones: los detalles que hacen el producto

¿Qué es una microinteracción y cuáles son sus partes?

Una microinteracción no es una pantalla ni un flujo completo. Es el momento corto en el que el usuario hace algo y el producto responde. Dan Saffer, en su libro Microinteractions: Designing with Details (O’Reilly), propone analizarla con cuatro partes:

• Disparador (trigger): lo que la inicia. Puede ser del usuario, como pulsar o arrastrar, o del sistema, como la llegada de una notificación o un cambio en la conexión.
• Reglas: qué pasa cuando se dispara y bajo qué condiciones. Un botón “Me gusta” que solo funciona con la sesión iniciada tiene una regla.
• Retroalimentación (feedback): lo que el usuario ve, oye o siente para saber qué ocurrió.
• Bucles y modos: qué pasa si la acción se repite (un bucle) y si la microinteracción cambia de comportamiento según el contexto (un modo).

Las reglas casi nunca se ven. El usuario las aprende a través de la retroalimentación: si el botón responde, entiende que la regla funciona; si no responde, supone que la interfaz está rota. Por eso el feedback es la parte más visible del trabajo, aunque no sea la más importante en la lógica.

¿Por qué le importa a un diseñador junior?

Porque un producto se usa a través de decenas de microinteracciones y casi nadie las revisa una por una. Un formulario que no avisa de un campo inválido hasta que se envía, un botón que no cambia durante una carga o un “me gusta” que tarda un segundo en reflejarse son detalles pequeños, pero suman fricción en cada uso.

La referencia general es la respuesta del sistema. Nielsen Norman Group, en su heurística de visibilidad del estado del sistema, pide mantener informado al usuario con un feedback apropiado y, siempre que sea posible, inmediato. En sus límites de tiempo de respuesta fija tres umbrales:

Laws of UX añade la regla de Doherty: la respuesta del sistema debe llegar en unos 400 milisegundos para que la interacción se sienta fluida. Es un referente de un estudio de 1982 de IBM, así que conviene tratarlo como guía y no como norma universal. Para cuando la espera es inevitable, la página de estados de carga explica cómo mostrarla sin molestar.

¿Cómo se diseña una microinteracción, paso a paso?

1. Define la tarea y el disparador. Escribe en una frase qué hace la microinteracción y quién la inicia. Si necesitas dos frases, probablemente son dos microinteracciones.
2. Escribe las reglas en lenguaje llano. Si no puedes explicarlas en dos o tres frases, la regla todavía no está clara para ti, y tampoco lo estará para el usuario.
3. Elige el feedback según la duración. Una respuesta de menos de 0,1 segundos puede resolverse con un cambio de color o de estado. Una espera de varios segundos necesita un indicador de progreso o un texto que diga qué está pasando.
4. Decide si hay animación y cuánta. Nielsen Norman Group recomienda que la animación de causa y efecto empiece en menos de 0,1 segundos desde la acción del usuario. También advierte de que las animaciones repetidas se vuelven frustrantes. Anima para explicar un cambio, no para decorar.
5. Diseña el error y la carga antes que el caso feliz. La versión fácil es la del caso ideal. Lo que distingue una buena microinteracción es cómo se comporta cuando falla la red, cuando el dato no existe o cuando el usuario repite la acción.

Para la parte de las reglas, el costo de interacción te ayuda a decidir qué pasos sobran antes de pulir el feedback.

¿Cuándo NO conviene añadir animación?

• Cuando la acción se repite muchas veces. Un menú que se despliega con una animación de medio segundo resulta lento si se abre cien veces al día. Nielsen Norman Group señala este caso como fuente de frustración.
• En acciones críticas. Confirmar un pago o borrar datos necesita feedback claro. Una animación llamativa puede desviar la atención del texto de confirmación.
• Cuando el usuario pidió movimiento reducido. La animación iniciada por interacción debe poder desactivarse, salvo que sea esencial para entender la información (WCAG 2.2, criterio 2.3.3). La técnica C39 de WCAG usa la media query prefers-reduced-motion para respetar esa preferencia. Revisa también las estrategias de movimiento reducido.

Ejemplo

Ejemplo ilustrativo: un botón “Guardar cambios” en el editor de un perfil.

• Disparador: el usuario pulsa el botón.
• Reglas: el botón solo está activo si hay cambios sin guardar.
• Retroalimentación: al pulsar, el botón cambia a “Guardando…” con un indicador. Cuando termina, muestra “Cambios guardados” y vuelve a su estado inactivo.
• Bucle: si el usuario vuelve a editar un campo, el botón se activa de nuevo.
• Modo de error: si la red falla, el botón muestra “No se pudo guardar. Reintentar” y conserva los cambios para que no se pierdan.

Cada parte se revisa por separado. Si el botón no tiene estado de error, la microinteracción está incompleta, aunque en la demo funcione perfectamente. Si quieres profundizar en cómo se decide entre mostrar el cambio antes o después de confirmarlo, la página sobre skeleton vs. optimistic UI es el siguiente paso.

Para la retroalimentación de estado, también está relacionada la conciencia de estado: el usuario debe poder saber en qué punto está el sistema sin adivinarlo.

Errores comunes

• Animar por decoración, sin una función que explicar.
• Dar el feedback tarde y dejar al usuario sin respuesta durante más de unos cientos de milisegundos.
• Diseñar solo el caso feliz y olvidar los estados de error, de carga y de vacío.
• Repetir una animación larga que el usuario verá decenas de veces al día.
• Ignorar la preferencia de movimiento reducido del sistema operativo.
• Usar solo color como feedback, sin texto ni icono, lo que deja fuera a personas con daltonismo.

Fuentes

• Nielsen Norman Group, 10 Usability Heuristics for User Interface Design
• Nielsen Norman Group, Response Times: The 3 Important Limits
• Nielsen Norman Group, Animation Usability
• Laws of UX, Doherty Threshold
• W3C, Understanding SC 2.3.3: Animation from Interactions