Las puertas Norman – Cómo hacer mejores interfaces de usuario

Publicada en WordPress.

Hace un par de meses estaba echando la tarde viendo vídeos en YouTube y me saltó uno muy interesante que hablaba sobre puertas. En el vídeo, se ve una oficina con una puerta que todo el mundo parece odiar. ¿Por qué? Porque siempre que alguien la intenta abrir lo hace mal. ¿Tiras de ella? Lo siento, tocaba empujar. ¿Decides empujar? ¡Mal! Desde aquí hay que tirar. Qué chorrada de vídeo, ¿no? Todo el mundo sabe abrir puertas… ¡es imposible que esto pase!

Don Norman empezó a quejarse de las puertas hace 25 años. Según él, una puerta es un objeto lo suficientemente sencillo como para no necesitar manual de instrucciones, ya que su forma debería decirnos claramente cómo podemos interaccionar con ella. Nunca habías pensado en ello, ¿verdad? ¡Hay puertas que llevan instrucciones! Sí, ya sabes de qué hablo: los carteles de «Empujar»/»Tirar» que hay en las puertas de muchos locales. Así que, ya ves, quizás abrir una puerta no sea tan fácil. Por cierto, a las puertas mal diseñadas se las conoce con el nombre de «Puertas Norman», en honor a este señor.

Sorprendente, ¿no crees? Llevamos viviendo con puertas un montón de años. Son objetos sencillos que cumplen con un propósito sencillo. Y aún así, Norman es capaz de señalar una verdad que, por obvia, pasa desapercibida: seguimos diseñando malas puertas. Pueden ser bonitas, pueden ser seguras y pueden tener formas caprichosas… Pero, en serio, ¿tan difícil es hacerlas sencillas de usar?

Quizás te estés preguntando por qué estamos hablando de puertas en un blog de WordPress. Te hablo de ellas porque tanto las puertas como WordPress tienen algo muy, muy importante en común: los usuarios. Igual que eres un usuario de WordPress, eres un «usuario de puertas» (por ridículo que eso pueda parecer). Y viendo el vídeo me puse a pensar: si algo tan sencillo como una puerta puede generar tantos problemas, ¿qué pasa con todo nuestro software? ¿Qué pasa con los plugins que hacemos en Nelio?

The Design of Everyday Things, de Don Norman

En el vídeo aparece un libro de Don Norman titulado The Design of Everyday Things (algo así como «el diseño de las cosas del día a día»). Como el tema me llamó la atención y pensé que las reflexiones de Norman sobre las puertas podían aplicarse a mi trabajo, decidí que sería una buena idea comprarlo y leerlo. «Quién sabe, quizás me ayude a ser mejor programador», pensé. Y (creo que) así fue 😉

Incluso los más listos pueden sentirse totalmente ineptos cuando tienen que descubrir cómo funciona la ducha de su hotel o usar los fogones de una cocina cualquiera. Cuando se publicó el libro por primera vez en 1988, el científico especializado en cognición Don Norman quiso dejar muy claro que no se trata de la ineptitud de los usuarios, sino de un error en el diseño que simplemente pasa por alto las necesidades y la psicología de la gente. ¡Y es que los malos diseños están en todos lados! Por suerte, tampoco es imposible encontrar objetos que sean comprensibles, fáciles de usar y agradables. Después de haber sido revisado a conciencia para casar los principios eternos de la psicología con la tecnología siempre cambiante que nos envuelve, el libro es un llamamiento al buen diseño y un recordatorio de cómo y por qué algunos productos satisfacen y otros decepcionan.

La primera cosa que me sorprendió del libro fue descubrir que se publicó en 1988, hace ya casi 30 años. Empecé a temer que, quizás, estuviera un poco desactualizado… pero, sorprendentemente, todos los principios que aparecen en el libro siguen siendo completamente válidos a día de hoy. En un mundo como el nuestro, que cambia frenéticamente de forma, sorprende pensar que esto sea posible. Tal y como dice Norman en su libro:

El diseño de tecnología para satisfacer necesidades humanas y acomodar sus habilidades está determinada por la psicología de la gente. Si, la tecnología puede cambiar, pero la gente es la misma.

Un vistazo al libro

El libro (en inglés, no sé si existe una versión en español) está ordenado en los siguientes capítulos:

  1. La psicopatología de las cosas del día a día
  2. La psicología de las acciones del día a día
  3. Conocimiento en la cabeza y en el mundo
  4. Saber qué hacer: restricciones, capacidad de descubrir y feedback
  5. ¿Error humano? No, mal diseño
  6. Pensar a la hora de diseñar
  7. El diseño en el mundo de los negocios

Todos los capítulos son extremadamente interesantes, pero si tuviera que escoger sólo uno, probablemente escogería el primero. En las primeras páginas del libro, el autor presenta e introduce todos los conceptos que deberías conocer para diseñar mejores productos. Todos ellos se discuten y amplían en los siguientes capítulos, pero es que es fascinante ver todo lo que puedes aprender leyendo unas pocas páginas.

