Los errores más comunes de malos diseños de software.
Hay programas que usamos por obligación, en especial en el trabajo, y otros que elegimos porque nos gusta cómo funcionan y cómo están diseñados.
Pero también hay programas odiados. Bien porque dan muchos errores, porque monopolizan recursos en la computadora (memoria, espacio en disco o CPU) o porque tienen un mal diseño que convierten en un quebradero de cabeza el simple hecho de abrirlo, hay nombres de programas que siempre salen en una conversación cuando alguien se queja de cierto programa que le da problemas.
Por culpa de un mal diseño, un buen programa se convierte en una pesadilla: acciones innecesarias para ejecutar una acción habitual que debería ser posible con un sólo clic, menús excesivamente complicados o mal organizados, preguntar demasiado al usuario o no preguntar nada e ir por libre, no ofrecer un apartado de ayuda o con respuestas generales o insuficientes, etc.
Vamos a ver cuáles son los principales errores que se cometen al diseñar la interfaz de usuario (UI) de un programa y, en consecuencia, con qué problemas de experiencia de usuario (UX) se encuentran muchos usuarios.
Un mal diseño lo estropea todo
Crear un nuevo programa no es tarea fácil. Por muy simple que sean sus funciones hay muchos pasos a seguir y muchas cosas pueden salir mal, en especial si se parte de una mala concepción. En este sentido, es relativamente habitual cometer alguno de estos errores:
Diseñar para uno mismo: A todos nos gustan las cosas a nuestra manera, pero cuando diseñas la interfaz de un programa debes tener en cuenta a quién va dirigido, qué va a necesitar, etc. Puede que a ti te guste ordenar las funciones de una manera, pero si no se las ofreces a tu público objetivo en el orden en que las necesitan, les será de poca utilidad tu programa.
Interrumpir demasiado al usuario: ¿Quiere guardar el documento? ¿Está seguro de hacer eso? ¿Está intentando hacer tal cosa? ¿Le puedo sugerir tal otra? Un programa con un mal diseño puede hacerse muy pesado si pregunta en exceso. Lo ideal es que aprenda de las decisiones del usuario y pregunte las cosas una sola vez. Demasiadas interrupciones son contraproducentes y causan rechazo.
No seguir los estándares: Hay detalles de diseño a los que estamos todos acostumbrados, como los iconos de Imprimir o Guardar, que reconocemos de un vistazo, o el orden de los menús (Archivo, Editar, etc. y al final la ayuda). Los estándares ayudan a que el usuario comprenda cómo se organiza un programa al instante. Cuantos más cambios hagas respecto a ese estándar, más le costará al usuario aprender. No se trata de copiar el diseño de los programas de la competencia, pero sí de hacer que alguien que viene de un programa se sienta a gusto con el tuyo.
Ofrecer una ayuda en condiciones: Lo ideal es que la interfaz de un programa sea intuitiva hasta el punto de no tener ninguna duda. Pero en caso de ocurrir, debemos facilitar al usuario respuestas a sus preguntas, a poder ser directas, inteligibles y prácticas. Que un programa no demasiado complejo en funciones tenga muchas consultas en Google o similares implica que no hemos hecho bien esta tarea.
Una sola manera de hacer las cosas: Siempre hay varios caminos para ir a un mismo sitio. Lo mismo ocurre con una acción. Un programa con un mal diseño tan sólo permite hacer las cosas de una sola manera. No se trata de caer en duplicidades inútiles, pero una acción habitual debe ser posible de cumplir desde varias vías (menú principal, atajo de teclado, menú contextual, etc.)
Belleza por encima de lo práctico: El diseño de un programa debe ser más funcional que estético. Diseñar botones o menús originales, que se abren y cierran, circulares o que se mueven de manera futurista pueden ser graciosos o impresionar al principio, pero al cabo de unas horas pueden resultar molestos.
Ofrecer demasiado o demasiado poco: No es fácil, pero hay que buscar un equilibrio entre saturar al usuario con un exceso de opciones y, todo lo contrario, no ofrecerle apenas opciones. En el primer caso, debemos compartimentar acciones u opciones para acceder a ellas sólo en el momento adecuado y no distraer.
Ejemplos de un mal diseño llevado al extremo
Aquí van unos pocos ejemplos de un mal diseño en un programa. Obviamente hay muchos más pero éstos son los que suelen aparecer en todas las listas y encuestas.
Microsoft Bob
El caso de Microsoft Bob es el ejemplo más práctico de cómo una mala interfaz de usuario condena al fracaso una buena idea de programa.
Para quienes no lo conozcan todavía, Microsoft Bob era un programa lanzado en 1995 para Windows 3.1x y para Windows 95 que pretendía hacer más cercano su sistema operativo para quienes nunca habían tocado una computadora.
Microsoft Bob mostraba una casa animada. Cada elemento era una función o programa, como el procesador de textos en forma de máquina de escribir. El problema es que esta interfaz era poco práctica, ya que el usuario tenía que asociar las funciones a objetos que poco tienen que ver.
Además, el programa tenía un tutorial paso a paso que se mostraba siempre, aunque lo hubieras usado ya varias veces. A esto hay que añadir que la animación era demasiado infantil (a lo que hay que añadir el uso de la tipografía Comic Sans, diseñada para Microsoft Bob pero que escapó de allí infectando textos por doquier).
Microsoft Bob hubiera tenido sentido si partiera de una interfaz en modo texto como era MS-DOS, pero con Windows ya no era necesaria, ya que la interfaz gráfica de ese sistema operativo ya ofrece una metáfora de un escritorio con documentos y programas que cumplen funciones en ventanas.
Windows 8
Otro ejemplo de Microsoft, en esta ocasión el sistema operativo. Destaco Windows 8 porque supuso un gran cambio en el diseño de la interfaz respecto a las versiones anteriores, entre Windows 95 y Windows 7.
La importancia de las interfaces táctiles en smartphones y tablets hizo que Microsoft se adaptara a los cambios incluyendo funciones táctiles y un entorno muy tablet para un sistema operativo que principalmente se iba a usar en computadoras al uso.
De ahí que no tuviera la acogida esperada, si bien los cambios introducidos en Windows 8.1 y 10 han apagado las críticas iniciales.
El problema del diseño de la nueva interfaz de Windows 8 es que no respetaba el uso mayoritario de sus usuarios, por lo que sólo una pequeña parte se veía beneficiada, quienes usaran tablets tipo Surface o similares o computadoras con pantalla táctil, una minoría aún a día de hoy.
Por otro lado, muchas funciones sufrieron el rediseño, como por ejemplo los muchos pasos que había que seguir simplemente para apagar la computadora. De ir a Inicio > Apagar se pasó a Inicio > Configuración > Energía > Apagar. Innecesario y desesperante.
Apple iTunes
Apple cuida mucho el diseño de sus dispositivos y computadoras y también de su software, pero hay excepciones flagrantes como es el caso de iTunes.
Los problemas con iTunes vienen de lejos. Se conocen quejas de usuarios desde sus primeras versiones por lo complicado que era gestionar un iPod desde iTunes.
En la actualidad, el principal problema de iTunes es que ofrece demasiado. iTunes es un gestor de iPhone/iPad, una tienda de música, un reproductor de podcasts, una tienda de películas, series y documentales, un reproductor de vídeo, una tienda de aplicaciones para iOS y un repositorio y tienda de cursos y material educativo de institutos y universidades. Y seguro que me dejo algo.
En este sentido, se hace complicado saber en qué sección estás de iTunes. Un ejemplo es la homogeneidad entre la tienda de música de Apple y su servicio Apple Music, y es demasiado fácil salir de Apple Music y caer en la tienda, pagando por una canción o disco cuando lo tienes incluido en tu suscripción.
Por otro lado, cada nueva versión de iTunes trae consigo un rediseño de los menús, de manera que si ya te habías acostumbrado a cambiar entre funciones, al actualizar tienes que volver a aprender cómo ir de la App Store a la Music Store, por ejemplo.
La solución no es sencilla, pero viendo el ejemplo de iOS, tal vez iTunes debería dividirse en varias aplicaciones para evitar el caos en el que se ha convertido.