El botón de los 300 millones de dólares. Diseñar un botón como ejercicio

El botón de los 300 millones de dólares

¿Conocéis la vieja historia del botón de los 300 millones de dólares que contó Jared M. Spool en el 2009 (The $300 Million Button)? Es interesante. Cómo al cambiar, entre otras cosas, el texto de un botón, mejoró en 300 millones de dólares las ventas anuales en una web de comercio electrónico.

¿Qué ocurrió? ¿cómo pudo afectar tanto a las ventas el cambio de un botón?
Contexto: en una web de comercio electrónico, al comenzar el proceso de compra tras tener el carro con la compra deseada, aparecía un formulario en el que se pedía el usuario, la contraseña, y la posibilidad de entrar en la página web (para confirmar la dirección de entrega y el medio de pago) o la de darse de alta. Ah, y también el enlace de olvido de contraseña.

Es decir, algo como:

Campo de usuario, contraseña, botón de acceso y vínculos de olvidé mi contraseña y darme de alta.
Recreación libre del formulario del carro de la compra.

¿Qué problemas podían haber (recordemos, año 2009)? De todo tipo:

  • Usuarios que no quieren registrarse en la web (sólo querían comprar).
  • Usuarios dados de alta que dudan cuál es la dirección de correo electrónico que tienen como usuario.
  • Usuarios que se habían dado de alta con varias direcciones de correo electrónicas diferentes.
  • Usuarios que no recuerdan la contraseña.

La consecuencia: en esa página se producía un cuello de botella que impedía finalizar la compra.

La solución: tras realizar pruebas con usuarios, pasa por cambiar el literal de un botón (de «darse de alta» a «continuar»), e incluir un texto indicando que se puede comprar sin darse de alta.

El resultado: 15 millones más de ventas en un mes, y 300 millones en un año (de ahí el sugerente título del artículo para los que se excitan con dólares).

Diseñando un botón: un elemento fundamental

Siempre me ha intrigado el proceso que está detrás de la toma de decisiones en un diseño. El porqué.

Porque se supone que detrás de una decisión de diseño (particularizando en una página web: fuente, tamaño, color, posición, rejilla,…) debería haber motivos que fundamentan esa decisión. ¿Cómo ejercitar esa habilidad o conocimiento?

What if, instead of trying to design an entire page with dozens of elements (nav, text, input controls, a logo, etc.), we consciously started by designing the simplest thing possible? We deliberately limit the playing field to one, tiny thing and see what we learn? Let’s try.

What is the simplest possible element? I vote that it’s a button.

The King vs. Pawn Game of UI Design — Erik D. Kennedy

Enumeremos algunas características de un simple botón:

  • tamaño
  • texto
  • fuente
  • tamaño y efecto de la fuente
  • color de fondo (¿gradiente de colores?)
  • color del texto
  • acompañar o no de un icono
  • padding (separación del texto y el borde)
  • margen (separación entre el botón y el resto de los elementos)
  • forma (esquinas cuadradas, redondeadas, radio de la redondez)
  • tipo de acción que realiza (continuar un proceso, acción «peligrosa», acción neutra, acción principal, acción secundaria,…)

Podemos delegar varias características al estilo por defecto que tenga el navegador (en el caso de una página web), o a algún framework con posibles síntomas de vigorexia.

O podemos diseñar un simple botón. Con el objetivo de cumplir los requisitos del proyecto (real o ficticio). Intentando argumentar cada característica. Me parece un ejercicio muy saludable.

¿Qué falla en un diseño? El test de Can’t Unsee

Hace casi diez años (sí diez años), publiqué por el blog diseño, creatividad y dos test en el que hacía referencia a dos test de Andy Rutledge de los que se podía aprender mucho: en un test aparecía la solución, en otro había que investigar más… . Al final, una de las conclusiones es que la lectura de Universal Principles of Design, Revised and Updated era muy recomendable para conocer las respuestas al test y mucho más.

Con diferencia, Universal Principles of Design es el libro con el que más he aprendido.

