Listas Blancas y Listas Negras

Los principios de un buen diseño

Cuando hablo con ingenieros, programadores o desarrolladores intento explicar que un diseñador de interacción tiene como labor “traducir” lo que ellos crean al idioma de los usuarios. Este proceso consiste sobre todo en poner una capa, crear un envoltorio alrededor del producto que presentado al usuario comunique como funciona, para que vale y que se puede hacer con ello intuitivamente.

Multitud de veces me dicen que no es necesario, que ellos han sido formados en las mejores escuelas, que sus productos siempre muestran toda la información posible, que sus procesos estan diseñados con UML y tres mil argumentos más. Algo perfectamente válido. Pero lo que también es cierto es que cualquier disciplina educativa lo primero que hace es grabar a fuego en la mente de sus aprendices una nomenclatura que solo entienden ellos, como es el caso de las listas negras y las listas blancas, esas grandes desconocidas.

Mi definición:

Una lista blanca es una lista de items sobre los que existe una discriminación positiva. Es decir, existe una condición previa solo se aplicará a la lista de items y a ningún otro.

Una lista negra es una lista de items sobre los que existe una discriminación. Es decir, existe una condición previa que no se aplicará a la lista de items.

¿Cuál creeis que se entiende más rápidamente? ¿cuál creeis que tiene un nombre más positivo? Yo me maree la primera vez que me lo intentaron explicar, la verdad. Negra me sonaba a negativo, a malo, a mal rollo, mientras que blanca rezumaba bondad por todas partes. Pero lo cierto es que las listas son bastante agnósticas en ese sentido, porque dependen mucho de la “condición” sobre la que se apliquen.

Por ejemplo, imaginaros que a una persona le dais la opción de crear listas blancas o negras que limiten las llamadas que hace o recibe su teléfono móvil. En el momento en que añada un número de teléfono a su lista blanca conseguirá incomunicarse con el resto del mundo. Lo más probable es que acabe por no utilizar una funcionalidad que igual le vendria bien para evitar llamadas indeseables.

Todo este peyote lo he escrito para llegar a dos reflexiones:

  • No intentes explicar conceptos a través de tu interfaz; es mejor intentar satisfacer deseos o necesidades
  • Es más fácil conseguir que alguien te diga que cosas no le gustan que cuales le gustan por la sencilla razón de que la primera lista siempre va a ser más corta

¿Tiene sentido? No lo sé. Pero creo que vamos por buen camino.

5 Comments

  1. Esto me recuerda a un concepto que repito cienes y cienes de veces:

    Los detalles de tu implementación no le importan a nadie, y menos al usuario

    O lo que es lo mismo: si tu aplicación escupe un mensaje que dice “no se encontraron coincidencias en la base de datos” alguien debería aparecer y darte una yoya.

    Otra cosa: si sigues diciendo que el diseño es “envoltura” vendrá la policía del diseño y la yoya te la dará a ti :P

  2. Tienes toda la razón del mundo, querido Muñoz. Lo de “diseño como envoltura” es para que lo entiendan. Ya sabes, que sea algo intuitivo.

    En fin, me lo merezco.

Leave a Reply