Como el problema del icono de guardar tiene muchos matices y recovecos, lo voy a cambiar por otro problema mucho menos interesante, pero bastante más trillado que ilustra igual de bien este punto: el cambio de marchas de los coches.

Según la Wikipedia, la primera transmisión automática se inventó en 1921, y se utilizó por primera vez en un vehículo comercial en 1940. Desde entonces, los sistemas de transmisión automática han mejorado tanto que casi podríamos decir que, en 2013, un coche “normal” no necesita un cambio de marchas manual.

En el contexto de esta reflexión, llamaremos al cambio automático la “solución canónica ideal”: una solución a un problema que cumple todos los requisitos objetivos y no plantea ningún problema adicional si la evaluamos desde un punto de vista totalmente científico. Es decir: la solución que te daría el Dr. Spock si le planteases el problema.

Sin embargo, a pesar de los avances tecnológicos, muchos conductores siguen prefiriendo el cambio manual argumentando que tienen más “control” sobre su vehículo, o que pueden aprovechar mejor la potencia de su motor, o que están acostumbrados a conducir cambiando de marchas manualmente.

Para estos conductores el cambio de marchas automático implica renunciar a una serie de cualidades (casi todas solamente percibidas y no reales) que les vinculan emocionalmente con el cambio manual.

Volviendo al problema inicial: diseñar un icono de guardar es como diseñar una palanca de cambios. La solución canónica ideal no necesita ninguna de esas dos cosas. Sin embargo, es más que probable que nuestros usuarios sí. El salto cuántico necesario para sustituir los modelos mentales de un usuario hace inviable muchas veces la implementación real de una solución ideal…

La otra opción, como comentaba Diego Cano en Twitter, es recurrir a placebos: un botón de guardar que en realidad no es necesario, o una palanca de cambios que no actúe directamente sobre la transmisión.

La solución “buena” casi nunca es la solución “óptima” : )

Supón que no te contesta los mails, y no responde al teléfono, ni Whatsapp, ni SMS. Vuestros amigos comunes tampoco saben nada de él, y no publica actualizaciones en Twitter ni en Facebook.

Lo normal es que empezaras a preocuparte un poco por si está bien, y conforme pasaran los días tu preocupación por su paradero o estado de salud fuera aumentando.

Sin embargo, cuando un cliente o proveedor no contesta al mail o al teléfono no nos preguntamos cómo estará. Directamente pensamos que es un hijoputa una mala persona que nos está esquivando.

Si vemos un nuevo diseño en una web que no nos convence, el diseñador es un inútil.

Si leemos algo con lo que no estamos de acuerdo, quien lo dice es un cretino.

Si alguien pregunta algo mínimamente ofensivo es porque es un troll buscando pelea.

¿Por qué tenemos la mala costumbre de pensar siempre lo peor en situaciones del ámbito profesional?

Llevo unos días dándole vueltas al tema, y aún sin haber descubierto por qué esto es así he decidido dedicar un poco de esfuerzo a pensar bien por defecto, y a ser un poco más crítico con las conclusiones que saco de las cosas que veo, leo o escucho.

Así he descubierto cosas como que menos del 40% de los hogares ingleses tienen contador de agua, que un gestaltingenieur no es lo mismo que un coding designer, que hay quien valora más el humor que la precisión científica, y que te puedes gastar 100.000 euros en un libro.

Y sobre todo, creo que vivo más tranquilo y más feliz.

Photo Credit: clappstar via Compfight

Para un niño pequeño, un charco es un parque de atracciones.

Cuando hablemos de “diseño de experiencias”, quizá debamos pensar cuánto se parece el resultado de nuestro trabajo a “poner a un niño cerca de un charco”.

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

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

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.

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

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

…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.

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://bit.ly/PcTSMV