Cómo decidir qué tareas deben ejecutarse en segundo plano y cuáles necesitan una respuesta inmediata

Una tarea tarda varios segundos y el equipo propone enviarla a segundo plano. La decisión parece técnica, pero empieza con una pregunta de producto: ¿puede la persona continuar su objetivo sin conocer ahora el resultado? Si la respuesta es sí, el procesamiento asíncrono puede reducir interrupciones. Si necesita el resultado para decidir o completar el siguiente paso, esperar puede ser más claro y seguro.

Pasar una operación al segundo plano no elimina su duración ni su complejidad. Cambia cuándo recibe respuesta el usuario y qué responsabilidades asume el producto: comunicar que el trabajo empezó, conservar su estado y facilitar la recuperación si algo falla. Este marco permite evaluar experiencia, arquitectura y operación antes de modificar un flujo.

La decisión empieza por lo que el usuario necesita hacer después

El tiempo de ejecución, por sí solo, no determina el patrón. Una operación breve puede ser molesta si bloquea una acción importante; una larga puede resultar aceptable si el usuario puede seguir con otra tarea y volver más tarde. Conviene observar el flujo completo, no solo la llamada o el servicio que tarda.

Pregúntate qué decisión depende del resultado. Si una persona modifica la dirección de entrega y necesita saber si se aceptó antes de confirmar una compra, una respuesta inmediata ayuda a evitar una decisión a ciegas. Si solicita exportar un informe para usarlo más tarde, normalmente puede dejar que se prepare mientras sigue trabajando.

También importa el coste de esperar. ¿La pantalla bloqueada impide terminar una tarea urgente? ¿La persona perdería lo que ya escribió si abandona el flujo? ¿Puede entender qué está pasando sin soporte? Cuando esperar interrumpe un objetivo central, pero el resultado no es necesario para continuar, una respuesta rápida de aceptación y una ejecución en segundo plano pueden resolver mejor el problema.

Criterios para elegir entre primer plano y segundo plano

Evalúa cada operación con criterios observables. No hace falta convertirlos en una puntuación universal: sirven para hacer explícitos los intercambios y detectar supuestos distintos entre producto, diseño e ingeniería.

• Dependencia del resultado: si el siguiente paso exige conocer el resultado, mantén una respuesta inmediata o divide el flujo para pedir confirmación en el punto necesario.
• Impacto de la espera: si el usuario queda bloqueado o pierde contexto, considera una ejecución que le permita continuar. Si la espera es breve y clara, añadir estados y navegación puede ser más complejo que útil.
• Capacidad de recuperar el trabajo: en segundo plano, debe ser posible reconocer qué se solicitó y volver a consultar su estado. Si abandonar la pantalla hace desaparecer la operación o su contexto, el patrón no está completo.
• Reversibilidad y consecuencias: cuando un resultado modifica dinero, permisos, datos compartidos o compromisos externos, define con cuidado qué significa «solicitado» y qué significa «completado». No confundas aceptación con éxito final.
• Necesidad de informar progreso: si conocer el avance permite planificar, ofrece un estado útil. Si solo puedes mostrar una barra sin relación fiable con el trabajo real, comunica que sigue en curso en vez de simular precisión.
• Dependencias externas: los servicios de terceros pueden añadir variabilidad o dejar un resultado pendiente de confirmación. Diseña el mensaje según lo que realmente sabes, no según lo que esperas que ocurra.

Como regla práctica, mantén en primer plano las decisiones que requieren una respuesta antes de avanzar. Considera el segundo plano cuando el usuario ya pueda dar por iniciada la solicitud, continuar con valor y regresar al resultado sin perder información.

Cuándo encaja el procesamiento asíncrono y cuándo no

Son buenos candidatos los trabajos que producen un resultado consultable más adelante y no condicionan la siguiente acción: generar una exportación, procesar un conjunto de documentos, preparar una vista previa extensa o sincronizar información cuyo resultado no se necesita en ese instante. En estos casos, el usuario puede recibir una confirmación de inicio, salir de la pantalla y volver al elemento cuando esté listo.

También puede convenir para procesos con varias etapas o dependencias externas cuyo desenlace no es inmediato. El requisito es que el producto pueda representar estados significativos, como «recibido», «en curso», «requiere atención» o «completado». Si el sistema no puede saber en qué estado está el trabajo, no debería presentar como certeza una finalización que aún no ha verificado.

