Diseño y Movimiento

Este post es un comentario extendido al que publica Juan Leal en su blog. Léelo para ponerte un poco en contexto del tema.

Antes de liarme a escribir y perderme, lo voy a soltar a bocajarro: si no eres capaz de enseñar en movimiento algo que se tiene que mover, no eres un buen diseñador de interacción.

Los diseñadores de interacción vivimos tiempos difíciles*. Las interfaces ricas nos exigen cada vez más nivel de atención a los detalles, y crear (buenas) experiencias de usuario requiere de nosotros una serie de habilidades cada día más variopinta.

(* puedes sustituir “difíciles” por “llenos de desafíos”, “interesantes” o “que molan”, dependiendo de tu amor por la novedad : )

Como bien dice Juan en su post, “la interacción con un dispositivo electrónico se basa cada vez más en transiciones, muy visuales, llenas de significado (las negritas son mías).

La parte vital aquí es la de “llenas de significado”. Por mucho que queramos aferrarnos a nuestra vieja definición de diseñador como “el personaje que pinta cosas estáticas”, lo cierto es que el movimiento ha llegado para quedarse en el diseño de interacción.

Cuanto antes empieces a asimilar el concepto, y a diseñar el movimiento, antes podrás disfrutar de la belleza de pensar, hacer y usar interfaces que no sólo funcionan. Además se mueven con gracia, te arrancan alguna sonrisa, o te hacen decir “esto mola mucho”.

En BeBanjo (donde trabajo actualmente) tenemos una frase que marca el final de la fase de diseño estático y el inicio de la fase de diseño de verdad: “Muy bonito. Pero esto hay que verlo en HTML”.

La gente que trabaja en animación tiene clarísimo, desde hace mucho, que el movimiento de un personaje es la clave de su personalidad. La voz, el guión, el color… son (grandes) actores secundarios, pero un personaje es su movimiento.

Obviamente, no se trata de llegar al nivel de animadores profesionales, pero un diseñador de interacción moderno, glamouroso, y con ganas de destacar en el maravilloso mundo del UX, tiene que tener en su arsenal la capacidad de poner en movimiento la interfaz que puede pintar.

Puedes buscar la ayuda de un experto en front-end / Flash / video, o adquirir los conocimientos necesarios para convertir tu idea en una interfaz utilizable con todos sus extras, pero “seguir haciendo lo mismo de siempre” ya no es una opción : )

4 thoughts on “Diseño y Movimiento”

  1. Gracias a ti por aportar este extra. Notaba que me faltaba algo de chicha y tu lo has terminado de cerrar. Lo creas o no me he parado cuando he llegado a la frase “llenas de significado”, y vas tú y lo sacas con más pecho, juas :)

    Es justo ese tándem UX+Front el que hecho de menos en cada vez más proyectos para poder sacar cosas mucho más agradables al ojo humano, que realmente sean autoexplicativas. No es por falta de ganas, sino de tiempo, pero bien que me ponía a aprender con Flash/Vídeo…

    Genial. Como siempre.

  2. Completamente de acuerdo, ahora eso si, yo personalmente no lo llevo “nunca” a la practica no por falta de ganas, sino más bien por falta de tiempo. Aunque eso una vez más, es solo una excusa :)

  3. Yo sólo quería comentar que hay varias formas de enseñar un diseño sin tener que llegar a HTML.

    Para los flows de usuarios se debe dibujar inicialmente con algo de detalle como borradores de las distintas pantallas. Crear un modelo de baja resolucion para representar una interacción con movimiento.

    Se puede hacer un test basico de usabilidad, y sacar conclusiones para empezar a darlke mas resolución al diseño. Cuando tienes las pantallas en Fireworks 1) Se puede hacer otro prototipo en papel o… 2)… es facil pasarlo a un HTML impuro y hacer otro test de usabilidad. En un documento es facil representar los flujos. Un mapa del flujo y las posible decisiones del usuario representan claramente la linea temporal. Luego se correlaciona la pantalla dentro del mapa.

    Una vez que se tenga lijen las asperezas se crea la capa grafica y el HTML final. Luego se pueden añadir las diferentes transiciones de JavaScript para crear mejores transiciones entre los distintos pasos.

    El problema de ir desde un principio a HTML es que se necesita un esfuerzo para diseñar y codificar un diseño que puede cambiar. Al final el proyecto puede salir caro.

    Este proceso es el ideal, pero todos sabemos que normalmente el proceso de diseño no tiene peso en las cabezas de muchos clientes. Quieren un producto final para ayer. Aunque poco a poco están más educados al respecto, hay que hacerles entender que en total un buen proceso en la etapa de prototipación ahorra en tiempo de trabajo y mejora la calidad del producto final.

    Luego ya puedes entrar en un diseño final

  4. Que le hablen de estas cosas al co-creador del Spaceship Warlock, Radiskull y Devildoll…

    Un tal Joe Sparks. Hace tiempo que trabaja en Google…

nos encantaría oir tu opinión...