En este artículo vamos a hablar un poco sobre la funcionalidad y la estética de los botones en las interfaces digitales. Aunque es muy probable que acabemos hablando de micrófonos de latón, Harry Potter y el clip de Office.
Aunque la idea, repito, es que hablemos de botones.
¿Pero qué es un botón?
Pues no debería ser muy complicado responder a esa pregunta, ¿verdad?
Si pensamos de manera tradicional, inmediatamente nos vendrá a la cabeza la idea de un elemento físico que se pulsa para provocar un cambio de estado de algún tipo.
De hecho, la RAE define el botón como "Pieza que se pulsa o se hace girar para activar, interrumpir o regular el funcionamiento de un aparato o de un mecanismo, especialmente eléctrico"
Así que estupendo. No íbamos mal encaminados.
Sin embargo, cuando queremos utilizar esa misma mentalidad en el diseño de interfaz surgen una serie de factores adicionales: Estéticos y Detectables (discoverability para hipsters).
La gente de producto,o el cliente de turno, se enfrentará al equipo de diseño argumentando aquello de "Necesitamos que se sepa que es un botón, porque si no el usuario no va a saber dónde pulsar”.
Y razón no les falta. Imagino que todos podemos recordar alguna ocasión en la que encontrar la acción a realizar ha sido tarea difícil. Hasta el punto de buscar en Google cómo activar o desactivar alguna característica del servicio o aplicación que estemos empleando.
Yo mismo como diseñador me he encontrado con ese problema en varias ocasiones: encontrar el equilibrio entre estética y funcionalidad. Sin embargo no debemos olvidar que diseñamos aplicaciones, servicios, productos que van a ser empleados por muchísimo usuarios, y estaremos haciendo mal nuestro trabajo si un usuario tiene problemas a la hora de encontrar un botón.
El usuario
Hemos comentado la importante necesidad de que nuestras aplicaciones funcionen para todo tipo de usuarios, así que los botones deberían ser referentes visuales de objetos cotidianos con los que realizar un símil comparativo sencillo. ¡Pan comido!
¿Os acordais de cuando apareció el iPhone? Toda esa estética similar a objetos reales: el bloc de notas, la grabadora… Esqueumorfismo creo que se llamaba.
Y no me refiero sólo a los iconos, sino también a la propia interfaz de las aplicaciones. Un ejemplo maravilloso de esto era la aplicación de notas de voz
Parece extraño entonces que las interfaces hayan cambiado tanto en tan sólo 10 años. Apenas encontramos semejanzas con elementos reales en nuestras aplicaciones: ya no tenemos micrófonos de latón ni hojas con líneas para nuestras notas.
Y esto es debido a que el usuario ha evolucionado. Ha aprendido a usar interfaces digitales.
O para ser más exactos, el usuario “tradicional” está en proceso de aprender, adaptándose a los nuevos retos que las interfaces le plantea, mientras que en el caso opuesto, el nativo digital se enfrenta a un mundo donde los botones (físicos) simplemente activan o desactivan cosas sin definir un contexto adecuado.
El contexto
Esta anécdota la he contado en clase en más de una ocasión cuando hablo del diseño digital: La hija de unos amigos, de 2 años de edad, se levantaba del sofá y se acercaba a la TV con la intención de hacer un gesto de “swipe” para cambiar de canal.
Tras haber visto a sus padres emplear el teléfono y las tablets, e incluso haber jugado a algunos juegos en el iPad, no era capaz de entender la conexión que hay entre el canal de la tele y un cacho de plástico lleno de botones que está en la mesilla del salón. ¿Cuál es la relación entre un botón específico de ese mando y la TV? ¿Por qué tiene que además apuntar hacia la TV para que la acción suceda correctamente?
Imagino que cuando lea los libros de Harry Potter, lo de volar en escoba le resultará menos extraño que la oscura magia que alberga el mando de la tele.
En el mundo de diseño de interfaces, las acciones están vinculadas al contexto. Esto surge inicialmente por la limitación del espacio en pantalla, pero actúa en nuestro favor, ya que ayuda al usuario a entender lo que puede hacer en la pantalla.
Cuando diseñamos las acciones, tenemos que tener muy presentes dicho contexto y testearlo en caso de que podamos prever algún tipo de problema a la hora de usarlo.
Retomando el ejemplo de la aplicación de notas de voz, uno de los principales problemas era que la gente pulsaba en el micrófono, en lugar del botón de “grabar” que había debajo del mismo. El diseño visual que asemejaba la realidad actuaba como barrera. La estética primaba por encima de la funcionalidad.
Y para rematar el asunto, la gráfica del botón sugería una posición por la cual la persona que usaba el teléfono para grabar algo, colocaba la parte del micrófono alejada de la fuente de sonido, en vez de voltearlo.
¿Un poco de ayuda? Por favor.
Ya que nos encontramos en un proceso de aprendizaje, siempre viene bien algo de ayuda.
Una de las cosas que podemos hacer es indicar al usuario cómo se emplean nuestras aplicaciones, dónde están los botones y para qué sirven. Y en especial si estamos diseñando una aplicación relativamente compleja que se sale de las convenciones ya establecidas como las aplicaciones de mensajería, redes sociales, etc.
Es conveniente recordar el clip de Microsoft Office. No queremos eso. Seguro que no.
Pero sí podemos añadir ayudas en pantalla cuando el usuario se enfrenta a una acción compleja, o a múltiples acciones a la vez.
Ya se que esto puede resultar un tanto polémico en la comunidad de UX/UI, sobre todo si recordamos ese dicho tan manido de “la interfaz es como un chiste, si la tienes que explicar es que no es muy buena”.
Y sin embargo en demasiadas ocasiones he visto interfaces que no funcionan por su complejidad o disposición, y que están pidiendo a gritos algún tipo de ayuda sobre cómo emplearlas. Pero claro, a ver quién es el que pone una ayuda en pantalla sugiriendo algo. Despídete de dar una charla en la ButtonConf del año que viene.
Se trata de buscar un equilibrio: Indicar al usuario de manera sutil, pero específica, lo que puede hacer y cómo hacerlo. Y en caso de duda, testearlo, como hemos comentado ya previamente.
Además, no todas las ayudas tienen que venir en formato de tooltip, modal o mascota. Podemos efectuar animaciones que inviten a la acción, emplear sonidos y/o vibraciones que refuercen nuestras interfaces, sugerir atajos si detectamos patrones de uso…
Las posibilidades son muchas.
Y en definitiva, asegurarnos que las indicaciones que estamos proporcionando al usuario para ayudarle a usar la aplicación son suficientemente claras para que no pasen desapercibidas.
Un ejemplo es el reproductor de música de Apple en iOS 10, donde se decidió que la acción de “aleatorio” no iba a estar presente en la pantalla y se cambió de sitio. Aquí hay un video donde vemos la imposibilidad de los usuarios por encontrarlo.
Sin embargo, la localización del botón se anuncia por primera (y única) vez al abrir la app mediante una animación muy sutil. Una animación en la aplicación de música.
Botones que son más que botones.
Estamos viviendo un momento maravilloso en el que los diseñadores y los usuarios van de la mano probando, experimentando y descartando nuevas maneras de interactuar con las aplicaciones:
Pinterest probó un botón que desplegaba un abanico de opciones pero no terminó de cuajar.
Por otro lado, se nos hace raro pensar en una aplicación que tenga un botón de recargar, ya que todos conocemos qué gesto hay que hacer para realizar dicha acción.
Como usuarios sabemos que un botón puede pulsarse una vez o mantenerse apretado para obtener una acción secundaria.
Y todo esto si pensamos en la parte visual de nuestras aplicaciones, pero si además pensamos en la tecnología del dispositivo al que nos enfrentamos, conviene recordar que aparte de millones de píxeles, tenemos toda suerte de sensores, como giroscopios, de proximidad, de luminosidad…
Ni Harry Potter hubiera imaginado un mundo en el que la música de tus auriculares se pausa automáticamente cuando los retiras del oído… ¡Magia!