Grancomo

Aunque me persiguen, no soy fan de los proyectos corporativos: intranets, plataformas, sistemas de aplicaciones, sistemas de información y apoyo a la decisión… Independientemente del contenido de negocio de las aplicaciones, sea dinero, inmuebles, matrículas, billetes de avión, pólizas o lechugas, el planteamiento de los proyectos en grandes corporaciones hace que todo al final se reduzca a combinaciones y anidamientos de altas, bajas, consultas y ediciones de forma repetitiva. Los profesionales trabajan desconectados, en cajas negras sin apenas una visión de sistema. Un camino hacia el embrutecimiento y la pérdida de sensibilidad. Tanto que acabas por guardar los proyectos en tu anti-curriculum.

Hacer prototipos y tener un Libro de Estilo no significa para nada que se esté haciendo Diseño Centrado en el Usuario. Una organización tecnocéntrica que no ha incorporado a los usuarios en sus procesos como elemento crítico para el éxito suele presentar síntomas como estos:

1. Se arranca de decisiones limitantes en tecnología. Por ejemplo, un CMS costoso de customizar que genera código no estándar. Una plataforma que una vez desplegada no permite iteraciones ni mejoras en tiempo y costes razonables.
2. Se trabaja en un contexto de enfrentamiento. Usuarios de negocio presionando hacia la productividad desconocedores -por mucho que digan- de las necesidades del usuario final vs. Desarrollo, con requerimientos incompletos y sometidos a plazos de desarrollo suicidas.
3. Trabajas en un oximoron: “tecnología web”. Error. No todo aquello que sale por un navegador es web. La web es abierta, estándar, compatible, social. En entornos corporativos hablamos de plataformas cerradas, propietarias, incompatibles, paranoicas.
4. Suele pensarse en los usuarios como si fueran microchips. Las personas son diminutos componentes de un gran sistema que trabajan de manera procedimentalizada y homogénea.
5. El entorno está compuesto por personal interno y de consultoras con diferentes backgrounds asignados a departamentos con intereses en conflicto.
6. Obsesión por la centralización, a costa de ahogar a áreas de negocio que ya tienen cubiertas sus necesidades.
7. Trabajas para directivos, en comités con un discurso tecnológico a partir de necesidades figuradas. Muy lejos del usuario final. Lo importante es ir salvando reuniones con la Alta Dirección, después se piensa en el usuario.
8. Procesos en cascada y “metagestión”, (gestores de gestores). Tantos que puedes terminar en una reunión con 10 personas que están en tu proyecto, de las que no habias visto en tu vida a 6.
9. Acceso vetado a las fuentes de información relevantes como usuarios finales o equipos de negocio. El propio equipo “sabe perfectamente” lo que necesitan los usuarios.
10. Las integraciones de procesos de negocio suelen reflejarse en el interfaz a través de tareas manuales.
11. Creyendo forzar la productividad se contemplan casos de uso extremos que derivan en aplicaciones recargadas e inusables. Se olvida la regla del 80/20: con el 20% de la funcionalidad, se atiende al 80% de los usuarios.
12. Se confunden usabilidad y apariencia. Todo aquello que aplique logotipos y colores corporativos ya es “usable”.
13. Se confunde diseño gráfico con poblar de iconos y gráficos una pantalla.
14. Se confunde usabilidad con estandarización. Tienes que explicar cada día, que aquello que llaman “usabilidad” no es más que mera “estandarización” o aplicar burocráticamente los estándares recogidos en un Libro de Estilo para pasar los controles de calidad finales.
15. Los proyectos generan documentación voluminosa y costosa de elaborar que aporta poco al proyecto, quedará desfasada y no será leída jamás.
16. Improvisación. Una vez se da el pistoletazo de salida de la programación las implementaciones a cargo de equipos de tecnología desconectados y bajo presión sin soporte de Experiencia de Usuario suele perjudicar la calidad final del producto.

En este entorno, son más útiles las habilidades políticas que las técnicas. Esto hace difícil que haya proyectos de calidad. Y es que no importa el sector (energía, banca, telecomunicaciones…). Pasan los años, apenas se ha evolucionado en estos aspectos. No se piensa que una aplicación corporativa es un componente de soporte a un servicio. Será usada en un contexto por un empleado que puede compartir espacio con uno o varios clientes.

