Saber para quién desarrollamos

En el documental de Metallica, Some kind of monster, me sorprendió como Lars Ulrich nadamás se metía al Protools (software de edición de música) y le movía a todo como si nada. Y luego hablaban cosas al estilo de "no, no, ya sé, mira, métele el micro al Protools y haz esto" y luego a un periodista le explicaban el proceso creativo, primero grababan horas y horas de cada instrumento y luego en el Protools depuraban y analizaban al detalle por segundo, cortaban, pegaban, metían y sacaban trozos de la música para armar un track bien fácil. O al menos así parecía.

Lo que me dí cuenta es que ese software lo usaban como un instrumento más, dependían de él enormemente pero mira, no se preocupaban que por actualizar versiones, que por tener service packs de esto y del otro, que si guardo así o asá un archivo, me refiero, simplemente se usa, y funciona para lo que quieren.

Me vino a la mente que en un software el usuario final nadamás quiere usarlo y que le sirva. No interesa saber que si la lista de requerimientos que se puso a definir su jefe, que si las revisiones siguientes comprenderán esto sí o esto no, o que si tengo que aprender un proceso común entre cualquier programa que tengan. Simplemente "quiero hacer esto y ni pongo en duda si el software lo hace o no, quiero que lo haga". Son enfoques muy distintos de cuando uno está desarrollando.

Eduardo me dijo "desarrollamos productos para gente normal no para geeks" y es esto precisamente el punto. A veces damos por hecho (y no con mala o deliberada intención, simplemente así se nos da) que un usuario va a entender y estará familiarizado con algo tan simple como un "Browse" para buscar un archivo. Pero algo tan simple como esto es algo que puede llegar a ser algo complicado para un usuario común y algo en donde debe ayudarle "el que sabe de computadoras" de su compañía.

Entonces, si ponemos esto en mente a la hora de desarrollar nuestros productos, nuestros productos podrán llegar a ser usados efectivamente y ser funcionales para nuestros usuarios finales. Varias de las cosas ya las tenemos definidas con mejores prácticas en diseño de interfaces pero si tomamos en cuenta que nuestro software será usado como una auténtica herramienta de trabajo como lo es un martillo o una sierra para un carpintero, tendríamos en mejor consideración al usuario y a final de cuentas, un usuario feliz es un relación feliz para nosotros.