Muchos recordarán el antennagate, cuando el diseño de antena exterior del iPhone 4 mostró un pequeño fallo: el usuario era capaz de cortocircuitar las antenas con su mano al sujetarlo de determinada forma (una forma no precisamente extraña), degradando la recepción hasta el punto de no tener señal en algunas ocasiones. El problema era gordo, aunque también es cierto que tampoco era para empezar la tercera guerra mundial como muchos quisieron hacer. Yo mismo tuve el iPhone 4 y el fallo se convertía en problema básicamente en zonas de baja recepción; no quito peso al fallo, pero si a la publicidad que se le hizo.
Pero vayamos a lo que interesa, lo que dijo Steve Jobs al respecto: “Lo estás agarrando mal”. El meollo del asunto no fue que hubiera un error en el diseño, sino la gestión que se hizo del problema desde la empresa: sencillamente espantoso, sacar balones fuera y no querer asumir el error.
Hace un par de años se hicieron virales vídeos del tipo “Cosas que estás haciendo mal”. Estos vídeos son realmente una recopilación de hackings (trucos caseros, la gran mayoría muy útiles por cierto). Puse el ejemplo del iPhone 4 antes porque uno de esos “trucos” básicamente dice lo mismo: estás agarrando mal el brick de leche o zumo. A todos nos ha pasado que salpicamos por doquier cuando se vierte líquido desde un brick. Esto se debe a la turbulencia creada cuando el aire que entra en el envase se encuentra de frente con el líquido que sale.
En resumen, se propone girar el envase de forma que el agujero de salida quede arriba en lugar de abajo, permitiendo que el aire entre libremente sin crear turbulencia.
El problema está que esas salpicaduras no ocurren por un fallo de uso de parte del consumidor que, lógicamente y con todo el sentido común, pone la boca del envase lo más cerca posible del recipiente para maximizar la puntería (con la boca puesta como en el truco se hace más difícil acertar). El problema está en el diseño del envase que prioriza otros factores como volumen y almacenamiento frente a su uso, dejando como única salida el poner la boquilla en un lugar tan poco apto. No es que “lo estés agarrando mal”, es que está mal diseñado. No es culpa del consumidor sino del fabricante. Y el vídeo no hace sino acentuar esa percepción de inutilidad del usuario al decir que “estabas haciéndolo mal” en lugar de decir que se trata de un simple truco para compensar el fallo de diseño (lo que se conoce comúnmente como un workaround).
“Estás usando mal el software”
Lo dicho anteriormente también ocurre en muchos otros ámbitos, incluido el desarrollo de software. Creemos que es el usuario el que lo hace mal (aunque no falten numerosos ejemplos de ello) cuando nuestro trabajo, en su clímax, ¡es lograr que el usuario lo haga bien sin tener que explicárselo 10 veces! Ya lo dice Jony Ive (ex-CDO de Apple): “Pienso que nuestra meta es que tengas la sensación de que no hay diseño”, de que las cosas funcionan y ya, de que son intuitivas, de que tenían que ser así.
Es muy frecuente encontrar software cuyo diseño no ha sido pensado, donde las distintas funcionalidades simplemente se han puesto una al lado de la otra sin ton ni son; donde el flujo de trabajo sólo ha sido revisado por las personas que lo idearon, seguramente con un montón de parches en el medio; donde no se ha cuidado el detalle funcional (que muchas veces no es detalle) por tener la vista puesta en plazos o en el rendimiento (aunque no haya que descuidarlo).
Hay muchas razones para esto y no todas son por carencia de talento de sus creadores:
- falta de foco en los objetivos del software (querer hacerlo todo),
- mantener funcionalidades antiguas que no encajan con las nuevas,
- ideas geniales que sólo aplican a un pequeño nicho pero que están integradas como si fueran genéricas,
- tener que cumplir plazos de entrega muy ajustados donde no hay espacio para un equilibrio entre todas las áreas del desarrollo (funcionalidad, eficiencia, usabilidad, mantenibilidad).
Desgraciadamente los desarrolladores estamos tan metidos en el proceso de desarrollo y de pruebas que nos acostumbramos a usar el software y lo vemos como obvio, intuitivo, y culpamos al usuario de ser un inculto digital que no sabe usar nada y de ser un pesado con continuas solicitudes de soporte técnico. Somos nosotros los que tenemos que hacer que el software sea de calidad, desde sus tripas hasta el último píxel del interfaz y coma de la documentación. En este proceso entra el equipo entero de desarrollo: líderes de proyecto, product owners, programadores, diseñadores, QAs, testers, todos ponen su granito de arena y si algo falla todos tienen un poco de culpa en ello. Dejo todo este proceso a reflexión del lector.
Sí es posible
Me gustaría cerrar el artículo mostrando dos envases de leche de los que compramos en casa. El de la derecha es el típico brick tetraédrico con la boquilla en una esquina (y su consiguiente turbulencia y derrame). El de la izquierda es de otra marca donde han querido evitar ese problema con un diseño mejorado: la forma en pico de la parte superior hace que la boquilla quede por encima del líquido durante el vertido, facilitando la entrada del aire y eliminando la turbulencia. Para evitar que la pérdida de resistencia colapse el envase al apilarlos, se agregó un tabique de cartón en el medio de los empaques de 6 unidades para absorber parte del peso. En términos de coste no sé cómo afectará, pero no es el producto más caro de su género y creo que han llegado a una solución más que buena.
Los desarrolladores podemos sacar muchas ideas de todo esto, que podemos mejorar tanto nosotros como nuestros procesos, pero principalmente en los productos que hacemos, que al final son lo que más importa a nuestros clientes.
Créditos a la imagen del pulgar hacia abajo a Wikimedia Commons.