Hoy recomiendo dar un vistazo a Can’t Unsee. Un test en el que vemos dos versiones sutilmente diferentes en el que hay que elegir aquella opción de que está mejor diseñada. ¿La diferencia? En ocasiones es muy sutil: es cuestión de detalles. Y ya sabemos…

Los detalles no son detalles, son lo que define el diseño.

Charles Eames

Disponible la UNE-EN 301549:2019 de accesibilidad

Ya está disponible la UNE-EN 301549:2019, la norma sobre accesibilidad web y aplicaciones móviles. Primero de pago en la Asociación Española de Normalización (une.org: UNE-EN 301549:2019) y más tarde en el portal de Administración Electrónica de forma gratuita ( administracionelectronica.gob.es: 301549:2019).

¿Qué es la UNE-EN 301549:2019?

En pocas palabras es una norma técnica sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público. En la norma se establecen los condicionantes, con respecto a su accesibilidad, que deberán cumplir todos los sitios web y aplicaciones móviles del sector público: estatal, regional, local, universitario, etcétera incluyendo también a los de los servicios gestionados por éstos entes como centros sanitarios y educativos, bibliotecas públicas, tribunales y órganos constitucionales, etcétera.

Origen de la norma UNE-EN 301549:2019

De nuevo, simplificando mucho, la cadena que empieza por las recomendaciones del W3C sobre la pautas de accesibilidad del contenido web, al final influye en la legislación europea (Directiva UE 2016/2012) que a su vez se traslada a la legislación española (el Real Decreto 1112/2018 traspone la directiva europea). Con respecto a la legislación, está «todo» dicho. Con respecto a los normas técnicas (o estándares),… se redactan diferentes versiones de la EN 301 549 (a día de hoy, la última, que incluye la versión WCAG 2.1 es la EN 301 549 V2.1.2) que a su vez se traslada a la norma española: la UNE-En 301549:2019 de la que estamos hablando.

La norma, de casi 200 páginas, presenta una serie de requisitos para diferentes contextos:

  • Requisitos genéricos
  • Comunicación bidireccional por voz
  • Video
  • Hardware
  • Web
  • Documentos no web
  • Software
  • Documentación y servicios de apoyo
  • Acceso a servicios de emergencia

Tiene también dos tablas, una que muestra los criterios de accesibilidad de páginas webs (Tabla A.1) y otra sobre accesibilidad de aplicaciones móviles (Tabla A.2).

Por último, el anexo C, determinación de conformidad, recoge los medios necesarios para determinar la conformidad con los requisitos individuales que figuran en el cuerpo del documento. Casi cien páginas en el que aparecen todos los requisitos –algunos, recordemos, originarias de las WCAG 2.1–, y las condiciones para superar o no los requisitos de accesibilidad.

Importancia de la UNE-EN 301549:2019

Sin duda, la UNE-EN 301549:2019 es un documento de gran importancia, no sólo para los profesionales y empresas relacionados con la Administración Pública (se tiene que aplicar), también en general, para los que están interesados en la accesibilidad web: el hecho de proponer unas pruebas para verificar o no el cumplimiento de los requisitos (y pautas) creo que tiene mucho valor, ya que, aparte de saber cómo comprobar los requisitos, permitirá evitar, en cierta medida, los sesgos que surgen al interpretar los requisitos.

Modelo europeo de declaración de accesibilidad para el sector público

Como epílogo, ya que reunimos de forma indirecta algunas novedades de los últimos meses sobre accesibilidad web (por ejemplo, la versión 2.1 WCAG), menciono otro documento, también importante: recomendaciones para realizar el modelo europeo de accesibilidad. Hablamos de «ése enlace» que pone accesibilidad en el pie de las webs. El documento puede servir de referencia y no sólo para las webs (y aplicaciones móviles) de las administraciones públicas.

Un para de detalles importantes: En las administraciones públicas debe tener el 20 de septiembre del 2019 (para sitios nuevos) o el 20 de septiembre del 2020 (para las webs ya publicadas) un ente (persona, grupo, departamento, unidad,…) encargado de recibir las comunicaciones sobre requisitos de accesibilidad, que además de poder presentarse mediante un correo electrónico o formulario, debe tener al menos un canal complementario, que puede ser u teléfono o una oficina física.

