Sectores regulados
Diseñar una app de música y diseñar el proceso de siniestros de una aseguradora no son el mismo problema. Cuando el error tiene consecuencias reales para el usuario, el diseño trabaja con otras reglas. Esto es lo que hemos aprendido en más de una década en banca, energía y seguros.
Lo que cambia cuando diseñas en sectores donde equivocarse tiene consecuencias reales
Hay una diferencia entre diseñar una app de música y diseñar un proceso de reclamación de siniestros. Entre diseñar un e-commerce y diseñar el sistema de control de acceso de una planta industrial. Entre diseñar una plataforma de contenidos y diseñar el portal de trámites de una administración pública.
La diferencia no es solo de complejidad técnica. Es de lo que está en juego.
Cuando el usuario se pierde en un e-commerce, abandona el carrito y se va. Cuando el usuario se pierde en la gestión de su seguro de vida, toma una decisión equivocada sobre algo que le importa mucho. Cuando el empleado se equivoca en la interfaz de control de una planta, las consecuencias pueden ser operativas y costosas.
Llevar más de una década diseñando principalmente en esos contextos ha cambiado cómo pensamos sobre el diseño. Estas son las cosas que hemos aprendido.
El usuario no es siempre el protagonista de la historia
En diseño centrado en el usuario, hay una tensión que no se suele nombrar: el usuario inmediato de un sistema no es siempre la persona cuyo bienestar más depende de que ese sistema funcione bien.
En un proceso de siniestros, el usuario que rellena el formulario es el gestor del call center. Pero la persona cuya experiencia importa es el cliente que está esperando noticias sobre su reclamación y no sabe en qué estado está.
En una app de gestión de maquinaria industrial, el usuario que opera la interfaz es el técnico. Pero si la interfaz no le permite detectar una anomalía a tiempo, las consecuencias las sienten otras personas y otros procesos.
Diseñar bien en contextos complejos significa entender toda esa cadena de impacto — no solo el usuario directo del sistema, sino todos los que dependen de que ese usuario lo use bien.
La investigación tiene que ir más allá de las entrevistas de usuario
La investigación con usuarios es el punto de partida, no el punto de llegada.
En sectores regulados, la experiencia del usuario está condicionada por marcos normativos que el diseñador tiene que entender antes de proponer soluciones. Un flujo de onboarding bancario no puede diseñarse sin entender qué exige la normativa KYC. Un asistente con IA en seguros no puede diseñarse sin entender qué obliga el AI Act en términos de transparencia y explicabilidad.
Eso significa que el equipo de diseño tiene que hablar con el equipo legal, con el equipo de compliance, con el equipo de riesgos. No para que le digan lo que puede y no puede hacer — sino para entender el contexto completo del problema antes de empezar a resolverlo.
En muchos de los proyectos en los que trabajamos, los aprendizajes más valiosos no han venido de las entrevistas con usuarios. Han venido de entender las restricciones del negocio, de la regulación y de la operación que rodean al usuario.
La simplicidad es más difícil cuando el problema es complejo
Hay una idea en diseño que suena bien pero que se malinterpreta con frecuencia: que la buena experiencia es la simple.
En sectores complejos, la simplicidad para el usuario es el resultado de absorber complejidad en el sistema. No de ignorarla.
Un formulario de reclamación de siniestros que le pide al cliente lo mínimo necesario no es simple porque el proceso sea simple — es simple porque alguien ha decidido cuánta complejidad del proceso interno le corresponde gestionar al cliente y cuánta puede resolver el sistema internamente.
Esa decisión no la toma solo el diseñador. La toma el diseñador con el equipo de operaciones, con el equipo legal, con el equipo de producto. Y requiere entender el proceso completo antes de saber qué se puede simplificar sin romper nada.
La entrega no es el final del trabajo
En proyectos de diseño para sectores complejos, la entrega del diseño es el principio de la implementación — no el final del trabajo.
Lo que diseñamos tiene que poder construirse, con la tecnología existente, dentro de los plazos del negocio, y por equipos de desarrollo que no siempre han estado en el proceso de diseño desde el principio.
Eso significa que el trabajo de especificación — documentar el comportamiento del sistema, los estados de error, los casos extremos, las reglas de accesibilidad — es parte del diseño, no un anexo que se añade al final cuando hay tiempo.
Y significa que el seguimiento durante la implementación es parte del valor que aportamos. No para vigilar, sino para resolver las preguntas que inevitablemente aparecen cuando el diseño se encuentra con la realidad del desarrollo.
Por qué esto importa para elegir con quién trabajar
Si tu organización opera en banca, energía, seguros, transporte o sector público, el criterio para elegir un equipo de diseño no debería ser solo el portfolio visual. Debería incluir si ese equipo entiende los contextos en los que trabaja — la regulación, la complejidad operativa, los riesgos de equivocarse.
No porque el diseño sea difícil — es que el diseño en esos contextos requiere un tipo específico de experiencia acumulada que no se construye en unos pocos proyectos.
Nosotros llevamos más de una década acumulándola. Y cada proyecto nos enseña algo nuevo sobre lo que significa diseñar cuando las consecuencias importan.