El diseño tanto por su capacidad de generar uso como a nivel estético, ha cobrado más visibilidad. Se pueden hacer interfaces usables y estéticos. La web está llena de ejemplos. En estos años, muchos de los sponsors de proyecto han comenzado a navegar, a ser usuarios y se está notando: hay cosas que ya no hay que explicar, y se van poniendo remedios:

1. La implantación de equipos de Experiencia de Usuario profesionales cerca de altos niveles de decisión con conocimiento, visión de negocio, medios y presupuesto que aplican una visión de diseño estratégica. Para esto, es necesario lograr muchos casos de éxito convincentes con sus cifras y venderlos internamente. Por otro lado, la visión multidisciplinar de un Equipo de Experiencia de usuario, conlleva beneficios cualitativos, ya que puede impulsar la innovación detectando necesidades de los usuarios no cubiertas y ayudar a definir nuevos productos y servicios.
2. Huida de la zona militarizada: los equipos de negocio identifican proyectos que se puedan ejecutar al margen de áreas de tecnología, sin estar sometidos a sus plazos, costes, procesos administrativos y la pobre calidad de los resultados (a veces, el desvío entre lo diseñado y lo finalmente entregado es sobrecogedor). En este caso, para no perder a su cliente interno, los equipos de tecnología tendrían dos opciones: montar su servicio de Experiencia de Usuario con los cambios en la forma de trabajar que conlleva, o bien olvidarse de todo aquello que tenga que ver con usuarios para concentrarse en el nucleo tecnológico.
3. Desarrollo ágil: una vez montada la estructura tecnológica básica sobre la que trabajar, se trocean proyectos en hitos viables con entregas claras y definidas en las que el usuario final es parte del equipo de proyecto.

Los profesionales de la Experiencia de Usuario, se van incorporando a esferas de decisión. Con ello acceden a una visión estratégica de conjunto y se les dota de capacidad de ejecución rompiendo con el “pantalla-centrismo” más allá de la burocracia de los Libros de Estilo o Manuales de Usabilidad.

Cuando llegas al sitio de Whitey Flagg, artista nacido en Tacoma, Washington, no entiendes nada. Acostumbrado a racionalizar interfaces, no sabes si estás en un sitio web, un experimento o un juego.

El interfaz representa el mapa de metro de Manhattan creado con ASCII. No hay más. La ilustración, hecha a base de HTML, es un catálogo con acceso a las obras “analógicas” de Flagg, que reflejan en lienzo y acrílico los rastros de la actividad humana. Y este es todo el sitio web.

Obra: “The Grand Inquisitor”

La información emprende el viaje de vuelta: lo digital se vuelve analógico.

Enlace

San Francisco. Aquel 13 de septiembre del 94, padre e hijo se subieron a un estrado. Este contaba con apenas diez años. Iba a dar su primera conferencia sobre diseño de interacción. Eran Jef y Aza Raskin. Jef fue uno de los pioneros en la interacción hombre-máquina y el diseño de Interfaces Gráficas de Usuario. Entre otras cosas inventó el ” click and drag”. Es 1984, en pleno apogeo del Gran Hermano IBM y sus hombres grises, la vida de Jef cambiaba con la llegada al mundo de dos hermanitos: Aza y el Macintosh, nacidos para plantarle cara a las conformistas interfaces de usuario del momento.

Jef abandona Apple y Aza y Macintosh toman caminos diferentes…

Cuando fallece Jef Raskin en el 2005 y pese haber dejado como herencia el rompedor Macinthosh no parecía muy convencido de las bondades de la GUI. Da la impresión de que tras su marcha de Apple, se hubiera dedicado a luchar contra sí mismo. Tras su marcha deja la Canon Cat, su libro The Humane Interface o Archy, una propuesta de interfaz accesible que salva las limitaciones de las GUI, y a Aza, convertido en su heredero que continua la labor de su padre, entre ellas la evolución de Archy, fundando una pequeña compañía, Humanized dedicada a volar por los aires los caducos patrones de interacción entre personas y máquinas.

