Escribo esto después de una conversación súper interesante esta mañana a raiz de un tuit en el que hablaba sobre el «addition by substraccion» o cómo a veces lo que genera valor en un producto es quitarle funcionalidad en lugar de ampliarla hasta el infinito.
Lo hacía a partir de haber leído este artículo y de unas semanas reflexionando sobre los problemas de consistencia y escalabilidad en los que te mete desarrollar un producto B2B diciendo «sí» a todas las funcionalidades que te proponen o piden los clientes.
Estoy de acuerdo en que en muchas ocasiones los productos se hacen mejores si los haces más sencillos y los centras en una funcionalidad. El «less, but better» de Dieter Rams.
Por ejemplo: si necesitas una herramienta de comunicación y colaboración síncrona entre equipos, creo que es suficiente con la funcionalidad que ofrecen combinaciones como Slack + Drive. Meterte en el nivel de sobre-funcionalidad de cosas como Yammer creo que hace que tengas un producto cuyo uso es tan complejo que lo abandonas.
Quitar funcionalidad para simplificar el uso
Muchos de los que hacemos producto tendemos a pensar siempre en cómo optimizar una funcionalidad existente o crear una nueva, pero dedicamos menos tiempo a mirar los datos y decidir si hay funcionalidades que tienen tan poco uso o aportan tan poco valor que es mejor eliminarlas (y así quitar complejidad al mantenimiento de nuestro servicio/plataforma/whatever).
Un ejemplo que mencionaba Simón aquí: aquel dashboard que existía en MacOs pero que nadie parecía usar y decidieron eliminar después de haberle dado bastante bombo y platillo.
Esta mañana he usado el ejemplo de esta calculadora. Seguro que muchos la teníamos en el instituto pero ¿cuántos botones usábamos?
Después de debatir bastante con Javi y Kike, es cierto que si piensas en esa calculadora como un producto de nicho para científicos, no te sobrará nada de funcionalidad y necesitarás todo lo que te da.
Sin embargo, yo estaba pensando en el gran número de personas que la hemos usado en el instituto y la facultad sin rozar jamás la mitad de las teclas porque no las necesitábamos. Yo creo que en ese caso tener tanta funcionalidad en primer nivel abruma, confunde y frustra al usuario más estándar.
Es decir, que la cuestión no es sólo si la funcionalidad está o no está, sino qué jerarquía le propones al usuario para utilizarla.
Dejar la funcionalidad (cuando tenga sentido) pero jerarquizar su uso
Javier Cañada ha puesto un ejemplo mejor de los que yo estaba usando. Hay veces que no es cuestión de quitar la funcionalidad sino de ordenarla mejor para que sea más fácilmente procesable por el usuario. Y ahí es cuando hemos hablado de estrategias de diseño para hacer convivir funciones simples y complejas.
O sea, volviendo al ejemplo de la calculadora… abruma bastante menos esto ¿no? Y además como decía Javier te permite ir más allá. No sólo quitas la frustración al usuario sino que, al no eliminar la funcionalidad sino jerarquizarla, te quedas con una calculadora compleja pero que te hace sentir más capaz.
Quitar la funcionalidad (cuando ya no tenga sentido)
Aún así, hay ocasiones en las que no es tema de jerarquías. Es cuestión de que hay botones que tienes en tu producto que nadie usa y no sirven para nada. Piensa en el mando de tu televisión ¿cuántos botones usas de los que tiene?
Yo, como decía Máximo, muy pocos. Así que estoy feliz con el mando de mi tele que vuelve a eso del «Less, but better».