Rinosaurio.net

Apuntes de diseño de interacción

firstkodak

Soy fan de los programas de prototipado. Me encanta poder imaginar cosas que no existen, y buscar soluciones e interacciones probando a unir unas cosas con otras.

Pero me he dado cuenta de que el auténtico prototipo es el que vive en su entorno. El que se prueba en la tecnología en la que será utilizado. Y «se pelea” con distintos sistemas operativos, pantallas y resoluciones.

A veces diseñar una interacción puede resultar sencillo en un programa de este tipo. El problema es que la cosa no se queda solo ahí. Lo sencillo sería darle ese prototipo al desarrollador y que lo convirtiese en real y funcional.

Pero ahí surgen los problemas. Incompatibilidades. Cosas que por causas externas no funcionan. Cosas que surgen en el proceso de desarrollo que a veces obligan a alterar ese prototipo. A cambiarlo.

Y esto nos lleva a pensar en algo: ¿No sería mejor crear ese prototipo directamente? Es decir, ¿montarlo junto al desarrollador con la tecnología que será implementado, y ver lo que surge, y hacia donde te lleva? ¿Analizar los posibles problemas según los vas encontrando?

En mi opinión este es el camino. Creo que existen más posibilidades de descubrir posibles problemas. Probar en distintos dispositivos, con distintos materiales, distintos contextos.

Indiscutiblemente es necesario diseñar. Pensar en ello como un paso previo. Siempre. Pero la funcionalidad lo es todo. Y el material, en este caso el dispositivo, junto al software hoy en día varía enormemente y a veces los errores se detectan tarde, cuando todo está ya montado. Y cuando hablamos de software, lo que termina de probar los prototipos son los datos reales.

Que nadie me malinterprete. Creo que los programas de prototipado tipo Axure, Pixate, Principle, Flinto, y un sinfín de ellos son más que necesarios para avanzar, descubrir, probar, mostrar funcionamientos, acercar a las personas a una idea. Pero un prototipo, un prototipo es algo más allá. Es la esencia del producto, en su habitat, con todos sus posibles problemas, virtudes y carencias.

