¿Se han fijado en la fachada de las tiendas de juguetes Imaginarium? Tienen dos puertas: una grande (para las personas mayores) y otra pequeñita (para los niños). Desde el punto de vista informático… ¡esto es una barbaridad! Si el niño cabe por la puerta grande, ¿por qué esforzarse en fabricar una pequeñita, por la que, encima, no cabe un adulto? Un informático diría: si el caso “puerta grande” comprende al caso “puerta pequeña”… ¡sólo hay un caso! Y obvian que a los niños les encanta su puerta pequeña, que se ha convertido en una suerte de marca visual física para la marca Imaginarium, lo que permite que niños de todo el mundo identifiquen rápidamente sus tiendas; obvian que a los niños adoran disponer de una puerta a su medida… precisamente por la que no pueden pasar sus acompañantes “viejos”. Se trata de una interpretación del comportamiento plausible, de los deseos de los usuarios (y grandes prescriptores, en este caso). Por otro lado, ¿no pasa igual con las compuertas para gatos que vemos en las puertas de las películas americanas (sobre todo 
)? Aquí prima la utilidad, aunque sigue siendo cierto que el gato cabría perfectamente por la puerta para humanos. ¿De dónde viene, pues esta discrepancia informática? Opino que se trata de la conjunción de dos comportamientos demasiado bien asentados en la composición software y, por tanto, en su proceso constructivo típico:
Generalización Culpable: se recogen elementos discretos, después de caras entrevistas, laboriosas sesiones de análisis y sesudas comparaciones sobre cómo acoplar lo que hemos visto a lo que ya sabíamos que posiblemente íbamos a dar como resultado (la experiencia no es que sea un valor aquí: usualmente es el único valor). Así que tras haber segmentado los requisitos en unidades manejables, se aúnan de nuevo en una solución global… ¡que los contemple a todos! Es decir: se maneja la misma ponderación para todos los requisitos, que bien están incluidos en una solución plausible (para el analista), bien son rechazados. Pero no hay excepciones. Este comportamiento se basa en un lema intuitivo, asumido sin reparos en toda la industria informática… ¡y absolutamente equivocado!: “Cuesta menos diseñar una interfaz común que diseñar una interfaz (y sus procesos asociados) para cada caso”. Y, claro, lo que importa no es el coste, sino la relación coste-beneficio, que simplemente no se considera, por principio, en los análisis típicos informáticos.
Personalización Forzosa: parece que, una vez conseguido el objetivo de modelar todas las situaciones con un esquema básico común, los diseñadores caen en la cuenta de que ese modelo, monstruosamente grande y genérico, no es que no sea reusable: ¡Es que ni siquiera es utilizable! Así que urge reducir el caudal de información hasta que alcance niveles asumibles por las personas (los destinatarios originales del esfuerzo de modelado, que pasaron rápidamente a ser “usuarios elásticos”, y ahora, en el momento de las pruebas, vuelven a ser parcialmente importantes), para lo que se utilizan tres diferentes técnicas de aplicación progresiva: la búsqueda, la suscripción y la re-decoración:
- Búsqueda: se dota al usuario con un potente (?!) motor de búsqueda, de forma que, sin conocer la profundidad o estructura de la información, encuentre lo que necesita, que suele ser muy poco de lo dispuesto.
- Suscripción: se insta a los usuarios a que señalen aquellos temas que les interesen, para mostrárselos. En realidad se trata de una versión remozada de la “búsqueda” anterior, en la que los resultados van hacia el usuario sin que éste tenga que requerirlos en cada ocasión: consiste, en la práctica, en guardar ciertos términos de búsqueda y que el ordenador se encargue de buscarlos y pasar al usuario los resultados instantáneamente o no, en razón de cuando éste quiera recibirlos.
- Re-decoración: como finalmente un usuario puede contar con demasiadas suscripciones, ¿por qué no permitirle elegir entre ellas para que sean mostradas de forma más o menos prominente, en sitios también determinados por su futuro lector? Así que se provee al usuario con herramientas de disposición de elementos visuales: puede añadir y quitar cajitas o ítems, y situarlas en diferentes partes de la pantalla.
De estos dos enfoques se desprende que, en la informática común, la que le aplican a uno, las particularidades de comportamiento en análisis se consideran anomalías a integrar (de forma muy parecida a como se consideraban la homosexualidad o la capacidad intelectual de la mujer en el pasado cercano), por lo que se busca una opción global que contemple todas las opciones que se han querido/podido contemplar. Así que se diseña para asimilar las excepciones, lo que precisamente impide que se den diseños excepcionales.
El Diseño de Interacción (ID) intenta establecer primero los comportamientos para luego, más adelante, decidir si se requieren procesos e interfaces diferentes para cada uno de ellos… ¡o no! Pero, como ocurre con tantos otros métodos y con la mayoría de las instrucciones de los electrodomésticos que nos favorecen… ¡No los leemos ni seguimos!
¿Debería tratarse de forma diferente a aquél que no sabe lo que quiere que a aquel otro que lo sabe exactamente? ¿Deberían los ayuntamientos incluir secciones especiales para niños (tipo “Imaginarium”) en sus sitios Web, y no sólo “información para niños” (que sería el equivalente de la “puerta para adultos”? ¿Deberían las instituciones ajustar las normas de accesibilidad AA para cumplir los objetivos de los niños (jugar) en vez de facilitar el acceso a una información que, a ellos, no les suele interesar (aunque tal vez sí a sus padres)? ¿Se manejan, en el ámbito de ejercicio de su profesión, los periodistas o documentalistas en un sitio Web como el resto de los mortales, y tal vez necesiten puertas periodísticas especiales? ¿Es la generalización –primero, y la especialización forzosa después– el único camino? Sí, sí, sí, no y… ¡claro que no!
Hablaremos (y yo escribiré) en el futuro sobre el Exception-aware Design (ED), y lo calificaremos (ya verán ustedes) de Diseño Excepcional . Al tiempo 