Una de las cosas que más me gustó fue la importancia que tiene la capacidad de descubrir (discoverability). Cuando interaccionamos con un producto, lo primero que tenemos que hacer es descubrir cómo funciona. Para ello, hay que tener en cuenta los siguientes conceptos (he intentado traducir los términos que usa el libro lo mejor posible, pero mantengo su traducción por si quieres investigar un poco más por tu cuenta):

  • Capacidades (affordances). Qué puede hacerse con un objeto dado un cierto usuario. Las capacidades indican qué acciones son posibles con el objeto en cuestión. Por ejemplo, una puerta se puede empujar o tirar.
  • Indicadores (signifiers). Cualquier marca o sonido (es decir, indicador que se pueda percibir) que le indique a una persona qué comportamiento o acción es adecuado. En esencia, nos dicen qué acciones tomar. Por ejemplo, la señal de Empujar en una puerta.
  • Restricciones (constraints). Sean físicas, lógicas, semánticas o culturales, las restricciones limitan el conjunto de acciones posibles y facilitan interpretar el estado. Por ejemplo, un botón desactivado es una restricción.
  • Mapping. Se trata de un concepto tomado de las matemáticas, el cual se refiere a la relación que existe entre dos conjuntos de cosas. El mapping es muy importante en el diseño de controles y pantallas. Por ejemplo, imagina el mapping que existe entre los interruptores de la luz y las luces (qué interruptor enciende qué bombilla) y si realmente es un buen mapping o tienes que ir probando para descubrir quién enciende qué.
  • Feedback. Comunica el resultado de una acción. Para ser efectivo, debe ser inmediato. Para darte cuenta de cuán importante, piensa simplemente en el montón de «sensores» de feedback que tenemos en nuestros cuerpos: vista, oído o tacto, así como la capacidad de propiocepción.
Conceptos de restricción y feedback aplicados a un botón
En la imagen, podemos ver claramente los conceptos de «Restricción» y «Feedback» de los que nos habla Norman. Una entrada no puede crearse hasta que todos los campos estén completados. Si nos ponemos encima del botón de creación, aparece un mensaje indicándonos el porqué y/o cómo solucionarlo.

El programador perezoso

Uno de los pasajes que más me gustaron del libro está en el segundo capítulo. Como ya sabes, hoy en día nos pasamos un montón de horas rellenando formularios en el ordenador. Nombres, fechas, números de teléfono, direcciones de correo, cantidades de dinero… ¡estamos siempre metiendo datos! Según Norman (e imagino que coincidirás con él), el principal problema que tienen los formularios es su rigidez. Tienes que introducir la información exactamente como el programa la espera o no funcionará. Y, lo que es peor, muchas veces no descubres que lo has hecho mal hasta que intentas validar el formulario y te indica qué está fallando (y, ojo, porque a veces no te dicen ni eso…).

Lo que suele pasar cuando nos encontramos con problemas así es que nos echamos la culpa a nosotros mismos, sobretodo si nos pasa mientras usamos un programa que, se supone, sabemos usar. Ahora bien, ¿por qué no preparamos los formularios para que acepten las diferentes formas en las que una persona puede introducir los datos y que sean ellos los que se adapten a nosotros? Norman pone el siguiente ejemplo en su libro:

Piensa en el calendario de Microsoft. Si usas este calendario podrás especificar las fechas como quieras: «23 de noviembre del 2015», «23 Nov. 2015», «23/11/15», o «23-11-15». De hecho, incluso acepta cosas como «una semana después del jueves», «mañana» o «ayer». Lo mismo con las horas: puedes poner «3:45 pm», «15.35», «en una hora» o «tres y media». ¿Los números de teléfono? No hay problema, ponlos seguidos, con puntos, espacios… como quieras (…)

Genial, ¿no crees? Sin duda es muchísimo mejor que forzar al usuario a meter los datos en un formato rígido y preestablecido. Pero, a pesar de las claras ventajas que el escenario anterior tiene, seguro que puedes encontrar un montón de ejemplos actuales donde es imposible encontrar esta flexibilidad. Así que, si es posible hacerlo mejor, por qué (los programadores) no lo hacemos? En mi opinión, por dos motivos: pereza y restricciones de negocio.

Desde el punto de vista del programador, es más sencillo enseñarle al usuario qué formato acepta nuestra aplicación que implementar esta «capacidad de adaptarse». ¿Por qué? Porque es menos código por nuestra parte y si el usuario se equivoca… pues, oye, la culpa es del usuario; yo ya le dije cómo iba el programa e incluso le di un manual de instrucciones. Pero las personas no somos máquinas, no nos gustan los formatos rígidos; queremos flexibilidad, queremos poder recuperarnos de los errores (¿alguien dijo diálogos de confirmación?), queremos que si nos interrumpen con una llamada, el programa nos diga por dónde íbamos para poder continuar…

Diálogo de confirmación clásico
Ejemplo de un diálogo de confirmación clásico. Si el usuario está a punto de borrar una entrada, ve este diálogo para evitar errores. Fíjate que, por defecto, el botón «Cancelar» es el que tiene el foco. Además, el botón de borrado usa el rojo (color chillón) para que resulte aún más evidente la acción que se está a punto de realizar, además de acompañarse con un texto claro.