Hoy, Aza aún es insultantemente joven y presume de ello. Se refiere frecuentemente a su padre como Jef y hace propios sus postulados, siempre cuestionando la tecnología a favor de un usuario que ha vivido décadas sintiéndose culpable por cada error cometido.

Sus esfuerzos se centran en el dominio de las aplicaciones y sus intersecciones. Esas zonas grises que te obligan a cambiar y ejecutar toda una aplicación para realizar una tarea auxiliar. Para hacer esa transición, aplica la interfaz de lenguaje de comandos “humanizada” de la que la primera prueba es Enso.

Charla sobre Enso en Google.

Tecnología para ese 90% que odia los ordenadores

Libros, blogs, videos… Las premisas en las que los Raskin basan su trabajo se encuentran dispersas en varias fuentes.

• Contenido: Las interfaces existen para manipular el contenido. Punto. Jef adaptó la Primera Ley de la Robótica de Asimov al diseño de interfaz: “Ningún sistema dañará tu contenido, o a través de la inacción, permitir que tu contenido sea dañado”. En este punto aún queda…
• Ok-Cancel: Un producto no debe interrumpir el flujo del usuario sino acompañarle de forma transparente y no intrusiva (semejante a Growl para Mac). Si el usuario se arrepiente, tendrá la oportunidad de deshacer. Lo habrás visto en GMail.
• Presunción de inocencia del usuario: Entre error del usuario o del sistema, el usuario es inocente. Si como usuario tienes un problema con un interfaz “no es tu culpa”, sino del producto y sus diseñadores. Aún estamos a años luz de esto.
• La interfaz de línea de comandos (CLI) es parte del futuro: la línea de comandos es brillante si hablas su idioma, que se lo digan a los usuarios de UNIX. Para el resto, hayq eu conseguir que la Línea de comandos hable el idioma del usuario. Nuevos contextos y vigilando que sea Eficiente, Expresiva y Fácil de Aprender (A Unix le faltaba este último). Como ejemplo: Enso o Ubiquity para Firefox creados desde Humanized.
• La tecnología es para todos: que “madres y sus hijos adolescentes no programadores” puedan crear sus propios servicios y mashups. ¿Es imposible?
• Los toolkits de diseño de interfaz estancan la innovación: El conformismo no es una opción. No se puede ser mejor si no se es diferente. Los tookits actuales de desarrollo de interfaz aceleran la construcción de productos pero estancan la innovación y perpetúan las malas decisiones de diseño. Y aquí chocan de frente “retro-usabilidad” e innovación.

Songza, interfaz sencillo por fuera, complejo por entro

Songza un jukebox de música online, es un ejemplo de todo lo visto antes. Es un escaparate de cómo puede humanizarse un interfaz web. Sencillez, originalidad, viralidad, prescinde de elementos clásicos: menos iconos, más palabras; el cambio de menús en cascada por “pie menús”; mucho contenido, escasa interacción; deshacer en vez de ventanas de advertencias; mensajes transparentes.

Imagen Crunchbase

El impuesto de esta aparente sencillez es más código: los componentes no estándar han tenido que desarrollarse artesanalmente.

Mozilla, Humanized y Ubiquity

Hace un tiempo Humanized se unió a Mozilla. Los resultados comienzan a aflorar: cambios en navegación por pestañas de Firefox, experimentos para dispositivos móviles y Ubiquity, una “extensión-extensible” de Firefox que traslada al navegador la funcionalidad de Enso, pensada inicialmente para Windows. Ya se están creando comandos basados en Ubiquity.

Pensar en Windows no fue una opción acertada: la “innovación” cautiva en un producto conformista para usuarios conformistas no ofrecía mucho recorrido. Mozilla es otro planeta: independiente de sistemas operativos y abierta. Es de esperar que las ideas de Aza y su equipo transformenla navegación por la web.

Ubiquity for Firefox from Aza Raskin on Vimeo

Aza escribe frecuentemente en su blog Aza’s Thoughts.

La aparición de Google Chrome y la nueva extensibilidad de Firefox prometen tiempos “interesantes”.