Traducción Libre del Capítulo 4 del libro de Alan Cooper, The Inmates are Running the Asylum. Why High-tech Products Drive Us Crazy And How to Restore the Sanity.
Jacinto Dávila
Aún cuando los sobrevivientes sepan que un producto de software los hace sentir estúpidos no podrán decirlo sin parecer que se están quejando, porque están rodeados por conformistas. A nadie le gusta quejarse, así que los sobrevivientes sienten una enorme presión social para unirse a los conformistas, excusarse y culparse a sí mismos por su mal rendimiento al usar un software. Pero los instintos de los sobrevivientes son mucho mejores que sus esfuerzos “conscientes” para sobre-compensar sus supuestas debilidades. El Software los hace sentir estúpidos y no tiene que ser así. Si Ud es una de esas personas, podría estar preguntándose “¿A qué se refiere con SOFTWARE MALO?. El que tenemos resuelve el problema ¿verdad?”. En este capítulo, explicaré a qué me refiero con malo.
Lo más triste del osoware danzante es que la mayoría de la gente está muy contenta con la horrible bestia. Sólo cuando ven un verdadero bailarín, comienzan a sospechar que hay un mundo más allá del meneo ursino. Tan pocos productos de software han alcanzado verdaderas habilidades de servicio al usuario, que la mayoría de las personas ignoran completamente que las cosas podrían ser mejor. Mucho mejor. La mayoría de las personas que usan hojas de cálculo y procesadores de palabras en los modernos PC imaginan que todos los problemas que un computador puede resolver, ya han sido resueltos satisfactoriamente, cuando no perfectamente. Pero esto está muy lejos de ser cierto. Una infinidad de proyectos de gestión de información siguen sin solución y, en muchos casos, ni siquiera han sido planteados.
Como consumidores de productos con software, estamos tan acostumbrados a aceptar lo que nos dan que no podemos ver lo que fácilmente podría ser nuestro. Los ingenieros crean productos que cumplen con sus tareas pero, a falta de buenos diseños, esas tareas todavía no alcanzan las metas de los usuarios.
Yo he tenido varios grabadores de video, VCR, en los últimos 20 años. Todos ellos tienen facilidades para programar la grabación automática de películas o programas de televisión, pero ninguna de esas máquinas – inclusive el modelo top-of-the-line de $1500 -- me garantiza que tendré éxito con la grabación. La interfaz que me presente el producto es tan difícil de controlar, difícil de leer, con un extraño lenguaje de configuración y repleta de tantos switches ocultos o disimulados que mi tasa de éxito ha sido, consistentemente, de un 40%. Mas de las mitad de las veces, consigo que he grabado 3 horas de fútbol, en lugar del programa especial que quería. Luego de años de intentos, simplemente me he declarado incompetente y ni siquiera trato de grabar nuevos programas. Lo mismo han hecho todos en mi casa y mis amigos. Somos todos sobrevivientes de osoware danzante.
Muy frustrado, voy a las tiendas electrónicas de mi localidad, con la tarjeta Visa ardiendo en mi bolsillo. “Aquí están mil!.. Dos mil! dólares”, les grito, “se los daré a quien me traiga un VCR que pueda usar para grabar mis shows de televisión”. El equipo de vendedores perfectamente trajeados me rodean y comienzan a mostrar sus corotos (sus wares). Desde el VCR de oferta hasta el más costoso, no hay ninguna diferencia en la forma de interacción con el usuario. Desde luego, hay un continuo de características disponibles, pero la manera con la que, de hecho, controlo el dispositivo es la misma para todos. En otras palabras, luego de 20 años de maduración de productos, no estoy ni un poco más cerca de poder usar el producto. Este es osoware danzante en su mejor expresión.
Cuando le explico esto a uno vendedor, defiende el dispositivo diciendo que esto es todo lo bueno que puede ser y me muestra el tríptico que dice “FACIL DE USAR” que viene con el dispositivo.
Bill Gates dijo en una ocasión, con un tono cínico inusual, que la forma de hacer que un software sea amigable al usuario es proveerse de un sello y estampar cada caja con la etiqueta “USER FRIENDLY”. (Quizás) sin proponérselo, su método se ha convertido en el método REAL de la industria del software.
Los botones no son buenos para registrar valores continuos como los del tiempo. Una válvula, dial o palanca rotativa son mucho mejores. Si el VCR tuviera uno de esos diales rotativos, como mi reloj de alarma de 11 dólares, yo podría fijar la hora y olvidarme del odioso “12:00” que titila intermitente todo el tiempo. Si el dispositivo tuviera un segundo dial para fijar la hora futura del programa a grabar, podría arreglármelas fácilmente. Tal como está, con la intención de ofrecer la capacidad de grabar 10 programas, el dispositivo es inútil para grabar uno sólo.
Productos que son osowares (oso-corotos) bailarines nos rodean. Tienen suficientes características para cubrir sus cajas con referencias y explicaciones. Tienen suficientes opciones para llenar con “Yes” cada celda de matriz que hacen los revisores de las revistas promocionales. Pero no logran que el usuario sea más feliz o más efectivo. La mayoría de los usuarios no puede usar esas características y opciones. Quienes pueden son los conformistas que servilmente cambian sus hábitos de trabajo para acomodarse a las idiosincrasias del software. Se entusiasman más con el desafío y con la oportunidad de jugar con el nuevo dispositivo. Con mucho esfuerzo aprenden cómo controlar nuevas características que nunca usarán.
Mientras los vendedores libran batallas en los mercados de software, los usuarios se esconden en sus cubículos, temerosos de aventurarse en la tierra de nadie. Los vendedores de correo electrónico, por ejemplo, agregan característica tras característica a sus listas de chequeo y, sin embargo, siguen sin atender las necesidades fundamentales de la comunicación electrónica.
Quienes comienzan a usar el correo electrónico lo hacen cautivados por la novedosa habilidad de poder comunicarse en forma simple, directa y asincróna con cualquiera. Pero lograr esas tareas simples no necesariamente atiende las metas del usuario y, por esto, el correo electrónico permanece en ese estado primitivo de desarrollo. El problema está en una confusión acerca de para qué realmente es el correo electrónico. Hace veinte años, recibir un mensaje era todo un evento. Puesto que el medio dictaba que el recibir el mensaje era importante, el mensaje en sí no tenía nada de especial. De hecho, era normalmente, un texto simple con caracteres ASCII y sin símbolos, ni conexiones extrañas.
Hoy en día, recibimos una enorme mezcla de mensajes importantes y mensajes inútiles. Cualquiera que use el email descubre rápidamente que es un medio extraordinariamente poderoso y útil, y su uso de la herramienta se incrementa rápidamente también, hasta el punto en que buena parte de su vida y de sus negocios pronto se organiza sobre el correo electrónico. Muchos usuarios de correo reciben docenas y hasta cientos de mensajes de correo cada día. La mayor parte de esas comunicaciones son enviadas, bien en respuesta a un mensaje previo ó, bien, esperando una primer respuesta.
Esas secuencias de mensajes, conocidas como Threads, Hebras o Hilos, van y vienen entre dos o más personas. En mi computador, la tasa de mensajes “hebrados” vs solitarios es de 50 a 1. Y, sin embargo, ninguno de los programas de email disponibles hoy trata los mensajes de correo como parte de una secuencia1. Actúan como si los hebras o no existieran o fuesen un atributo insignificante de algunos pocos correos.
Es fácil entender que ver una hebra, en lugar de un mensaje aislado dentro de la hebra, le permite al usuario apreciar las conexiones y el flujo entre los distintos mensajes y cómo es que forman una conversación coherente. Cuando se les considera desde el punto de vista de una tarea o característica particular, todo lo que Ud. puede ver es que necesita o bien enviar o responder.
No es exactamente un reto difícil programar uno de esos sistemas para que gestione el correo como una serie de conversaciones hiladas. Lo que pasa es que nunca se le ha hecho de esa manera, los programadores son reacios a innovar en beneficio del usuario y los gerentes tienen miedo de forzar a los programadores por ese camino que no ha sido probado.
Puesto que los programadores ven el software desde el punto de vista de la implementación, sólo ven que los mensajes fluyen de ida y de vuelta y que los usuarios puede colocar los mensajes en carpetas, así que no ven ningún problema. Luego de que logran que el oso se mueva, declaran que está bailando y cancelan cualquier construcción adicional.
El correo electrónico es apenas un ejemplo de los productos de software que no alcanzan la muy simple y obvia meta que deberían. Estamos tan impresionados con los ositos bailarines que no podemos apreciar las carencias de esos productos. Aquí vamos con otros ejemplos:
En la oficina de un abogado, una agencia de publicidad, una oficina de un contado o en cualquier otro negocio de consultoría, hay una enorme y aún insatisfecha necesidad de programas que gestionen la asignación de gente a proyectos en el tiempo. Esta estructura de tres partes es común a todos los negocios de consultaría. Sin embargo, increíblemente, no existe un buen programa que proporcione el servicio.
Desde el punto de vista del programador, la gerencia de proyectos es una asunto de programación de tareas, con la posible variante adicional de un poco de análisis de camino crítico, en el que el comienzo de una tarea depende de que se complete una tarea anterior. Todos los programas para gestión de proyectos que existen en la actualidad, están basado en esta suposición puramente académica2. El problema es que esta visión tiene muy poco que ver con la realidad.
Una suposición fundamental de los programas de gestión de proyectos – que la gente necesita ayuda para entender como ejecutar sus proyectos – es muy mala. La mayoría de la gente es muy buena para cumplir con sus proyectos; después de todo, es su trabajo. Lo que realmente necesitan es ayuda para acomodar muchos proyectos en un mismo calendario (dovetailing). Los recurso – generalmente gente – sirven a múltiples proyectos simultáneamente. Comienzan y terminan proyectos en una secuencia constante, muchas veces superpuesta, mientras otros proyectos aguardan por su oportunidad de usar el recurso. No es suficiente asignar gente a proyectos en un cierto momento. Tienen que ser asignados a muchos proyectos al mismo tiempo.
Para que sean útiles, los programas que manejan recursos deben integrar las tres dimensiones del problema: tiempo, proyectos y recursos. En lugar de eso, nos llegan programas que sólo manejan dos dimensiones – tiempo y recursos -- y sus vendedores insisten que esto es todo lo que realmente necesitamos. Llamado de varias formas, “tráfico”, “gestión de proyectos” o “asignación de recurso” este segmento de aplicación crítica simplemente no existe.
Más aún, los proyectos están constantemente cambiando respecto al plan. Cualquier programa realmente útil debe dejarse llevar y adaptarse a los cambios en la medida que surgen. Un sistema de gestión de proyectos que no incorpora mecanismos robustos y útiles de feedback – de forma que la gente de hecho hace el trabajo pueda decirle al sistema la verdad acerca de lo que está ocurriendo ahora – no es muy útil para la gerencia del mundo real.
Prácticamente todo el mundo usa un calendario para planificar sus negocios. Muchos programas de calendario se ofrecen en venta, a pesar de que todos ignoran la forma más simple y obvia en la que la gente quiere usar el calendario. Para ponerlo simple, un calendario o almanaque deben reflejar el cómo la gente usa el tiempo para llevar sus vidas. En general, podemos dividir nuestro asuntos con el tiempo en dos tipos: fechas límites y procesos andando. Una fecha límite, deadline, es un instante de tiempo para el cual algo tiene que estar listo, tal como un hito de un proyecto. Un ejemplo de un proceso andando es un viaje de negocio de un día para otro. Mientras estoy en Chicago durante 2 días, por ejemplo, tengo 3 reuniones con varios clientes.
Los programas de calendario modernos ignoran las fechas límites y los procesos y, por el contrario, se basan en la definición de citas. Una cita es una reunión particular que comienza a cierta hora. Las citas son parte importante de la gestión del tiempo, pero no son, de ninguna manera, la única.
No sólo se ignoran otro tipo de conceptos. Además, las mismas citas se representan mal. Registrar la hora de inicio de una cita es mucho más importante que registrar el final. Sin embargo, los programas de ese tipo no distinguen entre ambas. En los últimos 30 años, he iniciado y asistido a cientos de reuniones. El momento de inicio es extremadamente importante. Pero para la mayoría de las reuniones, el momento de terminación no importa, no es necesario, no se especifica o no se sabe por adelantado.
No obstante, todos los programas de calendario que yo he visto, requieren que las citas se definan con una hora de culminación que debe ser especificada por adelantado y con la misma precisión y diligencia que la de inicio. Ese valor, hora de terminación, es usado luego en cálculos preciso de disponibilidad que NO pueden estar correctos y que son una distorsión de la realidad. Por ejemplo, si – usando un programa de esos – Ud me invita a una reunión a las 3:00pm, el programa va ha rechazar su invitación si yo tengo ya una reunión de 35-minutos programada a las 2:30pm. En el mundo real, yo podría fácilmente escaparme de la primera reunión unos cinco minutos antes, sin consecuencias serias.
Además, ninguno de esos programas considera el tiempo que me toma llegar a la reunión. Si tengo que cruzar la ciudad para estar en un sitio a las 2:00pm, tengo que salir a la 1:30pm. ¿Debo colocar la cita a la 1:30 o a las 2:00?. Un programa bien diseñado debería resolver esto y ayudarme a salir a tiempo.
Hay unos cuantos otros asuntos relacionados con el tiempo que no son tomados en cuenta en esos programas de gestión del tiempo. Un día cualquiera, tengo una docena o más de proyectos andando, pero, de hecho, sólo puedo trabajar en uno a la vez. El programa de gestión típico, se reusa a admitir esta conducta normal y no me va a permitir actualizar un item de un proyecto fácilmente. No puedo escapar al osote danzante.
La World Wide Web, la Web, ha abierto el extraordinario caudal de recursos de la Internet a cualquiera que tenga un computador y un modem. La Web es una gran herramienta y ofrece un valor fantástico. Para sorpresa, el cambio más importante que ha traído la Web es una demostración clara de cuan fácil puede ser usar el software. Muchos conformistas de antaño encuentran la Web tan fácil de usar que demandan que todo el software sea así de fácil. En particular, les encanta que los navegadores no los hacen pasar por un incómodo proceso de instalación.
Los ejecutivos del software, particularmente quienes venden en grande, están montándose ansiosamente en ese bus. Ellos también se enamoran del software basado en navegador porque pueden acomodar sus productos sin castigar al usuario con un odioso proceso de instalación. Antes de la Web, todos los productos necesitaban un complejo proceso de instalación. Los productos que corren en un navegador, un browser, no lo necesitan. Este parece ser – para muchos ejecutivos del software – un salto tecnológico que supera la invención del cierre.
Pero esto es una farsa!. No hay razón para que un programa que sea Web – no importan sus otros detalles técnicos – no pueda tener un proceso de instalación completamente invisible. Si tu computado requería instalación de software, lo seguirá haciendo con o sin el navegador. La única razón por la que los programas no-navegadores requieren esa compleja instalación es por la forma en que los programadores han hecho siempre las cosas. Ese montón de preguntas en el instalador hacen el que el trabajo de programación sea más fácil. Los primeros navegadores no tenían forma de hacer esas preguntas, así que sus programadores simplemente se encogieron de hombros y no las hicieron. Si hace falta más prueba, noten que los programadores jamás se quejaron por no haber hecho esas preguntas, mientras que para muchos usuarios esto hizo de la Web la plataforma más fácil que han usado.
Aparte de lo de la instalación, sin embargo, los navegadores son unos gaticos debiluchos. Su idioma de interacción es prehistórico. Su estructura técnica es una broma primitiva. Son tan flexibles como una roca. Cualquier programa que corra dentro de un navegador debe sacrificar una gran cantidad de poder y capacidad. Me molesta que los gerentes de software estén ansiosos por arrancarles la cabeza a sus aplicaciones y montarlas sobre la Web, sólo para obtener la ventaja de la no instalación, cuando podrían obtener el mismo producto sin-instalación simplemente diciendo a sus programadores “Desháganse del proceso de instalación, por favor.”
Los usuarios exigen software basado en navegadores
porque no saben de nada mejor.
Los que desarrollan software, sin
embargo, les siguen la corriente por la razón equivocada. La
Web está organizada como la antigua Unión Soviética,
con computadores centrales que dictan las acciones de las sumisas
máquinas de escritorio. Los programadores, especialmente
aquellos en los departamentos de Informática, poseen los
computadores centrales así que, como los comisarios
soviéticos, se benefician al hacer las cosas de esta manera.
En lugar de obtener los beneficios de la no-instalación en
forma gratuita, los usuarios están pagando un alto costo con
la pérdida de su control sobre su infraestructura de
información.
Buena parte de mi primer libro estuvo dedicada a responder esta pregunta en detalle. Sin embargo, me gustaría dedicar algunas páginas a proveerles con una vista rápida de algunos principios de diseño de interacción que son efectivos al diseñar mejor productos basados en software.
Cada vez que Ud usa un programa, aprende un poco más acerca de él, pero el programa no recuerda nada. Troy Daniels es nuestro productor de medios. Prácticamente vive en el Adobe Photoshop. Sin embargo, cada vez que abre el Photoshop, el programa ha olvidado todo lo que Daniels ha hecho antes con él. No recuerda donde guarda sus archivos de imágenes, ni recuerda las típicas cosas que ha hecho con ellas. Los controles y las funciones que Daniels usa constantemente reciben el mismo énfasis en la interfaz que aquellos que él nunca ha usado y probablemente nunca usará.
La mayoría de los programas no es que trabajen mucho para el usuario. Esto no quiere decir que no trabajen duro, sino que, a veces, gastan una enorme cantidad de esfuerzo para complacer a los usuarios tratándolos como los programadores quieren que se les trate (a los programadores). Es como regalarle a su esposa un taladro para su cumpleaños. Sólo porque a Ud le guste el taladro no significa que a ella le guste. Si tan sólo pudiéramos lograr que los programadores lanzaran todo su esfuerzo tras lo que los usuarios realmente desean, podríamos hacer al usuario más feliz sin sobrecargar más a los programadores.
De la misma forma que el cajero automático se reusa a darme el saldo de mi propia cuenta, la mayoría de los productos interactivos son muy “pichirres” con la información. Además, tienden a camuflar el proceso – lo que está ocurriendo en su interior – y la información relevante a ese proceso. El usuario típico de un sistema interactivo no puede decir cual es el estado del sistema hasta que estalla con un mensaje que anuncia la falla total. Por ejemplo, mi nuevo el radio-reloj, del que hablaba en un capítulo anterior me engaña al no dejarme saber que está haciendo. El sistema parece estar trabajando bien pero no es cierto y no hay manera de saber.
Si alguna vez se encuentra a sí mismo con una libretica de papel tomando notas marginales mientras trabaja con un programa, sepa que es Ud víctima de un programa pichirre con la información. Sería más fácil para un programa colocar más información en la pantalla, pero pocos programadores piensan en esto con cuidado. Por ejemplo, cuando mi cliente de correo recibe un mensaje, muestra un pequeño icono con un sobre. El mismo iconito se vuelve visible cuando recibo un mensaje y cuando recibo cientos. No me da ninguna pista sobre el peso de mi buzón digital. Esa parsimonia no me deja ver el bosque, sólo un árbol.
Cuando la gente puede ver el bosque más allá de los árboles, ajustan sus acciones apropiadamente. Pero el software raramente es así de flexible. Cuando una persona ve que la pila de planillas en su buzón ha crecido a más de 15 cm, sabe muy bien que debe hacer algo drástico para evitar que lo desborden. Por la forma en que están escritos, la mayoría de los programas sólo ve la planilla al tope de la pila – nunca debajo. Si, hablando metafóricamente, el buzón del programa tiene una pila de 15 cm o de 15 metros pendiente, el programa se sigue comportando como si fuese una sola cosa pendiente. El opuesto también es cierto. Si un humano tiene una sola cosa pendiente, puede que use parte de su tiempo para ayudar a un amigo con mas cosas. El computador nunca haría eso.
Cuando un proceso humano es automatizado, los programadores (o los analistas) estudian la conducta normal de los usuarios al realizar el trabajo manualmente y les “extraen” las tareas y las funciones. Esas tareas son luego programadas en el computador. Típicamente, todo lo que no es una tarea en el trabajo simplemente se pierde.
En un sistema humano, la persona a cargo puede tomar la planilla de su cuñado, que están debajo de todas las demás y procesarla de inmediato. Asimismo, el molesto arrogante que nos trató tan mal consigue que su planilla vaya directo al fondo de la pila. Esta flexibilidad en el sistema es crucial para mantener el orden social. En muchos sistemas computarizados, una racionalidad inhumana se impone solo para desgastarse en la fábrica de la civilización.
Los humanos prefieren sistemas que le permiten ajustar un poco las cosas. Quieren sacudir solo un poco la máquina de juegos – no tanto como para trampear el juego, pero suficiente para sesgar positivamente el resultado. Esta ajustabilidad es lo que hace que nuestros sistemas manuales trabajen mucho mejor – aunque sea más lentamente – que los automatizados.
Cuando un programa tiene un problema, invariablemente lo vacía en brazos del usuario y, típicamente culpa al usuario por el problema. Si un humano tiene un accidente, normalmente trata de remediarlo. Por ejemplo, si estoy en casa de unos amigos cenando y derramo el vaso de vino de alguien, inmediatamente uso mi pañuelo para evitar que el vino se extienda y consigo un nuevo vaso para esa persona. Puesto que he mostrado preocupación y diligencia, nadie se ofende y el accidente es aceptado como tal.
Hace poco usé el programa de cierto vendedor para acceder al portal de ayuda del propio vendedor. Por alguna razón extraña, el programa no podía conectarse. Sacaba un mensaje diciéndome, incorrecta, inútil y ofensivamente, que yo no estaba conectado a Internet. Tal como si el programa derramara el mi vino, se reusara a limpiarlo y luego me culpara por todo.
Cuando un producto interactivo tiene un pequeño problema, con frecuencia deja todo y colapsa dejando apenas un inútil vaciado de memoria. Cuando colapso suele causar una enorme cantidad de daño colateral. Por ejemplo, un programa de instalación le hace varias preguntas al usuario antes de comenzar a descargar el nuevo programa en el disco duro. En los primeros tiempos, si se le acababa el espacio, se estrellaba. Los programas de instalación modernos no son mucho mejores. Si se les acaba el espacio, puede que saquen un mensaje de error, pero dejarán de funcionar olvidando todos la información que Ud meticulósamente ha tecleado. Si Ud libera algún espacio y lo corre de nuevo, el programa comenzar repitiendo las mismas preguntas, en lugar de recordar lo que ya se le dijo antes.
Las cajas de dialogo para confirmar son uno de los mas ubicuos ejemplos de mal diseño de software – son esas que nos preguntan si estamos seguros de que queremos hacer cierta acción – En los primeros tiempos de la computación, el programa ejecutaba una acción, sin posibilidad de revertirla, en el momento en el que el usuario introducía el comando. Teclear “borrar todo” hacia justo eso, de inmediato y sin “devolución”. Seguro que tan pronto el primer usuario borró todo su disco duro sin notarlo, se quejó con el programador y el este agregó lo que consideró lo que consideró un nivel adecuado de protección. Luego que el usuario dicta el comando de “borrar todo”, pero antes que el computador lo ejecute, el programa muestra una caja de esas de diálogo, pidiéndole al usuario que confirme la instrucción de borrado.
Es todo tan lógico, como tan malo.
Una caja de confirmación es una solución adecuada para el programador porque le absuelve de la responsabilidad de ser el causante de un borrado accidental. Pero esto es confundir el tema. El borrado del disco es responsabilidad del usuario y ya él o ella ha dado el comando. No es momento para que el programa se haga el loco. Debe seguir adelante y hacer lo que se le pide. La responsabilidad que se están escondiendo bajo la mesa es la que tiene el programador de prepararse para “deshacer” sus acciones, aún cuando las solicite el usuario.
En general, los humanos no tomas las decisiones como lo hacen los computadores, y es normal que una persona cambie de opinión o decide retractarse en una decisión previa. En el mundo real, afuera de los computadores, la mayoría de las acciones pueden ser postergadas, cambiadas o revertidas. No hay razón para que esto no sea así en los productos basados en software, salvo que los programadores que los crean no piensan así.
El cajero automático, que expliqué en capítulos anteriores, abdica su responsabilidad con preguntas de confirmación, tal como hace el software de escritorio. Cuando inserto mi tarjeta, el cajero demanda que yo confirme que he insertado la tarjeta. Cuando le pido un retiro, me pide que le confirme que he pedido un retiro. Cuando introduzco un cantidad, me pide que confirme que he introducido la cantidad. ¿Por qué simplemente no confía en mí? ¿Por qué no simplemente hace lo que le pido?.
Esa máquina podría permitirme cancelar la operación en cualquier momento en una forma más simple. Si el cajero tan solo me ofreciera una ENORME botón rojo para CANCELAR, que pudiera yo presionar en cualquier momento, podría suponer que yo soy inteligente y capaz y que sé lo que estoy haciendo, en lugar de suponer que soy un estúpido, incompetente y estoy confundido respecto a lo que quiero.
Estoy seguro que debe haber gente estúpida e incompetente usando los cajeros, pero a nadie – ni siquiera los estúpidos e incompetentes – le gusta que lo traten como estúpido e incompetente. Además, no es que genere lealtad y buenos sentimientos tratar a sus clientes de esa manera.
Arreglar este problema NO es difícil. El programa podría colocar la palabra RETIRO arriba de la pantalla y dejarla allí durante TODA la transacción. Luego podría colocar la cantidad que me cobra por el retiro en la pantalla y dejarla también allí. Luego debería agregar la palabra “VERIFICANDO” junto con mi número de cuenta, el saldo y el límite de retiro, dejándo todo VISIBLE. Luego, cuando llega el momento de la cantidad que quiero retirar, soy un cliente completamente informado, en lugar de la confundida víctima de un interrogatorio. Puedo tomar la decisión crucial: la cantidad, desde una posición de conocimiento de lo que es legal, tengo disponible, está preparado y es apropiado.
Un sistema que se adelanta a mis necesidades de información, tal como el que acabo de describir, es muy típico del cómo funcionan los sistemas solo humanos, pues los humanos tenemos que ver la globalidad. Los computadores, por su parte, sólo deben ver un pequeño pedazo de toda la información para proseguir y así es justamente como se modela esta interacción: supone que la persona parada allí, en pleno sol tropical, pulsando botones mientras sus amigos dan patadas al piso, es otro computador, no un ser humano de sangre caliente con sentimientos.
Muchos novatos en el mundo de la computación imaginan que el software se comporta en la forma que lo hace por alguna buena razón. Por el contrario, su conducta es, con frecuencia, el resultado de algún giro o accidente que se propaga sin que se le piense por años. Con un oportuno diseño de la interacción al crear productos basados en software, podemos cambiar esta conducta a algo más placentero y productivo para los humanos.
Fin del Capítulo
1Algunos programas de correo le permiten al usuario construir y manejar una hebra manualmente, pero el remedio es peor que la enfermedad. Manipular esa opción es difícil y las conversaciones hiladas son tratadas todavía como excepcionales.
2Soy tan culpable como cualquier programador. En 1984, escribí SuperProject de Computer Associates, uno de los primero programas de gestión de proyectos. Ignoraba la interacción entre muchos proyectos, justo como han hecho todos sus sucesores.