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.

4 thoughts on “Saber para quién desarrollamos

  1. La verdad es que este es un tema mas que interesante, es cierto que muchas veces asumimos un determinado nivel en nuestros usuarios y generamos unas interfaces superultra complicadas cuando tal vez con algo mas simple, le alegramos la vida a mas de uno. Yo creo que para esto lo fundamental, es tener sentido comun, algo que escasea bastante pero que nos ayuda a tener criterio en nuestras decisiones.

    Saludos

    El Bruno

    PD: q bueno llegar a esta conclusion desp de ver a Metallica !!

  2. Bueno, es una idea que tenía en mente desde que ví la interfaz del Money, allá por el 97 creo y que me llevó a ver más a fondo sobre el User Experience (aunque, en ese tiempo no se llamaba así). Luego con experiencias de amigos y colegas donde por ejemplo usar el Project o el Outlook les hacía tener una experiencia de usuario muy buena traté de detallar un poco más el tema.

    Ahora, lo de Metallica fue de ejemplo, hizo que me quedara grabada la frase "desarrollar para que se use y funcione" que fue precisamente lo que ví, ellos usan el Protools y les funciona.

  3. A veces los usuarios utilizan el sistema de formas que ni nos imaginamos.

    Quiero decir que hay pocos placeres (al menos para mi) de ver una persona usar lo que tu diseƱaste y desarrollaste y que sea parte de su vida.

Leave a Reply

Your email address will not be published. Required fields are marked *