Deprecation & migration UX

Las deprecaciones sorpresa destruyen la confianza. El aviso debe incluir una fecha calendario fija (no "proximamente") y publicarse con tiempo para que el usuario planifique. La industria convergio en ventanas según el alcance: GitHub mantiene cada versión de su REST API por al menos 24 meses tras liberar la siguiente, AWS retira servicios con timelines típicos de 12 meses, y Slack muestra el banner in-app 60 días antes del retiro. La fecha no debe cambiar después de anunciada, salvo pausa justificada publicamente.

Un aviso de deprecación sin justificación se percibe como arbitrario y genera resistencia. El usuario necesita entender la razón real (seguridad, deuda técnica, mejor alternativa) y la ganancia tangible al migrar. NN/g documenta el patrón correcto: anunciar que cambia, por que cambia y que permanece igual; su heuristica #1 establece que ninguna acción con consecuencias debe tomarse sin informar al usuario. El lenguaje corporativo vago ("optimizando nuestra plataforma") activa desconfianza; la honestidad sobre las restricciones se acepta mejor.

Anunciar que algo desaparece sin decir adonde ir es una notificación a medias. Cada aviso debe incluir que reemplaza la feature, pasos concretos para migrar y un enlace a documentación accionable. Stripe define explicitamente cambios backward-compatible vs. breaking y entrega un checklist de migración por versión mayor; GitHub, al deprecar endpoints del Teams API, incluyo el endpoint alternativo exacto. En un caso documentado por UserIntuition, la ausencia de soporte a la migración costo neto -$830K en el año 1 (caso único, no estudio controlado).

Los correos de deprecación solos no bastan: el usuario puede no leerlos o no conectarlos con su flujo real. El aviso contextual, colocado en la UI de la propia feature deprecada, alcanza al usuario en el momento exacto en que le es relevante. NN/g documenta el fracaso de notificaciones pasivas descontextualizadas (una usuaria espero 5 minutos porque no vio el mensaje al pie de pantalla) y recomienda revelaciones pull (contextuales) sobre push (globales). Slack confirma que el canal in-product es el primario; el email es el respaldo para usuarios inactivos.

La migración forzada crea fricción máxima. El patrón correcto ofrece un periodo de coexistencia donde el usuario usa ambas versiones y migra a su ritmo. Google Cloud AIP-185 establece que distintas versiones de la misma API deben poder convivir en un mismo cliente durante una transición razonable; Stripe fija la versión por cuenta y permite probar la nueva con el header Stripe-Versión sin alterar la cuenta, con ventana de reversión. NN/g recuerda que los usuarios odian el cambio: las quejas no implican que el nuevo diseño sea peor. Deprecación y sunset son fases distintas.

Un aviso informacional dado 90 días antes tiene el mismo peso visual que uno dado 3 días antes si no se escala. El sistema correcto usa tres fases: awareness pasivo (chip dismissable, tono neutro), advertencia activa (banner persistente, acción requerida) y bloqueo final (dialog no-dismissable que reempaca todo el contexto). Slack documenta esas tres fases; NN/g reserva el modal para acciones destructivas o cuando falta información para continuar. Usar tono critico desde el día uno es gritar "lobo": el usuario aprende a ignorarlo.

Hay una diferencia fundamental entre deprecar una comodidad y deprecar algo que contiene datos del usuario o soporta un flujo de negocio activo. Para el segundo caso la regla es absoluta: no cortar el acceso sin garantizar que los datos son exportables, migrables o transferidos antes del cutoff. AWS exige en su politica proveer alternativas y soporte a la migración para minimizar disrupciones; GitHub pauso el sunset del Teams API en marzo 2022 por presión de la comunidad, evidencia de que ejecutar sin ruta de rescate es reversible pero costoso en reputación. La protección aplica a features estables, no a betas/previews. Planear la ruta es prerrequisito del anuncio, no su consecuencia.

Los avisos de deprecación deben cumplir WCAG 2.1 AA para ser perceptibles por todos. Esto implica anunciar el mensaje con role="alert" o role="status" (SC 4.1.3, el contenedor debe existir vacio en el DOM al cargar), no depender solo del color para la severidad (SC 1.4.1: icono o etiqueta de texto redundante), y mantener contraste de texto >= 4.5:1 (SC 1.4.3). La urgencia falsa, un countdown que se reinicia o "actua ahora" sin deadline real, es un dark pattern inverificable que erosiona la credibilidad de todos los avisos futuros: usa la fecha fija, no un contador.