Reconozco que yo soy de los que pensaba que escribir código «para los usuarios» era aburrido. A fin de cuentas, todo ese código es tangencial a las funcionalidades principales de mi producto. Pensaba que no añadía valor. ¡Pero estaba equivocado! Dicen que la calidad está en los detalles. Quizás tuviera razón cuando pensaba que dedicar (algunos de) nuestros recursos a mejorar la experiencia de usuario impiden que añada funcionalidades interesantes al producto, pero a cambio consiguen que éste sea mucho más amigable y que usarlo sea más agradable. Y créeme cuando te digo que, a la larga, las sensaciones e impresiones que tengan tus usuarios al usar el producto es lo que determinará realmente su valor.

Borrado de tareas editoriales con confirmación integrada
En esta captura de pantalla puedes ver un icono indicando que se puede borrar una tarea editorial. Cuando el usuario activa la acción, aparece un pequeño mensaje de confirmación, perfectamente integrado en la interfaz, para evitar sustos.

Trabajando con las restricciones de negocio

Aparte de la pereza tenemos las restricciones de negocio como limitación para conseguir esa experiencia perfecta. El último capítulo del libro se centra en todas las restricciones a las que nos vemos sometidos cuando diseñamos algo. Los primeros seis capítulos argumentan el «caso ideal»; aquél en el que podemos seguir los principios del diseño centrado en las personas a rajatabla, sin ningún problema. No obstante, el mundo real está muy lejos de este ideal: la competencia, los costes y las planificaciones son límites reales que entran en conflicto con nuestros requisitos ideales de diseño. En mi opinión, es un acierto que Norman hable de esta realidad en su libro, ya que te ayuda a poner en perspectiva todas las lecciones de los capítulos anteriores. Al final, tienes que ser tú quien decida qué peso quiere dar al «diseño» y qué peso tiene «el negocio».

Aplicando los principios de diseño a nuestros plugins

Después de leer el libro de Norman puedo asegurarte que aprecio y valoro la importancia de la experiencia de usuario como nunca antes. A ver, no estoy diciendo que antes no me importara… pero creo que ahora tengo una nueva perspectiva que me empuja a ser mejor programador. Me explico, cada vez que me planteo un cambio en nuestra interfaz de usuario, pienso en el usuario y en sus necesidades, pregunto a amigos y compañeros. En definitiva, intento que realmente el diseño gire alrededor del usuario y no al revés.

Preguntas como «¿para qué sirve este nuevo componente?», «¿entenderá el usuario qué hace esto aquí?», «¿es útil?», «¿molesta?»… son las que me planteo e intento resolver. Quiero que nuestros usuarios disfruten usando nuestros plugins, que no sean un estorbo y que se sientan cómodos…

Ejemplo de un indicador en el calendario de Nelio Content
Ejemplo de un indicador sutil en nuestro calendario. Si el calendario incluye información adicional por arriba o por debajo de la vista actual, se añade una sutil sombra que indica al usuario la posibilidad de subir y bajar con el ratón.

Tengo la sensación de que cuando empieces a usar nuestro nuevo plugin, Nelio Content, en seguida notarás cómo hemos aplicado las lecciones del libro. Lo estuve leyendo mientras programaba la interfaz de usuario y la mayoría de los principios que comenta Norman están aplicados de un modo u otro en nuestro producto. ¿Quieres ver qué pinta tienen estos principios en nuestro nuevo plugin? Echa un segundo vistazo a las capturas que he compartido en la entrada; ¡todas ellas son de la beta de Nelio Content! 😇

Ejemplo de indicadores para añadir mensajes sociales
Diferentes indicadores (un botón y la silueta de un mensaje social) le dan a entender al usuario que puede añadir mensajes sociales en una cola de publicación.

En resumen, si quieres mejorar tus conocimientos sobre la psicología humana y aprender a hacer mejores productos, léete el libro de Norman.

Por cierto, si te has quedado con la duda sobre cómo hacer una buena puerta, es muy fácil. Si tienes que empujar, pon una superficie plana. Como no tiene ningún objeto físico que puedas coger, la única acción posible será empujar (affordance). Además, la superficie en cuestión (signifier) te indicará en qué parte hay que empujar. Si hay que tirar pon una tirador; se trata de un elemento que puedes coger y que invita a ser cogido, y el movimiento lógico es tirar de él.

Imagen destacada de Federica Campanaro.

FlojaNo está malBienMuy bien¡Impecable! (1 votos, promedio: 5,00 de 5)
Cargando…

Deja un comentario

No publicaremos tu correo electrónico. Los campos obligatorios están marcados con: •

He leído y acepto la Política de privacidad de Nelio Software

Al marcar la casilla de aceptación estás dando tu legítimo consentimiento para que tu información personal se almacene en SiteGround y sea usada por Nelio Software con el propósito único de publicar aquí este comentario. Contáctanos para corregir, limitar, eliminar o acceder a tu información.