Hace años trabajé en una empresa que estaba desesperada porque los usuarios de uno de sus productos no querían usarlo. Había mucho rechazo y resistencia. Hicieron decenas de reuniones para mejorar la usabilidad, el diseño de la interfaz gráfica, etc. Incluso hasta subcontrataron a unos expertos en usabilidad. Pero por más vueltas que le daban al tema seguían sin ser capaces de solucionarlo, de ver, o reconocer, el problema más obvio: Los usuarios rechazaban usar la aplicación porque esta no aportaba ningún beneficio a su trabajo, independientemente de que la interfaz gráfica fuera más o menos bonita.
Desde los comienzos de la informática, ha habido miles de aplicaciones sumamente “feas” ampliamente usadas, y miles de aplicaciones sumamente “bonitas” mínimamente usadas. Quizás recuerdes, no hace tantos años, las primeras aplicaciones de gestión de inventarios, contabilidad, etc., con aquellas feas interfaces “gráficas” en modo carácter, y que en su momento se usaban masivamente. Se usaban porque el problema que resolvían era tan necesario que hacía que los usuarios superaran cualquier problema de usabilidad.
Si tu aplicación es para ti maravillosa, pero al usuario le facilita más la vida usar el Word que usar tu aplicación… ahórrate en mejorar la interfaz y la usabilidad. Quizás tienes un problema en los requisitos. Quizás no detectaste realmente la necesidad del usuario. Quizás falta innovación.
En aquellos días, cuanto intentaba explicar esto a aquella empresa que os contaba al principio, que creía que sus problemas venían solo de que la interfaz “no era bonita”, intenté hacerlo con una matriz muy simple, y que os dejo en este post, por si la necesitáis en alguna situación similar.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Pingback: Bitacoras.com
Algo que debería ser obvio y no lo es. Genialmente contado