Otra unidad, departamento, grupo… que debe existir es la Unidad Responsable de Accesibilidad (artículo 16 del Real Decreto 1112/2018 ya mencionado).

La pregunta final: ¿se cumplirá?

Referencias

Cómo crear un diseño más simple

En una época –la de las constantes distracciones–, en la que encontrar el foco puede considerarse una hazaña, la sencillez y la simplicidad tienen aún más importancia.

Es bastante conocido el ya veterano libro de John Maeda The Laws of Simplicity. Con este punto de partida, Taras Bakusevych, ha desarrollado un interesante artículo titulado How to simplify your design, en el que muestra con ilustrativos ejemplos cómo encontrar esa simplicidad tan necesaria y vencer la complejidad, que clasifica de la siguiente manera:

  • Information overload
  • Randomness and disorder
  • New and foreign experences
  • Multitasking
  • Multitudes of choices
  • Rely on the user memory
  • Distractions and break the focus
  • Repetitive and monotonous operations

Consta de los siguientes apartados:

  • Build products with focused value
  • Remove everything unnecessary
  • Translate data into a meaningful format
  • Support quick decision making
  • Too many choices will scare off customers
  • Provide recommendations where multiple choices are presented
  • Draw users attention to the right areas
  • Use color and typography to communicate a hierarchy of content
  • Organizations help the system of many look fewer and more manageable
  • Group related content
  • Break up huge tasks in smaller steps, try one column layout
  • Be transparent in communicating the process and system status
  • Do the calculations for your user
  • Hide complexity with progressive disclosure
  • Rely on commonly accepted patterns and interactions
  • Design a streamlined first-time experience
  • Keep in mind ergonomics and circumstances under which product will be used
  • Support inline edit and autosuggest values
  • Use Smart Defaults to Reduce Cognitive Load
  • Prevent errors
  • Design for accessibility
Y está muy bien explicado y más desarrollado con buenos ejemplos en How to simplify your design.

Mike Monteiro, vacunas, datos y sensaciones

Mike Monteiro, autor del recomendable libro Design is a job, ha publicado otro: Ruined by Design: How Designers Destroyed the World, and What We Can Do to Fix It. Y como ahora lo de escribir en un blog se ha vuelto vintage, está publicando una lista de correo (Mike´s Monteiro Good News).

Estoy suscrito.

La última entrega empieza hablando de las vacunas, los anti-vacunas (gente que puede ser responsable de la vida de sus hijos y también puede votar), los datos, las sensaciones y el diseño.

Como buen diseñador, es partidario de utilizar los datos disponibles: es una forma objetiva de tomar decisiones argumentadas (y tengo que aprender más al respecto, confieso).

Y no deja de ser paradójico que en la época en la que más datos hay disponibles, en no pocas ocasiones al final se toman las decisiones por emociones.

Silicon Valley claims to be obsessed with data.
[…]
How to get it. What to do with it. Who’s selling it to whom. Who needs it. How to protect yours. We’ve collected more data in the last ten years than we can process in the next hundred. No one can exactly remember why we’re collecting it, but everyone’s afraid to stop. Yet, with all this data at our disposal, we’ve created a garbage fire run by platforms of vitriol. Here’s some more data: we’re idiots.
Like any good designer, I work with data. If you’re designing something for people to use and no one can use it, that’s data. You’d be a fool to ignore the data.
[…]
While you’re designing, you’re like a scientist. You study every data point. It’s the smart thing to do. Then you gotta persuade people the work is right. Hold onto your butts…
The minute you put a design solution in front of data-driven Silicon Valley types, they start talking about feelings.
“This feeeeeels wrong.”
“I’m not feeeeeeling it.”
“Oh, I like the feel of this!”
It’s a little crazy-making, but it’s also understandable. I told you people don’t make decisions based on data; they make them based on feelings.

Mike Monteiro

Datos versus emociones.

Datos y emociones.