12 Comentarios

  • Patricio dice:

    Para mi está mejor diseñar en Fireworks (or another one) y hacer prototipos funcionales en Marvel (o Invision).
    A los desarrolladores les da flojera hacer prototipos en html y los diseñadores son muy lentos en eso mismo.

    Saludos.

  • Me gusta la reflexión, Uge. Efectivamente, cuanto más cercano a la realidad es el prototipo, mejor anticipas su comportamiento.

    Y añado una reflexión: estamos de acuerdo en que lo que define a un diseñador experimentado es precisamente la capacidad de simular escenarios en su mente, por experiencia, por músculo mental y por capacidad de abstracción, ¿verdad?. Si esto es así, por lógica, cuanto más senior sea el diseñador, menos definición neesitará en ese prototipo. O dicho de otro modo: cuanto menos sepas de diseño o del ámbito de aplicación de tu producto, más definición requerirá tu testeo.

    Así lo veo yo 🙂

  • Alejandro dice:

    Estoy de acuerdo. En mi opinión, los programas de prototipado, tan de moda, sirven para crear/plasmar ideas a un medio «físico», más que para prototipar. Son como los concept cars en el mundo del automóvil, quedan muy bonitos y vistosos pero a la hora de comercializar el producto acaba siendo distinto, en ocasiones muy distinto, porque existen otras variables que no se han tenido en cuenta o no se han visto (materiales, aerodinámica, tiempos de entrega…). Quizá habría que cambiar el nombre de programas de prototipado a programas de concept.
    No es hasta que te pones con código (lo que empezaría siendo el prototipo) que te das cuenta que a lo mejor esa animación del concept no merece la pena de implementar por el tamaño del código o la carga de frames. Y es ahí cuando de verdad empiezas a trastear con un prototipo que se acerca más al producto, que el concept.

    • uge dice:

      Mil gracias por comentar Alejandro, no puedo estar más acuerdo.

      Tu respuesta denota que te has pegado con unos cuantos desarrollos 🙂

      Un saludo

  • Pablo dice:

    Muy buen post Uge! y todavía mejor el hilo que ha tomado con cada uno de los comentarios.

    Pienso que los programas de prototipado hace que personas externas a la conceptualización y definición del producto tengan una primera conexión con el resultado final.

    Comparto la reflexión de Javier en su totalidad: cuando la definición NO sale de una persona experimentada o «Senior», este paso puede incluso a ralentizar el proceso, ya que en su totalidad sirve como paso de definición y testeo que a veces se torna en doloroso.

    Podríamos decir que «todos los caminos llevan a Roma…» pero están de nuestra mano elegir el que mejor se adapta a nuestro producto… 🙂

  • Pablo dice:

    Muy buenos comentarios, espero aportar una perspectiva diferente.

    El fin del prototipo es validar conceptos y direcciones en el diseño de forma «barata», intentando que se parezca al producto final (no creo en validar wireframes en blanco y negro), pero gastando lo mínimo en tiempo y recursos disponibles, para de esta forma iterar.

    Como comenta Javier, un diseñador bueno, ya ha iterado varias veces en su cabeza, pero siempre hay cosas que hasta que no ves como son utilizadas por la gente, no puedes dar por válidas. Es muy difícil acertar a la primera.

    Hoy he estado precisamente viendo varios videos de usuarios interactuando con un prototipo hecho en marvel y aunque no todo estaba disponible o funcional como una web o app real, te da una idea sobre si varias de las cosas que asumes van en la buena dirección.

    El problema, creo, es tener claro lo que estamos haciendo. Muchos de estos programas permiten tal nivel de detalle que acabamos pensando en el producto final y no en lo que queremos validar puesto que el detalle final sólo lo tendrá el producto que vea la luz.

    Por tanto creo que es un problema de enfoque y de tener clara la intención antes de gastar tiempo y recursos.

    • uge dice:

      Muchas gracias por pasar y comentar Pablo 🙂

      Estoy de acuerdo en lo que comentas con respecto a validar conceptos, incluso probar un primer prototipo a nivel de comportamiento y ver que todo va en una buena dirección.

      Pero pueden existir más cosas que probar en un prototipo, por un lado tenemos un entendimiento del mismo por parte del usuario, pero no siempre lo tenemos con el software y el dispositivo en el que será utilizado.

      Tal y como comento en el artículo, me encantan los programas para hacer este tipo de interacciones, pero veo más práctico invertir un tiempo inicial trabajando junto al desarrollador en un prototipo rápido pero real, que en algo que quizá en el proceso de desarrollo presenta problemas de incompatibilidad o formato.

      Para mí, las dos formas son buenas, pero al final, a nivel de agilidad y resultados, me ha resultado más económica la segunda. 🙂

      Supongo que todo variará según equipos, requisitos, entornos, etc…

  • Daniel Martínez dice:

    Muchas gracias Uge, he disfrutado mucho del artículo y el debate que se ha generado entorno al uso de los prototipos.

    En mi opinión las nuevas herramientas como Principle y Silver Flows han dado en la clave. Derribar barreras técnicas y hacer accesible el desarrollo de prototipos a personas sin conocimientos técnicos, pero sobre todo lo interesante es como han conseguido acortar el tiempo que se tarda en crear un prototipo complejo en poco tiempo.

    Por otro lado también pienso que la decisión de cuando trabajar sobre un prototipo o el propio producto pasa por valorar la complejidad, los medios disponibles y sobre todos los objetivos del proyecto en la fase en que se encuentra. Todo esto sumado a la experiencia que aporta el diseñador de interacción y sus habilidades determina cual es el mejor camino a seguir.

  • Luciana dice:

    Qué buenos aportes se generaron en los comentarios. Muy buen artículo!!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *