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 : )

Contenido relacionado:

• (aquí irían posts relacionados, pero creo que no tengo nada parecido a este…)

Make everything as simple as possible, but not simpler. — Albert Einstein

Contenido relacionado:

• Sobre el valor del diseño

Pero un diseño funcional, bonito, simple y fácil de maquetar está mucho mejor.

O como dijo Charles Eames:

Los detalles no son los detalles. Los detalles son el diseño.

Habla con tu equipo de maquetación. Seguro que te enseñan cómo mejorar como diseñador.

Contenido relacionado:

• La filosofía UNIX y el diseño
• Aprende a preguntar
• La mayor cualidad de un diseñador…
• Los 10 mandamientos de Dieter Rams
• Fundamentos de diseño: lo probable, lo mínimo, lo máximo

Las 17 reglas en versión resumida vienen a decir (perdón por la traducción al vuelo):

1. Regla de Modularidad: Escribe partes simples, conectadas por interfaces simples.

2. Regla de Claridad: ser Claro es mejor que ser ingenioso.

3. Regla de Composición: Diseña programas para que se conecten a otros programas.

4. Regla de Separación: Separa las reglas del funcionamiento; separa los interfaces de los mecanismos.

5. Regla de Simplicidad: Diseña para la simplicidad; añade complejidad sólo donde sea estrictamente necesario.

6. Regla de Parsimonia: Escribe un programa complejo sólo cuando sea evidente que no existe otra solución posible.

7. Regla de Transparencia: Diseña para la visibilidad, para hacer más fácil la inspección y la corrección de fallos.

8. Regla de Robustez: la Robustez es hija de la transparencia y la simplicidad.

9. Regla de Representación: Convierte el conocimiento en datos, para que la lógica de los programas pueda ser estúpida y robusta.

10. Regla de Mínima Sorpresa: En diseño de interfaces, haz siempre lo menos sorprendente.

11. Regla de Silencio: Cuando un programa no tenga nada sorprendente que decir, no debería decir nada.

12. Regla de Reparación: Cuando tengas que mostrar un error, falla estridentemente y lo antes posible.

13. Regla de Economía: el tiempo del programador es caro; consérvalo sobre el tiempo de la máquina.

14. Regla de Generación: Evita hacer cosas a mano; escribe programas que escriban programas siempre que puedas.

15. Regla de Optimización: Prototipa antes de pulir. Haz que funcione antes de optimizarlo.

16. Regla de Diversidad: Desconfía de todo lo que diga “esta es la única forma correcta”.

17. Regla de Extensibilidad: Diseña para el futuro, porque estará aquí antes de lo que piensas.

El único cambio que creo necesario para añadirlo a mi arsenal de Fundamentos de Diseño es reescribir la regla 13 como “el tiempo del usuario es caro; consérvalo sobre el tiempo del diseñador” (pensando en la Ley de Tesler).

Contenido relacionado:

• Detalles…
• Aprende a preguntar
• La mayor cualidad de un diseñador…
• Los 10 mandamientos de Dieter Rams
• Fundamentos de diseño: lo probable, lo mínimo, lo máximo

Ahora que se habla tanto de “Design Thinking”, el concepto creatividad está más bastardizado que nunca, y no viene mal un recordatorio de que creatividad y diseño no son lo mismo (ni se parecen).

En el artículo se plantea un pequeño test de fundamentos de diseño, y una de las frases de cierre me ha conquistado:

I want those who have considered themselves to be designers but find this test impenetrable to clearly understand their lack of design competence.

El artículo va de cabeza a la lista de “referencias esenciales para presentaciones de diseño” : )

Contenido relacionado:

• Detalles…
• La filosofía UNIX y el diseño
• La ley de la conservación de la complejidad de Tesler
• Aprende a preguntar
• Los 10 mandamientos de Dieter Rams

…every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.

(Una cita de la que siempre me acuerdo, pero nunca consigo ubicar al autor. Ahora sólo tendré que buscar en mi blog en vez de en toda la internet mundial).

via Larry Tesler Interview.

Contenido relacionado:

• Los 10 mandamientos de Dieter Rams
• Para qué sirve un diseñador
• Detalles…
• La filosofía UNIX y el diseño
• Creativity is Not Design

Novedades de esta versión respecto a la anterior (v1.3.0):

• Fallos corregidos:
  • El comando ‘Set Size’ya no peta cuando le das a ‘Esc’para cerrarlo sin cambiar el tamaño de un objeto.
  • Corregido un bug con los comandos de redimensionado que hacía que Fireworks se volviera loco después de redimensionar un grupo de objetos.
• Nuevos comandos
  • Export » All Pages as PNG 24, que exporta todas las páginas del documento en PNG 24
  • Set Page Name, para cambiar los nombres de las páginas sin usar la interfaz demencial de Fireworks
  • Dos comandos de texto: Join y Join With… para fusionar cajas de texto
  • Dos comandos de páginas: Vertical Trim y Vertical Trim All Pages, que recortan las páginas verticalmente al tamaño de los elementos que haya en la página.

Postdata: estoy en proceso de actualizar el sistema que genera la documentación, y de momento la versión en castellano está un poco por detrás de la versión en inglés. Si quieres ver la documentación más reciente, la tienes disponible (en inglés) en http://github.com/bomberstudios/fireworks/blob/master/README.markdown

Contenido relacionado:

• Presentando OrangeCommands
• Reflexionando sobre herramientas…
• Atajos de teclado en Fireworks
• Reticulator v1.6.9
• Reticulator 1.6.2

Si eres lector habitual de este blog, ya sabrás cual es, en mi opinión, uno de los pilares de la productividad y la innovación.

En la línea habitual de “haz más haciendo menos”, Orange Commands surge de la imperiosa necesidad de perder menos tiempo haciendo cosas aburridas en Fireworks, para poder dedicarlo a menesteres mucho más interesantes.

La segunda motivación para Orange Commands es que me gusta trabajar a pantalla completa sin ninguna paleta abierta. ¿Las razones?:

• Porque uno es así de raro.
• Porque la interfaz de Fireworks es tan lenta que cuando ocultas las paletas va mucho más rápido.
• Porque la interfaz de Fireworks es fea.

Vale, suena bien… ¿qué hace Orange Commands exactamente?

Pues empezó haciendo retículas (y llamándose Reticulator), y a día de hoy (que vamos por la versión 1.3) hace todas estas cosas (y alguna más, abajo tienes la lista completa):

• Redimensionar objetos con el teclado. El por qué Adobe no ha puesto esto de serie en Fireworks continúa siendo un misterio…

  Si piensas que no necesitas redimensionar objetos con el teclado (que es lo mismo que pensé yo cuando Keko me pidió que le programara estos comandos) es porque todavía no lo has hecho. Si sólo me tuviera que quedar con una cosa de Orange Commands, sería esto…

• Cambiar la transparencia de objetos con el teclado, que es algo que Photoshop tiene (mas o menos) pero Fireworks no tenía. Otra cosa que piensas que no vas a necesitar hasta que un día te sorprendes no pudiendo vivir sin ella.

• Cambiar el color de relleno, de línea y de fondo de documento con el teclado, que es algo esencial si no quieres tener abiertas mil paletas (¿he dicho ya que Fireworks funciona mucho más rápido con las paletas ocultas?)

• Exportar la página actual como un PNG a 24 bits con un sólo atajo de teclado, sin abrir la ventana de previsualización (¿adivinas por qué? porque es lenta de cojones) y sin tener que cambiar opciones en ninguna parte. Con este comando puedes tardar entre 1 y 5 segundos en mandarle a alguien por email un pantallazo de lo que estés haciendo :)

• Reticulator, nuestro viejo conocido, ahora tiene un atajo de teclado para la retícula más habitual (la 960-16-9).

• Rodear de guías una selección con el teclado. Selecciona lo-que-sea, dale a , y tendrás cuatro guías enmarcando tu selección. Esto debo usarlo unas 400 veces al día, y la inspiración (y el atajo de teclado :) vienen directamente de TextMate.

• Posicionar elementos con el teclado. ¿He dicho que Fireworks es lento?

• Y más cosillas…

¡Cáspita!, ¡Zapateta!, ¡Repámpanos!… ¡Lo quiero!

Estás de suerte, porque Orange Commands es gratis total. No sólo es Software Por La Patilla™, sino que es código abierto (a modo de homenaje a todas esas almas caritativas que han sembrado el mundo de software libre molón del que nos aprovechamos todos los días y que incluso nos da de comer)

Si eres de esa gente rara que quiere ver el código fuente, lo tienes disponible en http://github.com/bomberstudios/fireworks (por si quieres asegurarte de que los comandos no ejecutan nada raro, ni se beben tu cerveza, ni te levantan a la novia por la espalda sin avisar)

Si eres gente normal, tienes los comandos para descargar, y toda su documentación, en la página de Orange Commands

¡Feliz semana!

Contenido relacionado:

• Orange Commands v1.4.0
• GTD con papel
• Reflexionando sobre herramientas…
• poor man’s version control
• Atajos de teclado en Fireworks

Contenido relacionado:

• Orange Commands v1.4.0
• Presentando OrangeCommands
• cambiando de servidor
• ¿Post largo, o post corto?
• Atajos de teclado en Fireworks

Un consultor te hablará de “oportunidad”, “desafío” o “reto”, pero nunca te dirá “tienes un problema”.

En el mundo del diseño, donde nos gusta llamar a las cosas por su nombre, nos dedicamos a resolver problemas, y para ello una de las habilidades imprescindibles en nuestro arsenal es saber preguntar.

Un método para encontrar problemas

Definición: Cuando en este post digo “saber preguntar”, me refiero a “una colección de técnicas que nos permiten obtener toda la información necesaria para localizar y empezar a resolver un problema de comunicación de forma eficaz”.

Reflexionando sobre mi forma de preguntar, estas son algunas claves que he encontrado, sin ningún orden aparente:

• Saber preguntar implica identificar el contexto del problema.

  “Contexto” puede ser algo tan obvio como “presupuesto”, o algo tan sutil como la agenda oculta del jefe de nuestro cliente. Yo diría que la gran mayoría de los “imprevistos” en el desarrollo de un proyecto provienen de un contexto poco investigado.

• Aunque parezca una obviedad: tu misión es averigüar cuál es el problema en realidad.

  No lo que el cliente dice que es el problema.

  No lo que el cliente piensa que es el problema (a veces un cliente no dice todo lo que piensa. Por eso preguntamos :).

  No lo que el cliente está haciendo o quiere hacer para solucionar su problema.

  El problema.

• Si no sabes qué quiere conseguir tu cliente, no sabrás si has solucionado su problema.

  Para esto vienen muy bien metodologías como el “Effect Management” de inUse, o algo tan simple como un checklist de objetivos.

• Preguntas clásicas

  • ¿por qué?

    Te servirá para descubrir la motivación de tu cliente. La idea es preguntar por qué ad-infinitum, con la sana intención de encontrar “el momento ¡ahá!”, esto es, el momento en que el cliente decide pasar de la idea a la acción, el momento “detonante” de la decisión de actuar, el origen del proyecto.´

    Sólo si eres capaz de ponerte en el papel de tu cliente en el momento de tomar la decisión de contratar a un diseñador, serás capaz de resolver su problema real.

    A mi me gusta llamarlo “ver el big bang en directo” :)

  • ¿para qué?

    O “qué se supone que tiene que conseguir esta jugada”. Ya sea “más usuarios registrados”, “registro en 5 minutos” o “mejorar la imagen de la marca”.

  • ¿quién lo pidió?

    Esto es algo que casi nunca preguntamos, pero es vital. No es lo mismo resolver los problemas de tu cliente que los del jefe de tu cliente.

  • ¿qué quieres conseguir?

    Que no es lo mismo que “para qué”. Aquí es donde intentamos detectar si nuestro cliente tiene algún tipo de “agenda oculta” o motivación personal no documentable, por ejemplo “quedar bien con dirección”, “justificar la existencia del departamento”, o “llamar la atención en medios de comunicación”. Por muy marciano que suene, este es el tipo de información que puede convertir un potencial infierno en un proyecto redondo.

Como cierre de este tostón, un apunte breve: obtener información preguntando es tu obligación como (buen) diseñador.

Y así de repente, creo que es todo lo que se me ocurre sobre obtener información. Algún día veremos qué hacer con ella :)

Contenido relacionado:

• Detalles…
• La filosofía UNIX y el diseño
• La mayor cualidad de un diseñador…
• Los 10 mandamientos de Dieter Rams
• Fundamentos de diseño: lo probable, lo mínimo, lo máximo