08 Jun El software funciona, el código es bueno, pero tu equipo lo odia. ¿Te suena?
El software no da errores. Las funcionalidades están completas. El código pasó todas las pruebas. Y aún así, tu equipo busca cualquier excusa para no usarlo. Abren el sistema con resignación, completan lo mínimo y vuelven a sus hojas de cálculo de siempre. La buena noticia es que no estás solo. La mejor noticia es que esto tiene explicación y tiene arreglo.
La barrera no es técnica, es psicológica
Hay un fenómeno documentado en psicología cognitiva llamado «efecto de usabilidad estética»: los usuarios perciben un sistema visualmente atractivo como más fácil de usar, incluso antes de interactuar con él. Lo contrario también es cierto. Un software que parece anticuado genera desconfianza automática, aunque técnicamente sea impecable.
Tu equipo no odia el software porque falle. Lo evita porque cada vez que lo abre, su cerebro recibe la señal de «esto es viejo, esto es lento, esto me va a costar». No es una decisión racional. Es una respuesta emocional que se activa en milisegundos y condiciona toda la interacción posterior.
El caso GiveFeedback: nosotros también evitábamos nuestro propio SaaS
Esto no es teoría de libro. En Vidasoft desarrollamos GiveFeedback, nuestro SaaS de encuestas de clima laboral. El código era sólido. Las funcionalidades cubrían lo prometido. Pero nosotros mismos —los creadores— evitábamos usarlo. Cuando rediseñamos la interfaz, no cambiamos lo que hacía el software. Cambiamos cómo se sentía al usarlo. Y el cambio de actitud fue inmediato: lo que antes era una herramienta que daba pereza abrir se convirtió en algo que fluía.
Si los propios desarrolladores evitan su producto, imagina lo que siente un empleado al que le han impuesto la herramienta sin preguntarle.
Las tres razones por las que tu equipo rechaza el software (y ninguna es técnica)
1. Parece una reliquia del 2005. No es esnobismo. Es que el cerebro asocia diseño anticuado con abandono. Si la herramienta parece que nadie la ha actualizado en 10 años, el mensaje subliminal es «a la empresa no le importa esto». Y si a la empresa no le importa, ¿por qué iba a importarle al empleado?
2. Castiga en lugar de ayudar. Muchos sistemas internos están diseñados para controlar, no para facilitar. Campos obligatorios sin sentido, validaciones absurdas, flujos rígidos que no contemplan excepciones. Cada vez que el sistema dice «campo obligatorio» para algo que el empleado sabe que no aplica, la relación se deteriora un poco más.
3. No respeta el tiempo de quien lo usa. Si completar una tarea de 30 segundos requiere 2 minutos de navegación por menús, el sistema está comunicando «tu tiempo no me importa». Y la respuesta natural es buscar alternativas que sí lo respeten, aunque sean menos seguras o menos trazables.
La paradoja del software interno
Hay una ironía cruel en el software de empresa: el mismo propietario que exige una web corporativa impecable y una app de cliente pulida, tolera un software interno que parece diseñado en otra década. La diferencia es que el cliente puede irse a la competencia si la experiencia es mala. El empleado no puede irse del software —pero puede desconectar, hacer lo mínimo, resistirse pasivamente y, eventualmente, irse de la empresa.
El coste de un empleado que se va por frustración con las herramientas es el mismo que el de uno que se va por sueldo. La diferencia es que el segundo lo ves venir; el primero te pilla por sorpresa.
Cómo darle la vuelta sin reescribir todo el código
La solución no es tirar el software y empezar de cero. En la mayoría de los casos, lo que hay debajo —la lógica de negocio, la base de datos, las integraciones— funciona perfectamente. Lo que falla es la capa de presentación: cómo se muestra la información y cómo se interactúa con ella.
Un rediseño de interfaz bien ejecutado no toca el motor: reorganiza el salpicadero para que todo esté donde el conductor lo espera. Los mismos botones, los mismos datos, pero presentados en el orden en que realmente se usan, con el lenguaje que realmente habla el equipo y con un aspecto que transmite «esto está vivo, esto se cuida».
Señales de que el problema es la interfaz, no el código
- Los empleados nuevos tardan más en aprender el sistema que en aprender su trabajo real.
- Hay funcionalidades que existen desde hace meses y nadie usa porque «no sabía que estaban ahí».
- Las mismas tareas se completan mucho más rápido en herramientas externas que en el sistema oficial.
- Cuando anuncias una nueva funcionalidad, la reacción es escepticismo en lugar de interés.
- Escuchas frases como «yo es que soy de la vieja escuela» como justificación para no usar el sistema.
Si has marcado mentalmente al menos dos, el código no es tu problema. Lo es la capa que conecta ese código con las personas.
Tu software funciona. Técnicamente. Pero si tu equipo lo odia, no está funcionando donde importa: en el día a día de quien lo usa. Y eso se arregla. Hablemos de cómo convertir esa herramienta que evitan en una que usan sin pensarlo.
