UX en software empresarial: los errores que cometen hasta los equipos con experiencia
El diseño de software para entornos profesionales tiene reglas propias que difieren radicalmente del diseño de apps de consumo. Ignorarlas produce herramientas que nadie quiere usar.
Por qué el software empresarial tiene tan mala fama
Hay una broma en el sector que dice que el usuario corporativo promedio pasa más tiempo lidiando con el software que usando el software. Los interfaces sobrecargados, los flujos de siete pasos para tareas básicas, los menús que hay que memorizar: el software empresarial tiene una reputación merecidamente mala en términos de usabilidad.
La razón histórica es comprensible: durante décadas, el software B2B se vendía a directores de compras, no a los usuarios finales. El que tomaba la decisión no era el que sufría el producto. Pero ese modelo ha cambiado radicalmente. En un mercado con product-led growth, con SaaS de adopción viral y con usuarios que comparan tu herramienta con las apps de consumo que usan en su vida personal, la UX es un factor competitivo directo.
Hemos diseñado interfaces para plataformas de atención al cliente, sistemas hospitalarios, ERPs y herramientas de análisis. Lo que sigue son los errores que vemos con más frecuencia, incluso en equipos con diseñadores experimentados.
Error #1: confundir feature coverage con valor
El error más común en producto empresarial es añadir funcionalidades porque el cliente lo pide, sin preguntarse si esa funcionalidad resuelve el problema correcto.
El cliente que pide una feature suele estar describiendo un síntoma, no la causa. "Necesitamos poder exportar a Excel" puede ser la causa real o puede ser la consecuencia de que el reporting integrado no tiene los filtros que necesitan. "Necesitamos un botón de prioridad en los tickets" puede ser la causa o puede ser consecuencia de que el sistema no tiene una vista adecuada del trabajo pendiente.
El diseño de producto empresarial empieza por entender el trabajo que el usuario intenta hacer —el "job to be done"—, no por implementar la lista de peticiones. Esto no significa ignorar al cliente: significa escuchar de forma más profunda. Las entrevistas de usuario que preguntan "qué quieres que haga el software" son menos útiles que las que preguntan "cuéntame cómo completaste esta tarea la semana pasada".
La pregunta correcta en una entrevista de producto no es "¿qué funcionalidad te falta?". Es "¿cuál fue la última vez que te frustraste usando esta herramienta? ¿Qué intentabas hacer?"
Error #2: diseñar para el usuario nuevo, no para el experto
Las apps de consumo tienen un reto de onboarding enorme: el usuario llega con cero contexto y hay que retenerlo en los primeros tres minutos. El software empresarial tiene el problema opuesto: el usuario va a usar la herramienta ocho horas al día durante años.
El diseño que prioriza la comprensión inmediata —tooltips en todos los botones, wizards de tres pasos, interfaces simplificadas— puede ser correcto para el primer día y destructivo para el uso intensivo. Un usuario experto que ha completado la misma tarea mil veces necesita velocidad, atajos de teclado y densidad de información. No necesita que la interfaz lo trate como si fuera la primera vez.
La solución no es ignorar el onboarding. Es diseñar explícitamente para las dos fases: el camino del usuario nuevo, que prioriza comprensión y reduce fricción, y el camino del usuario experto, que prioriza velocidad y eficiencia. A veces son la misma interfaz con configuración gradual. A veces son modos distintos. Siempre requieren diseño explícito.
En Nexen, nuestra plataforma de comunicaciones, el panel de agente tiene una vista compacta para usuarios con carga alta de tickets —donde la densidad de información es máxima— y una vista estándar para usuarios más nuevos. El cambio es un toggle. Pero ese toggle es el resultado de dos años de feedback de usuarios que llegaban con experiencia de otras plataformas y pedían más información visible a la vez.
Error #3: la ilusión del usuario único
El software empresarial raramente tiene un solo tipo de usuario. Tiene el agente de atención al cliente que gestiona tickets, el supervisor que monitoriza al equipo, el director que mira métricas, el administrador que configura el sistema.
El error es diseñar pensando en uno solo de esos perfiles —normalmente el más visible— y asumir que los otros se adaptan. El resultado es que el supervisor tiene que usar un interface diseñado para el agente, el director tiene que exportar a Excel porque el sistema no tiene un panel de métricas adecuado, y el administrador hace configuraciones complejas con herramientas pensadas para operación diaria.
Cada perfil de usuario tiene un trabajo diferente, contextos de uso diferentes y necesidades de información diferentes. Diseñar para todos no significa hacer una interfaz que sirva para todo: significa hacer interfaces específicas para cada trabajo, compartiendo la lógica de negocio y los datos subyacentes.
Error #4: la densidad como problema, no como solución
Hay una tendencia en diseño de producto a asumir que menos es más: menos elementos en pantalla, más espacio en blanco, interfaces más limpias. Es un principio válido en muchos contextos. En software de uso intensivo, puede ser un error.
Un usuario de helpdesk que gestiona cincuenta tickets al día necesita ver mucha información a la vez. Si para ver el historial de un cliente tiene que abrir tres menús, ha perdido tiempo multiplicado por cincuenta. El tiempo es el recurso más escaso en trabajo operativo.
La densidad de información no es un defecto de diseño: es una feature cuando el usuario es experto y el tiempo importa. La diferencia entre buena densidad y mala densidad es la organización visual: jerarquía clara, grupos coherentes, información secundaria que existe pero no compite con la primaria.
Bloomberg Terminal tiene una interfaz que parece caótica para cualquier usuario nuevo. Para un operador de mercados que lo usa doce horas al día, es la herramienta más eficiente que existe. No es un accidente: es el resultado de décadas de diseño para usuarios expertos con necesidades de información específicas.
Error #5: no diseñar para el error
El software empresarial procesa operaciones que tienen consecuencias: un pedido cancelado, una factura emitida, un paciente dado de alta. Los errores en estas operaciones tienen coste real.
El diseño que no contempla los estados de error, las confirmaciones antes de acciones destructivas y las formas de deshacer operaciones está incompleto. No por estética: por resiliencia operativa.
Los principios que aplicamos:
Las acciones destructivas necesitan confirmación explícita, con descripción clara de qué va a ocurrir. No "¿Estás seguro?": "Vas a eliminar 47 conversaciones. Esta acción no puede deshacerse."
Los errores necesitan contexto y solución, no solo código de error. "Error 403" no ayuda a nadie. "No tienes permiso para ver este ticket. Contacta con tu administrador para solicitar acceso" resuelve el problema o al menos guía al usuario.
El estado del sistema tiene que ser siempre visible. El usuario tiene que saber si su acción se completó, si está pendiente o si falló. Los estados de carga sin feedback, los botones que no dan respuesta al clic, las operaciones asíncronas que no confirman su resultado son fuentes de ansiedad operativa.
Error #6: el diseño sin los datos reales
Los mockups se hacen con datos perfectos: nombres de longitud media, títulos de una línea, campos siempre rellenos. El software real tiene datos de longitud impredecible, campos vacíos, estados excepcionales y casos que nadie anticipó en el diseño.
La interfaz que se ve perfecta en el mockup puede verse completamente rota con datos reales. El nombre del cliente que tiene sesenta caracteres rompe el layout. El campo de descripción vacío deja un hueco inexplicable. La lista de resultados con 847 elementos no tiene paginación.
El hábito que más mejora la calidad del diseño de producto B2B es hacer mockups con datos reales desde el principio. Si el sistema va a gestionar datos de clientes, consigue datos reales o datos sintéticos representativos. Prueba con el nombre más largo, el campo más vacío, la lista más larga.
Lo que diferencia el software que se adopta
El software empresarial que tiene tasas de adopción altas tiene una característica en común: hace que el usuario sea mejor en su trabajo. No más rápido en las tareas que ya hacía igual: mejor en un sentido más profundo. Le da información que antes no tenía. Le libera de tareas que no generaban valor. Le avisa antes de que ocurra un problema.
Eso no ocurre por accidente. Ocurre cuando el diseño empieza por entender profundamente el trabajo del usuario, cuando las decisiones de diseño se toman con datos de uso real y cuando hay un ciclo de feedback constante entre el equipo de producto y las personas que usan la herramienta.
La buena noticia es que el estándar en software empresarial sigue siendo bajo. Un producto con UX genuinamente buena, en un mercado donde la media es mediocre, tiene una ventaja competitiva real. Es una de las pocas áreas donde la inversión en diseño tiene retorno directo en churn, NPS y crecimiento viral.
Etiquetas
Cuéntanos tu proyecto
Te ayudamos a encontrar la solución tecnológica adecuada, sin humo ni presiones.
Hablar con nuestro equipo