En cambio, suele ser preferible una respuesta inmediata cuando el usuario necesita corregir datos antes de continuar, cuando el resultado determina una elección siguiente o cuando una confirmación equivocada podría causar un perjuicio. Validar que un formulario tiene campos obligatorios, comprobar si una acción fue aceptada o mostrar si una configuración se guardó son ejemplos de respuestas que pueden ser parte del propio flujo.

Hay casos mixtos. Una operación puede confirmar de inmediato que la solicitud fue recibida y completar después el trabajo. Esa respuesta inicial debe ser explícita: «Hemos recibido la solicitud» no equivale a «La operación terminó». Esta distinción es especialmente importante para acciones financieras, cambios con efectos externos y procesos que pueden requerir intervención.

Qué debe comunicar la interfaz

Una experiencia asíncrona necesita algo más que un indicador de carga. Antes de iniciar, explica qué ocurrirá y si el usuario puede salir. Al aceptar la solicitud, confirma que el sistema la registró y ofrece una referencia o un lugar reconocible donde consultar el resultado, si el flujo lo requiere.

• Confirmación: indica qué se solicitó y qué estado tiene ahora. Evita mensajes que sugieran éxito definitivo cuando solo se confirmó la recepción.
• Progreso: muestra fases solo si reflejan información disponible y ayudan a entender la espera. Si no hay una estimación fiable, no inventes un porcentaje ni una hora de finalización.
• Continuidad: informa si se puede cerrar la pantalla, cambiar de sección o seguir usando el producto sin cancelar el trabajo.
• Resultado y acción siguiente: cuando termine, explica qué cambió, dónde encontrar el resultado y qué puede hacer la persona si debe revisarlo o corregir algo.
• Problemas: comunica si el trabajo requiere una acción, quedó incompleto o no se pudo confirmar. Ofrece un siguiente paso comprensible y evita mensajes genéricos que obliguen a contactar con soporte.

La notificación no sustituye a un estado persistente. Si el usuario vuelve después, debería poder entender qué pasó sin depender de una alerta que quizá ya desapareció. Define también qué sucede si el resultado llega mientras la persona está en otra pantalla o si el trabajo deja de ser relevante.

Implicaciones operativas y señales de diagnóstico

El segundo plano desplaza parte de la experiencia desde una pantalla hasta la operación del producto. El equipo debe poder distinguir trabajos pendientes, activos, terminados y que requieren revisión; investigar casos concretos y explicar discrepancias al soporte. Esto no exige exponer detalles técnicos al usuario, pero sí contar internamente con suficiente contexto para responder qué se pidió y qué ocurrió.

Observa señales del flujo, no solo el tiempo promedio de procesamiento. Si aumentan los usuarios que abandonan antes de una confirmación, quizá la espera bloquea demasiado. Si abundan consultas a soporte del tipo «¿se completó?», falta visibilidad o la confirmación es ambigua. Si las personas repiten la acción porque no saben si la primera solicitud quedó registrada, el diseño puede estar fomentando duplicados. Si casi nadie consulta el progreso, quizá una vista persistente o una notificación compleja no aportan valor.

Antes de lanzar, acuerda quién responde ante un trabajo atascado, cómo se comunica un resultado parcial y qué sucede cuando una dependencia externa no da una respuesta concluyente. Para acciones sensibles, define además quién puede ver el estado y el resultado. Estas decisiones son parte del producto, no detalles que puedan posponerse hasta que aparezca el primer incidente.

Preguntas antes de cambiar un flujo

1. ¿Qué necesita saber el usuario para dar el siguiente paso, y en qué momento?
2. ¿Puede seguir trabajando mientras el resultado se prepara? ¿Qué contexto debe conservar?
3. ¿Qué confirmación podemos ofrecer con certeza: recepción, progreso o finalización?
4. ¿Cómo encontrará el resultado después de cerrar la pantalla o volver otro día?
5. ¿Qué consecuencias tendría un estado incorrecto, incompleto o difícil de recuperar?
6. ¿Qué señal de uso o soporte demostraría que la espera mejoró, en vez de solo trasladarse a otra pantalla?

La decisión correcta no es automatizar en segundo plano todo lo que tarda. Es reservar la respuesta inmediata para los momentos donde aporta seguridad o permite avanzar, y permitir que el resto continúe sin secuestrar la atención del usuario. Si no puedes explicar cómo se confirma, se consulta y se recupera el trabajo, todavía no tienes un flujo asíncrono completo.