(echo echo) echo (echo): Poética de la línea de comandos

Me gustaría un texto que encontré hace tiempo y me pareció precioso. Desgraciadamente la web donde lo leí lleva caída mucho tiempo y sólo he podido rescatarlo dese archive.org. Ojalá lo hubiera escrito yo, pero no 🙂 el autor original es Florian Cramer y está traducido por Kamen Nedev (trad.)  – 2007 – CC-BY-NC-SA (espero que os guste tanto como a mí)

 

Diseño

La mayoría de los argumentos a favor del uso de la línea de comandos frente al uso de la interfaz gráfica de usuario (GUI) están lastrados por un platonismo de administrador de sistemas. Una instrucción como «cp test.txt /mnt/disk» no está, en realidad, ni un milímetro más cerca de una hipotética «verdad» de la máquina que arrastrar un icono del archivo.txt con el ratón al símbolo de un disco duro montado. Y, aunque estuviera más cerca de la «verdad» ¿qué ganaríamos con ello?

La línea de comandos es, de por sí, una interfaz de usuario tan abstraída del kernel del sistema operativo como lo es la GUI. Mientras que el aspecto y usabilidad de «escritorio» de la IGU emula objetos de la vida real de un entorno de oficina analógico, la línea de comandos de Unix, BSD, Linux/GNU y Max OS X emula las máquinas de teletipo que servían como terminales de usuario en los primeros ordenadores Unix de principios de los 70. Este legado sigue vivo en la terminología de la «terminal virtual», y el archivo de dispositivo /dev/tty (de «teletipo») en sistemas operativos compatibles con Unix. Por tanto, tanto el uso de entornos gráficos como el de la línea de comandos son medios; capas de mediación en el bucle de retroalimentación cibernético entre humanos y máquinas, y pruebas de la veracidad de la afirmación de McLuhan de que el contenido de un nuevo medio es siempre un medio antiguo.

Ambas interfaces de usuario fueron diseñadas con objetivos diferentes: en el caso del teletipo de la línea de comandos, el de minimizar el esfuerzo y el gasto de papel, mientras que en el caso de la GUI fue el uso de analogías – en un caso ideal – autoexplicativas. La minimización de escritura y gasto de papel tenía la intención de evitar la redundancia, manteniendo la sintaxis y la respuesta de las instrucciones lo más sucintas y eficaces posibles. Por eso «cp» no se escribe «copy», «/usr/bin» no es «/Unix Special Resources/Binaries», y por eso también el resultado de la instrucción de copiar recibe como respuesta una línea en blanco, y por eso la instrucción puede repetirse simplemente pulsando la flecha hacia arriba y el retorno, o por qué volver a escribir «/mnt/disk» se puede evitar escribiendo simplemente «!$».

A su vez, la GUI reinventa el paradigma de los lenguajes universales de signos pictóricos, ideados por primera vez en las utopías educativas del Renacimiento, desde la Ciudad del Sol de Tommaso Campanella hasta el libro escolar ilustrado «Orbis Pictus» de Jan Amos Comenius. Los objetivos de sus diseños eran similares: «usabilidad», operación autoexplicativa a través de diferentes lenguas y culturas humanas, si es necesario a costa de la complejidad o la eficacia. En la operación de copiar un archivo, el acto de arrastrar es, en sentido estricto, redundante. Al significar nada más que la transferencia de «a» a «b», consigue exactamente lo mismo que el espacio entre las palabras – o, en términos técnicos: los argumentos – «test.txt» y «/mnt/disk», pero requiere una operación táctil mucho más complicada que pulsar la barra de espacio. Esta complicación es intencional, ya que la operación simula el común acto de arrastrar un objeto de la vida real a otro sitio. Pero, aun así, la analogía no es completamente intuitiva: en la vida real, arrastrar un objeto no lo copia. Y, con la evolución de las GUI desde Xerox Parc a través del primer Macintosh hacia paradigmas más contemporáneos de barras de herramientas, múltiples escritorios, integración con el navegador web, uno ya no puede sentar un analfabeto digital delante de una GUI y decirle que piense en ella como si fuera un escritorio de la vida real. Al margen de lo acertado de esta clase de analogías, el uso de la GUI es una técnica cultural tan construida y aprendida como lo es escribir instrucciones.

Por tanto, las categorías platónicas de la verdad no pueden evitarse del todo. Si bien la interfaz de línea de comandos también es una simulación – en concreto, la de una conversación telegráfica – sus expresiones alfanuméricas se traducen mucho más fácilmente en la operación numérica del ordenador, y viceversa. El lenguaje escrito puede usarse mucho más fácilmente para usar los ordenadores para aquello para lo que fueron construidos, para automatizar tareas de formateo: la operación «cp .txt /mnt/disk», que copia no sólo uno, sino todos los archivos de texto de un directorio a un disco montado sólo puede replicarse en una IGU encontrando, seleccionando y copiando a mano todos los archivos de texto, o usando una función de búsqueda o una función de script como una herramienta añadida. La extensión de la instrucción «for file in ; do cp $file $file.bak; done» no puede replicarse en una IGU a no ser que esta función haya sido ya programada en ella. En la línea de comandos, «usar» se extiende naturalmente a «programar».

En una perspectiva más amplia, esto quiere decir que las aplicaciones GUI son, típicamente, simulaciones directas de una herramienta analógica: el procesamiento de textos emula las máquinas de escribir, Photoshop el cuarto oscuro de un laboratorio fotográfico, el software de publicación digital una mesa de maquetación, los editores de vídeo un estudio de vídeo, etc. El software sigue anclado en una escaleta de tareas tradicional. Las herramientas equivalentes en la línea de comados – por ejemplo: sed, grep, awk, sort, wc para el procesamiento de textos, ImageMagick para la manipulación de imágenes, groff, TeX, o XML para la maquetación de documentos, ffmpeg o MLT para el procesamiento de vídeo – transforman el proceso de trabajo tradicional de la misma manera que «cp *.txt» transforma el concepto de copiar un documento. El diseñador Michael Murtaugh, por ejemplo, usa herramientas de línea de comandos para extraer automáticamente imágenes de una colección de archivos de vídeo para generar galerías o composites, un concepto que, sencillamente, excede el paradigma de un editor gráfico de vídeo, con su concepto predeterminado de qué supone la edición de vídeo.

Las implicaciones de esto llegan mucho más lejos de lo que pueda parecer a primera vista. La interfaz de línea de comandos provee funciones, no aplicaciones; métodos, no soluciones, o: nada más que un montón de plug-ins para ser promiscuamente enchufados unos en otros. La aplicación puede construirse, y la solución puede ser inventanda, por los propios usuarios. No es una interfaz empaquetada, o, – tomando prestados los términos de Roland Barthes – una interfaz «legible», sino «escribible». Según la distinción que hace Barthes entre literatura realista frente a literatura experimental, el texto legible se presenta lineal, compuesto suavemente, «como una despensa donde se guardan los significados, apilados, a salvo». 1 En cambio, al reflejar la «pluralidad de puntos de entrada, la apertura de redes, la infinidad de lenguajes» 2, el texto escribible intenta «convertir al lector no en consumidor, sino en productor del texto». 3 Además de la caracterización que hace Umberto Eco de la línea de comandos como una interfaz iconoclásticamente «protestante», y la GUI como idolátricamente «católica», la GUI podría calificarse como Tolstoi, o como Toni Morrison, y la línea de comandos como Gertrude Stein, «Finnegans Wake», o la poesía L.A.N.G.U.A.G.E. de las interfaces informáticas. O, también, el paradigma Lego de un juguete auto-definido frente al paradigma Playmobil de un juguete predefinido.

La ironía está en que el paradigma Lego había sido el objetivo de diseño inicial de Alan Kay para la interfaz gráfica de usuario en Xerox PARC en los años 70. Basado en el lenguaje de programación Smalltalk, y haciendo uso de la programación orientada a objetos, aquella GUI debía permitir a los usuarios conectar sus propias aplicaciones a partir de módulos preexistentes. En sus formas populares en Mac OS, Windows, o KDE/Gnome/XFCE, las GUI nunca cumplieron esa promesa, y en cambio reforzaron la división entre usuarios y desarrolladores. Incluso excepciones marginales del propio sistema de Kay – que sigue vivo en el proyecto «Squeak», y los entornos de programación multimedia gráficos de Miller Puckette «Max» y «Pure Data» manifiestan la limitación de las GUI para operar también como interfaces de programación gráfica, ya que ambos siguen requiriendo programación textual a nivel de la sintaxis base. En términos de programación, la GUI refuerza la separación entre la UI (la interfaz de usuario), y la API (la interfaz de programación de aplicaciones), mientras que en la línea de comandos, la propia UI es la API. Alan Kay reconoce que «no sería sorprendente que el sistema visual fuese menos capaz en este área [el de la programación] que el mecanismo que resuelve oraciones sustantivas en el lenguaje natural. Aunque no sería justo decir que los ‘lenguajes basados en iconos no funcionan’ sólo porque nadie haya sido capaz de diseñar uno bueno, es probable que la explicación anterior esté cerca de la verdad». 4

 

Mutant

 CORE CORE bash bash CORE bash

 There are %d possibilities.  Do you really  
 wish to see them all? (y or n)

 SECONDS  
 SECONDS

 grep hurt mm grep terr mm grep these mm grep eyes grep eyes mm grep hands  
 mm grep terr mm > zz grep hurt mm >> zz grep nobody mm >> zz grep  
 important mm >> zz grep terror mm > z grep hurt mm >> zz grep these mm >>  
 zz grep sexy mm >> zz grep eyes mm >> zz grep terror mm > zz grep hurt mm  
 >> zz grep these mm >> zz grep sexy mm >> zz grep eyes mm >> zz grep sexy  
 mm >> zz grep hurt mm >> zz grep eyes mm grep hurt mm grep hands mm grep  
 terr mm > zz grep these mm >> zz grep nobody mm >> zz prof!

 if [ "x`tput kbs`" != "x" ]; then # We can't do this with "dumb" terminal  
 stty erase `tput kbs`

 DYNAMIC LINKER BUG!!!

Codework de Alan Sondheim, enviado a la lista de correo «arc.hive» el 21 de julio de 2002

En una terminal, las instrucciones y los datos pasan a ser intercambiables. En la instrucción «echo date», «date» es el texto, o datos, que tiene que aparecer como resultado de la instrucción «echo». Pero si el resultado se vuelve a enviar al procesador de la línea de comandos (también conocido como shell) – «echo date -sh» – «date» se ejecuta como una instrucción en sí. Esto quiere decir: se pueden construir instrucciones de líneas de comandos que mezclan datos introducidos, texto, en nuevas instrucciones para ejecutarlas. Al contrario que en las GUI, hay recursividad en las interfaces de usuarios: las instrucciones pueden procesarse a sí mismas. Photoshop, en cambio, puede manipular sus propios diálogos gráficos, pero no puede después ejecutar estas mutaciones. Tal y como dice el programador y administrador de sistemas Thomas Scoville en su artículo de 1998 «The Elements of Style: UNIX As Literature», «Las herramientas de sistema de UNIX son como un kit de Lego para escritores. Tubos y filtros conectan una utilidad a la siguiente, y el texto fluye, invisible, entre ellas. Trabajar con una shell, con derivados de awk o lex, o con la herramienta set, es literalmente como bailar con palabras.» 6

En el net.art, «OSS» de jodi es lo más cercano a una hipotética GUI que se devora a sí misma, manipulando con Photoshop sus propios diálogos. El entorno de la línea de comandos de Unix/Linux/GNU es exactamente eso: un procesador de texto gigante en el que cada función – buscar, reemplazar, contar palabras, ordenar líneas – ha sido externalizada a un pequeño programa, cada uno representado por una instrucción de una sola palabra; palabras que pueden procesar palabras tanto como datos [correo electrónico, documentos de texto, páginas web, archivos de configuración, manuales de software, código fuente, por ejemplo] como las palabras en sí. Y, para más «shocks» culturales para la gente que no está acostumbrada a ella: con SSH o Telnet, cada línea de comandos pasa a ser «transparente a la red», esto es, cada instrucción puede ejecutarse tanto localmente como remotamente. «echo date – ssh user@somewhere.org» construye la instrucción en la máquina local, la ejecuta en la máquina remota somewhere.org, pero devuelve el resultado otra vez en la terminal local. Instrucciones y datos no solamente pueden mutar unos en otros, sino que instrucciones y datos en máquinas locales se pueden mezclar con los de máquinas remotas. El hecho de que ARPA – y, más tarde, Internet – fuera diseñado para computación distribuida se hace tangible a nivel microscópico en el espacio entre palabras, de una manera mucho más radical que en paradigmas monolíticos como «subir», o «aplicaciones web».

Con su hibridación de código y datos locales y remotos, la línea de comandos es el sueño húmedo de un poeta electrónico, «codewoker» o net.artista ASCII hecho realidad. Entre las «constricciones» poéticas inventadas por el grupo OULIPO, aquellas que son puramente sintácticas se pueden reproducir fácilmente en la línea de comandos. «POE», un programa diseñado a principios de los 90 por los poetas experimentales austriacos Franz Josef Czernin y Ferdinand Schmatz para asistir a los poetas con el análisis y construcción lingüísticos, acabó siendo, sin ninguna intención, una herramienta de texto Unix para DOS. En 1997, el poeta underground norteamericano ficus strangulensis hizo un llamamiento para la creación de un «sintetizador de texto», que es lo que la línea de comandos Unix realmente es. Por tanto, la «netwurker» mez breeze apunta, como principales influencias culturales en su trabajo net.poético «mezangelle» a «#unix [shelled + otherwise]», junto a «#LaTeX [+ LaTeX2e]», «#perl», «#python» and «#el concepto de ARGS [con un potencial todavía por realizar]». 7 En la dirección contraria, desarrolladores de C obfuscado, poetas Perl y hackers como jaromil han mutado sus programas en net.poesía experimental.

Las mutaciones y recursiones en la línea de comandos ni son una coincidencia, ni son agujeros de seguridad, sino herramientas que los administradores de sistemas necesitan a diario. Tal y como dice Richard Stallman, fundador del proyecto GNU y primer desarrollador de los programas de línea de comandos GNU, «es un poco paradójico que puedas conseguir definir algo en términos de sí mismo, que esa definición tenga sentido. […] El hecho de que […] puedas definir en términos de sí mismo y definirlo bien así, esa es una parte fundamental de la programación.» 8

Cuando, como observa Thomas Scoville, el vocabulario de instrucción y sintaxis como la de Unix pasa a ser «algo natural», 9 también se convierte en lenguaje conversacional, y la sintaxis se convierte en semántica no a través de algún tipo de inteligencia artificial, sino en términos pop culturales, como pasaba con las máquinas de escribir mutantes en la adaptación cinematográfica de «El almuerzo desnudo» que hizo David Cronenberg. Estas máquinas de escribir, literalmente «buggy», quizás sean el icono más potente del texto escribible. Y, aunque el software libre no se limite, de manera alguna, a las terminales – Unix empezó como software privativo – no dejar de ser esa cualidad escritora, y esa deconstrucción de la dicotomía usuario/consumidor, lo que hace que el software libre/de código abierto y la línea de comandos sean íntimos compañeros de cama.

[Este texto deliberadamente reutiliza y muta algunos pasajes de mi ensayo «Exe.cut[up]able Statements», publicado en el catálogo de ars electronica de 2003.]
 

Referencias

[Bar75] Roland Barthes. S/Z. Hill and Wang, Nueva York, 1975.

[Ben97] David Bennahum. Interview with Richard Stallman, founder of the free software foundation. MEME, (2.04), 5 1997. http://www.ljudmila.org/nettime/zkp4/21.htm.

[Kay90] Alan Kay. User Interface: A Personal View. En Brenda Laurel, editor, The Art of Human-Computer Interface Design, págs. 191-207. Addison Wesley, Reading, Massachusetts, 1990.

[Sco98] Thomas Scoville. The Elements of Style: Unix as Literature, 1998. http://web.meganet.net/yeti/PCarticle.html.


Notas a pie de página:


  1. [Bar75], p. 200
  2. [Bar75], p. 5
  3. [Bar75], p. 4
  4. [Kay90], p. 203
  5. Codework de Alan Sondheim, enviado a la lista de correo «arc.hive» el 21 de julio de 2002
  6. Thomas Scoville, The Elements of Style: Unix As Literature, [Sco98]
  7. Inédito en estos momentos, por publicar en la web http://www.cont3xt.net
  8. [Ben97]
  9. [Sco98], ibid.

Rediseños: mejorando la herencia recibida

Diseñar la solución a problema de cero nos presenta un terreno lleno de posibilidades. Podemos poner en práctica las técnicas que queramos, probar, errar, mejorar, etc. Sin embargo hay veces que llegamos a un proyecto que ya tiene un producto en funcionamiento y que requiere urgentemente de mejoras de usabilidad.

En diseño, también existe deuda técnica, bien sea porque se toman malas decisiones, se deciden cosas que ‘ya se harán mejor luego’ o se cometen errores de diseño que implican problemas para nuestros usuarios. Como deuda técnica que es el tiempo que pasamos sin solucionarla no hace más que empeorar la situación, agravada incluso por el hecho de que la deuda técnica en diseño sí se ve.

¿Cómo podemos gestionar la deuda técnica?

Si tienes la suerte de que el equipo de producto ha identificado y priorizado la resolución de la deuda técnica aquí van unas cuántas cosas que plantearse.

Conoce las debilidades de tu producto

No todos los problemas de usabilidad son igual de graves o tienen el mismo impacto para tus usuarios. En cualquier caso debes tenerlos identificados mediante cualquier técnica de testing.

Sé realista en cuanto a la dimensión y el impacto, asigna un grado de severidad al problema y decide junto a tu equipo qué pasos deben darse para solucionar cada problema de forma individual y conjunta.

Estrategia

¿Evolución o revolución?

Si empiezas el nuevo producto desde cero pensado para resolver todos esos problemas y que éste no sea visible hasta el final corres el riesgo de introducir nuevas funcionalidades y que nada de esto esté siendo probado por los usuarios que de verdad ‘sufrirán’ el cambio.

Por otra lado, el diseño evolutivo e incremental de pequeñas partes de tu aplicación puede comenzar a generar inconsistencias, y esto es un cáncer del usabilidad.

La consistencia es uno de los principios fundamentales del diseño, la consistencia ayuda a crear un lenguaje de interacción entre el usuario y el producto y facilita su aprendizaje. Introducir inconsistencias ya sean derivadas por rediseños parciales como por un fallo en la identificación de un patrón o un estándar, crea disonancias y dificulta el uso. Volver a ‘homogeneizar’ las soluciones puede llegar a ser bastante más costoso conforme se acumulan dichas inconsistencias.

Entonces ¿qué estrategia seguir? La estrategia depende del primer punto. Si tu producto sufre de inconsistencias o sufre de falta de personalidad, de que el lenguaje no es claro, de que hay ciertas funcionalidades que no se usan, las estrategias a seguir pueden ser muy diferentes.

Mi propuesta sería la siguiente (algo conservadora pero nada pasiva):

  • Una vez identificados y clasificados los problemas de usabilidad de tu aplicación según severidad e impacto, crea dos grupos en base al coste de la solución: baratos (bajo impacto pero fáciles de solucionar y de decidir sobre ellos) y caros (requieren tiempo, validación de conceptos y refactorizaciones de código)
  • Incluye soluciones baratas de forma constante en ciclo de desarrollo. Aunque luego un cambio futuro lo arregle todo o cambie de nuevo. No hagas sufrir más a tus usuarios más tiempo. La tipografía no funciona, cámbiala, no se muestran cosas alineadas, corrígelo. Demuestra a tus usuarios que el producto está vivo y con ganas de mejorar.
  • Lanza los cambios revolucionarios y costosos manteniendo lo que hay. Dirige a tus usuarios hacia tus nuevos diseños y mide el impacto que tienen ¿funcionan mejor? ¿tienen adopción? ¿dónde los abandonan? Esto te ayudará a decidir sobre el siguiente gran cambio y el éxito real de tu rediseño, aunque exista cierta disonancia los usuarios pueden entender mejor que existe una intención de cambio de su producto sin que le desarmes la casa de un día para otro.
  • No asocies el re-diseño sólo a nuevas funcionalidades. No hagas que tus usuarios de siempre piensen que no les importas. No crees dos identidades diferentes que puedan parecer productos diferentes.
  • Cambios de fuera hacia adentro. Esta discusión la he tenido muchas veces y aún no encuentro razones para hacerlo de otra manera. Si el layout o la navegación de tu aplicación es un problema, creo que es fundamental empezar por aquí e ir poco a poco entrando en el detalle del contenido de cada página o sección. Lo peor que puede pasar es que el rediseño de una sección no pueda ser accesible o encontrable, o que la sensación de pérdida sea igual que en el resto. Por otra parte los cambios estructurales pueden ayudar también a la resolución de deuda técnica en desarrollo.

Y recuerda, ignorar la deuda de UX afecta, entre otras cosas, a la confiabilidad del del producto. Da igual de quién recibiste la herencia, siempre que te incorpores a un equipo de diseño, la deuda hay que saber gestionarla.

Cómo adoptar un proceso de diseño centrado en el usuario en equipos ágiles

Es bastante común en las empresas de desarrollo tener equipos enteros trabajando mediante metodologías ágiles mucho antes de incorporar ningún rol especializado en Experiencia de Usuario. Incluso cuando cuentan con Diseñadores Gráficos, los referentes clásicos en prácticas como Scrum o Kanban no son muy explícitos en cómo o cuándo deben participar dichos roles durante el proceso. Cuando estos equipos necesitan de una vez por todas tomar una estrategia donde el producto que desarrollan sí tenga en cuenta al usuario para el que está destinado surgen las preguntas: cómo lo hacemos.

Diseñadores de …

Hace unos años cuando preguntaba a los desarrolladores qué esperaban de mí como diseñadora respondían algo así:

Espero que los diseñadores me entreguen un diseño de las pantallas y los flujos donde quede claro cómo debe comportarse la aplicación. Todo esto lo espero antes de empezar a trabajar en una User Story.

Básicamente proponían que el lugar de un diseñador era el de crear especificaciones (las interfaces de usuario vendrían a sustituir los diagramas de casos de uso, de flujo y modelado de negocio) siempre desde el lado del producto (ya que durante el desarrollo ni se nos ve ni se nos espera).

Evidentemente hoy en día no se concibe que un desarrollador sea ajeno al qué debe tener un producto al igual que no es realista que un diseñador no participe en el cómo debe funcionar. Sin embargo, las fórmulas para combinar a estos roles tan especializados dentro del flujo de trabajo ágil no resultan aún claras y, peor aún, generan la sensación de que aún existe más carga de trabajo.

La metodología como producto

Cuando se empieza a poner en práctica algo que hasta entonces no se había hecho o no había dado resultado tenemos que tener en cuenta que pueden llegar fricciones: hay que balancear la cantidad de cosas nuevas que se tienen que adoptar, lo bien o mal que nos las llevamos a la práctica y/o lo útil que resultan para el producto o el equipo.

Si consideramos la metodología de diseño centrado en el usuario como un producto, el equipo serían nuestros usuarios, por lo tanto la ‘percepción’ que tengan es tan importante como la propia eficacia y eficiencia de la metodología.

A continuación expongo algunas ideas sobre cómo enfocar ciertas actividades típicas de metodologías de trabajo como Kanban o Scrum para incorporar prácticas de análisis, diseño y validación para el desarrollo de productos con una mejor Experiencia de Usuario.

User Stories

La idea de las user stories o historias de usuario en desarrollo es muy sencilla, se han usado durante muchos años en la industria, aunque no fue hasta los años 90 que comenzó a recomendarse el uso de una plantilla en la que no sólo se contaba la historia desde la perspectiva del usuario, sino que que se añadía cierto contexto e intencionalidad. La plantilla más sencilla es la siguiente:

As a [type of user]

I want to [do something]

So that I can [get some benefit]

Las historias de usuario son una oportunidad para comenzar la conversación con el equipo de desarrollo y de producto incluyendo la información que hemos obtenido en nuestra investigación.

Type of user (Persona). No hablaremos solamente de tipos de usuarios, sino que podremos ser más específicos y mencionar a la Persona protagonista (la cual lleva consigo una información de valor que podría considerarse parte de los requisitos no funcionales de la plataforma).

Do something (Motivation). Cada historia de usuario debería estar enfocada a resolver un problema concreto, éste problema vendría especificado por la necesidad de un usuario a realizar una actividad.

Get some benefit (Expected outcome). Las actividades y necesidades que los usuarios quieren poder hacer con nuestra solución buscan alcanzar un objetivo concreto, incluirlo como parte de la historia nos ayudará a entender el propósito e incluso a identificar escenarios de test.

Backlog

El backlog es la herramienta que se utilizar para gestionar las User Stories que definen el producto digital, aunque también se incluyen otros conceptos como Epics (User Story de gran tamaño) y Themes (conjunto de epics). Organizar un y priorizarlo no es una tarea menor, aunque se simplifica si mantenemos claro los objetivos y creamos ciertas convenciones.

  1. Epics y Themes deben servir para crear una visión de producto a alto nivel
  2. Las User Sotries deben facilitar la ejecución y entrega del producto

A mí me gusta trabajar con prototipos de baja fidelidad para el primer objetivo y refinar con prototipos de alta fidelidad para el segundo. Es importante considerar para este segundo caso la velocidad a la que se tienen que tomar ciertas decisiones, la cual es posible alcanzar si se han creado recursos como guías de estilo y componentes de la Interfaz de Usuario (UI en sus siglas en inglés).

Desde el aspecto de la validación también se puede trabajar a diferentes niveles de acuerdo con estos objetivos.

Para el objetivo primero definiremos los escenarios que pueden ser más interesantes testear y los KPIs que nos indicarán el resultado y para el segundo la métrica que ayudará a calcular dichos KPIs.

Hay equipos que trabajan con dos backlogs (product backlog y sprint backlog) diferentes para cada uno de los objetivos. Esto tiene como ventaja la libertad para estructurar ambos pipelines como resulten más cómodos, pero carga de mayor trabajo a la hora de priorizar y planificar. Trabajar en un solo backlog requiere sin embargo de más consenso en la convención que quiera tomarse y cuando se trata de incorporar nuevas actividades se generará aún más fricción.

Qué podemos esperar

Cuando las cosas van bien…

  • el equipo entiende el problema y forma parte de la definición de la solución óptima
  • el equipo tiene claro los requerimientos de la solución
  • el equipo sabe lo que tiene que hacer en cada momento

Cuando las cosas van mal…

  • el equipo deja cosas sin terminar
  • el equipo deja de comunicar cosas importantes
  • el equipo hace tareas sin entender de dónde viene la necesidad
  • el equipo no va alineado

Una mánager me dijo hace tiempo algo que me encantó

No hace falta estar de acuerdo sino estar alineados.

Cuando se trata de definir procesos, podemos estar más o menos convencidos de que van a funcionar, pero si el equipo decide conjuntamente seguirlo cualquier persona que se desalinee hará que el resto no funcione de forma óptima.

La mejor estrategia es ir incorporando nuevas técnicas poco a poco, que el equipo se acostumbre a usar ciertos términos e identificar la necesidad de hacer una mejor investigación, mejor diseño y mejor testing y por lo tanto de seguir incluyendo más y mejores técnicas de diseño centrado en el usuario.

Conclusiones

Las técnicas de diseño centrado en el usuario no deben ser incompatibles con las metodologías ágiles, la forma en la que definimos el problema y describimos la solución pueden ayudar a mantener un enfoque más dirigido hacia las personas que usan el software y a conducirnos hacia soluciones que las tengan más en cuenta. Tanto lo que hacemos en diseño como la forma en lo que lo hacemos es parte de la comunicación y el proceso de entrega, así como de la creación e identificación de necesidades del producto.

La siguiente pregunta que me formulo es ¿estamos dispuestos a asumir el esfuerzo?

Tiene sentido definir un término como la Experiencia de Usuario

La Experiencia de Usuario (UX) es una disciplina holística, lo es todo, es el alfa y el omega, el principio y el fin, el caos y el orden y si le preguntas a un diseñador de UX te dirá que “cualquier cosa que hagas tú que no haya hecho él NO es UX”. Somos así.

UX es un término difícil de definir y, sin embargo, después de tantos años, me sigo encontrando con el mismo problema cuando tengo que explicarlo en algún taller o charla de introducción. Mejor o peor, esta es la forma en la que intento enfocar la definición del término: contando la historia sobre cómo llegué a valorar lo que significa ‘Experiencia de Usuario’.

Cómo llegué a entender el valor de la UX

En todo este tiempo de profesión creo que no llegué a entender bien la importancia de la UX hasta un día que, visitando el museo de Ciencia e Industria de Mánchester, muy recomendable por cierto, me encontré con una historia muy curiosa que me fascinó y está relacionada con la siguiente ilustración la cual representa un ‘día cualquiera’ en una fábrica algodonera.

 

IndustrialRevolutionManchester
Entre 1780 y 1820. La revolución de las máquinas

Ésta es una ilustración de cómo eran las máquinas entonces, el detalle de esta imagen está en esa niña pequeña. La razón por la que esa niña (al igual que otros niños de la época) trabajaba como un adulto era, entre otras cosas, porque las máquinas algodoneras estaban diseñadas de tal forma que obligaban para su funcionamiento que una persona, generalmente un niño, de no más de un metro de altura se moviera bajo el tejal para recoger el sobrante textil, evitar que la máquina se atrancara y mantener la cadencia de producción, incluso a riesgo de su propia salud física.

La verdad es que hasta que no vi estas imágenes no entendí el impacto tan grande y tan relevante que podía tener algo mal diseñado, mal ‘planteado’. Porque eso es lo que era, estas máquinas estaban simplemente pensadas para producir, para funcionar en un contexto mercantilista, pero no para que las manipulase un ser humano (adulto a ser posible) durante diez horas al día.

Todo esto sucede en el contexto de la Primera Revolución Industrial, época que incrustó en nuestra sociedad la creencia de que mediante la transformación tecnológica se perpetuaría la filosofía de la innovación, la modernidad y el progreso. ¿Os suena este pensamiento?

Mientras tanto el recién nacido mundo del cine comenzaba a reflejar cómo evolucionaría esta hasta la exageración proyectando distopías como la que veíamos en Metrópolis. Nada más lejos de la realidad ¿no?

Volviendo a la ciencia no ficción.

La ergonomía se ocupó entonces, y menos mal, de practicar un diseño que se adaptara a nuestras características físicas, psicológicas y ambientales. Personas, máquinas y contexto como principios fundamentales para el desarrollo de la tecnología.

Intencionada o no, las consecuencias de un buen diseño tendrían un enorme e irremediable impacto en nuestra sociedad como hemos visto. Tal y como vemos actualmente.

Seguimos con la historia y no tuvimos que esperar mucho para Revolución de la Computación. Personajes como Ada Lovelace o Alan Turing contribuyeron al surgimiento de una era histórica única, una era en la que las máquinas serían cada vez más inteligentes y sustituirán, quizá, el esfuerzo intelectual, de cálculo y procesamiento de información. La Informática como rama de estudios de todas estas ideas, nada que no sepáis.

eniac
Dos mujeres programando la ENIAC (1945-47) – US Army

Y desde este contexto, el equivalente histórico: la Interacción Persona-Ordenador, como área de conocimiento que estudia el diseño de estas ‘máquinas inteligentes’ para construirlas de acuerdo a las características de las personas que estaban destinados a usarlos.

Digamos que uno, quizá el primero, de los pasados de la Experiencia de Usuario reside desde el aspecto técnico, pero no es el único. César Astudillo lo cuenta muy bien en su artículo ‘¿Para quién luchamos?’. En el campo UX conviven ‘linajes distintos’. Como hemos visto los profesionales del diseño, pero también de las ciencias humanas, psicología, sociología, gente de negocio, de márketing y comunicación.

Pero ¿qué tenemos en común? Que todos desde nuestra forma de ejercer esta profesión vemos en la Experiencia de Usuario un espíritu de cambio. La UX surge como fenómeno transformador de la tecnología de trascendencia humanista.

La UX ya ha transformado el concepto de Usabilidad. No se limita por tanto únicamente a analizar la facilidad de uso (eficacia, eficiencia y satisfacción) de las personas que utilizan productos interactivos sino que alude también a un factor emocional del usuario. No se limita a calificar los productos de usables o útiles, sino que abarca las vivencias y las relaciones de las personas con dichos productos a lo largo del tiempo.

Como dice Nate Bolt, autor del libro Remote Research:

You don’t come up with an iPod just by making a Walkman really easy to use.

En este sentido el contexto emocional se suma al contexto de uso como factor determinante de la posible experiencia de usuario. En dicho contexto, se tienen en cuenta tanto sentimientos pre-asociados, como el actual estado de ánimo y emociones evocadas por el producto y afecta entre otras cosas a la capacidad de aprendizaje, atención, memorización, rendimiento y percepción de utilidad.

El término de UX según Donald Norman

En cualquier caso, si todo esto no ha terminado de convencerte mi sugerencia es leer y escuchar a los más grandes en este campo.

 

Building your own tools with existing software

I’m sure you’re sick to death to hear whether designers should learn to code or not.

To me, coding skills have let me create my own designer toolkit by reusing and extending current software tools. Have you ever imagine how cool would be to become your own user while developing a solution?

At the moment there are thousands of open-source apps available for anyone to improve them. Some of them do just basic things like To-Do lists apps and others are a bit more sophisticated like Chats.

I’m not even talking about libraries and that crazy need of knowing the whole universe of packages and extensions of a programming framework. I’m talking about already built-in solutions with a purpose, with an API, and with an easy-to-consume documentation.

This is an experiment that I love to make from time to time: just pick an existing tool, see the code, imagine a different purpose with the current interaction model, a different way of using the visual grammar and customise it to see how the UI paradigm will work for a different goal.

If you include yourself as the target user, as a designer no one better than you what you want and need so, you can go ahead and create something fantastic to make your life easier, funnier or more productive.

Designer, you have the power of imagination, the good habits of a well-stablished UX process, and a strong creativity and ability to conceptualise things that most people can hardly envision, you just need to know the keys to play with the code and cross the red line.

It is to me the funniest way to learn.

Soon I’ll share my latest experiment: buidling my own UX testing framework 😉

Prueba de diseño en Cinefilica

Así de chulo me está quedando el nuevo diseño de Cinefílica, pero tengo mis dudas sobre si publicarlo. El layout responsivo funciona pero me está dando muchos quebraderos de cabeza para encajar ciertas cosas.

Quitarme de un plumazo la navegación es un decisión muy radical. Si bien podría confiar en la página de inicio como distribuidor de contenido y potenciar el buscador (y sus resultados) para darle al usuario todo lo que necesita explorar, me quito la posibilidad de extender en algún momento el sitio web a algo más que el catálogo.

Otra cosa que hago desaparecer es el pie, creo que debería incluirlo aunque muchísimo más discreto que lo que hay ahora. Eso sí, los géneros debería hacerlos más visibles en la página de inicio, a fin de cuentas, están recibiendo visitas.

No sé si acabaré publicando estos cambios, en cualquier caso aquí los comparto.

UX for Developers

UX for Developers

Resumen de la charla ‘Mainstream UX’

Debe ser que estoy en un momento esencialista o cyborg, que últimamente disfruto de una forma más directa de la creación tecnológica a través de la filosofía.

Pensándolo bien creo que siempre ha sido así, es decir, si algo en común tiene creer que los computadores, sistemas, aplicaciones, productos digitales, etc. deben ser diseñados para que las personas que los usan tengan una buena experiencia así como haber estudiado los fundamentos matemáticos, físicos y lingüísticos para desarrollar herramientas de procesamiento automático inteligentes, es en mi opinión la creencia de que el binomio hombre-máquina es el único concepto que tiene sentido y es, en esencia, lo que debería centrar nuestra atención como diseñadores y desarrolladores de tecnología.

No sé muy bien por qué digo esto, porque lo que yo quería compartir es la presentación que hice el otro día en nuestro evento mensual ‘Yes We Tech’ y alguna de las ideas que traté de transmitir con más o menos éxito.

Nótese que el hilo conductor cinéfilo no es casual y me ayuda a contar la historia precisamente como a mí me gusta, con todo el drama posible.

‘Mainstream UX’

La hipótesis fundamental era sencilla: Si la UX (Experiencia de Usuario) no es mainstream, debería de serlo.

Para ello comencé con una escena clave en la historia del cine, escena que representa a trabajadores típicos saliendo de sus fábricas en un contexto de post-revolución industrial.

Esa gente ¿qué pensaría? ¿pensarían que las máquinas algún días les acabarían sustituyendo y por tanto haciéndoles prescindibles?

Con una visión más apocalíptica y lejos de creer que la mentalidad capitalista productiva persiguiera durante la revolución industrial únicamente traernos modernidad y progreso, la película de Metrópolis nos dibuja una escena mucho más franca sobre cuál es el papel del hombre en su relación con las máquinas: la esclavitud y el riesgo de su integridad física.

Si estas imágenes nos parecían exageradas, rescaté otra mucho más realista. La que muestra cómo en Manchester, ciudad pionera en cuanto a construcción de maquinaría industrial, en una fábrica textil de algodón cualquiera, el diseño de las máquinas obligaba a que una persona de ‘pequeño tamaño’ fuera la única capaz de pasar diez horas de jornada laboral asegurándose de que la producción no parara. En aquel contexto y en aquella sociedad esa personita era generalmente un niño o una niña.

Todo esto como excusa para hablar de un libro, o más bien de la creación de una disciplina, como la Ergonomía, que empezaba a preocuparse por invertir el modelo de creación industrial y comenzar a pensar más en cómo somos las personas que usaríamos esas máquinas.

Aunque hasta este punto todo nos pareciera ajeno nada más lejos, personajes como Alan Turing, las chicas de la ENIAC o Ada Lovelace de alguna forma contribuyeron a la Revolución de la Computación con una aspiración muy parecida: construyamos sistemas con una capacidad de procesamiento superior al de los humanos que nos ahorren esfuerzos de cálculo y de entendimiento de la información.

La modernidad y el progreso de nuevo al servicio de la cadencia productiva fueron arriesgando esta aspiración y a nuestras casas llegaron no sólo lo que serían herramientas de trabajo inútiles sino computadores destinados al uso personal poco usables.

Como ya pasara con la Ergonomía y aprovechando la herencia, la Usabilidad, el Diseño de Interacción y la Experiencia de Usuario se convierten en disciplinas impulsoras del desarrollo tecnológico al servicio de las personas (de sus expectativas, de sus necesidades, de sus objetivos y de su contexto).

A este punto de mi charla me di cuenta de que había gastado tanto tiempo en justificar por qué era importante que retomáramos esta perspectiva desde cualquiera de nuestros roles que a penas había facilitado entender cómo se lleva a cabo la tarea de diseñar y desarrollar productos que realmente estuvieran centrados en las personas.

Desde mi modesta experiencia, planteé cuatro preguntas esenciales:

  • ¿Para quién diseñamos?
  • ¿Qué diseñamos?
  • ¿Cómo diseñamos?
  • ¿Cómo podemos estar seguros?

Para quién diseñamos

Es probablemente la pregunta más fundamental de todas. Lejos de analizar a nuestros usuarios por sus características físicas o sociales, la respuesta debe partir de la búsqueda de patrones. No diseñamos para nosotros mismos (recuerda, you’re not the user) ni para nuestra madre (aunque parece que aún usamos a nuestras madres como modelo de la persona más tonta con la que validar la usabilidad de nuestros diseños, a parte del machismo inherente de quien usa este tipo de ejemplos, es igualmente erróneo pensar que todas las formas de ser un usuario ‘principiante’ son iguales).

No busquemos categorizar a nuestros usuarios sino agrupar, porque cuando se agrupa se hace un esfuerzo por:

  1. Entender qué tienen en común
  2. Entender qué tienen de diferente y
  3. Analizar el volumen y recurrencia de estas características

Por otra parte la Experiencia de Usuario no puede ser tan anonimizada, es decir, no basta con pensar en uno o varios grupos de usuarios genéricos y tratarlos como iguales, sino que es necesario buscar los rasgos de personalidad que tienen o queremos que tengan. Aquí es donde entra el juego de la construcción de un usuario inexistente al mismo tiempo que intentamos conocer a quien pensamos es nuestro usuario objetivo.

Un ejemplo, en mi opinión, muy oportuno de esta nueva personalidad es la que ha conseguido crear Instagram, red social que nos ha hecho creer que todos somos excelentes fotógrafos, que ha hecho fácil algo que mucha gente desconocía como el retoque fotográfico y que ha resuelto la carencia de la habilidad del encuadre rompiendo con el formato panorámico.

Qué diseñamos

Esta podría ser la pregunta más capciosa. ¿Diseñamos interfaces? ¿diseñamos experiencias? ¿modelos de negocio?

Mi único consejo (conste que mis consejos a mí aún me cuesta aplicármelos) es no dar nada por hecho. Cuando creemos que diseñamos un producto que es realmente un servicio, una interfaz que es realmente una pantalla, una web que es realmente un motor de procesamiento, pensar en estándares y patrones es difícil. ¡Pero no imposible!

Es importante identificar la esencia del modelo que estamos usando para poder crear sobre él una gramática familiar. Si es una web visible a través de un navegador, el historial de navegación y la posibilidad de que el usuario escape simplemente re-escribiendo una URL es algo que no sucederá de la misma forma que si usamos una aplicación desde nuestra muñeca aunque la tarea – por ejemplo, buscar una dirección – sea la misma. El paradigma que usemos tiene ciertos estándares (cambiantes sí, pero estándares al fin y al cabo) que ayudan al lenguaje de interacción.

Cómo diseñamos

Si nos atenemos a nuestras habilidades como diseñadores está claro que algunos diseñan mejor que otros. Pero esta pregunta no va en ese sentido.

Las herramientas, las metodologías, las prácticas y las costumbres no tienen tampoco por qué ser las mismas en cada proyecto o para cada interfaz. Durante mucho tiempo he detestado la mentalidad de hacerlo todo con Photoshop o buscar la herramienta de prototipado universal con la que podamos representar todo tipo de paradigmas e interacciones.

No dejemos que nuestra búsqueda de la especialización personal/profesional haga que equivoquemos la forma de comunicar el diseño.

Por otra parte, el propio proceso de búsqueda de soluciones acabará formando parte de la cultura de diseño y desarrollo y, por tanto, de la misma identidad de la empresa que detrás haya ofreciendo dichos diseños.

Cómo podemos estar seguros…

… de que lo hacemos es realmente usado de la forma más eficiente posible, de que el resultado de lo desarrollado es satisfactorio, de que la interacción es eficaz, de que la respuesta emocional es positiva y la creación es valorada por los usuarios. Cómo sabremos esto si no probamos, observamos, medimos y tomamos decisiones que vayan directamente a iterar y mejorar.

El llamado ROI (Return of Investment) puede ser condición necesaria pero no suficiente para garantizar que la experiencia de usuario es de calidad. Dentro de las diferentes formas de analizar esta necesidad, la implicación o contemplación de los propios usuarios en la validación del sistema que se está desarrollando es fundamental para eliminar la incertidumbre.


Finalmente quise hacer una nueva reflexión sobre la importancia de realizarse estas preguntas independientemente del punto evolutivo de la tecnología y recordarnos que detrás de cada interfaz siempre hay un humano.  Que la experiencia de usuario es tan fundamental como el propio hecho de formar parte de la comunidad de creadores de tecnología y que por esta razón debe ser mainstream, si no lo es ya.

Y por si todo esto nos pareciera una fumada siempre podemos volver a nuestras fábricas y vivir con la preocupación de no saber si algún día las máquinas habrán sustituido no sólo el músculo sino también el cerebro del hombre.  

Side Projects

I think everybody should have at least one side project.  

It forces you to think in the consequences of your decisions and assume the responsability of sucess or failure

It keeps you focused on looking for the perfection while you have to be aware of being pragmatic.

It helps to balance a good design and a good implementation

Side projects are personal, so you learn the importance of being proud of what you do.

Side projects are pressure-free, so you learn to enjoy of every step of the process. 

My side projects may never succeed but I won’t keep on working on them because they help me to love my job, to go on discovering new things, to settle down knowledge and to maintain the illusion.

Does this mean that your daily job doesn’t give you the same kind of experience?

Absolutely not, time and budget factors are key to keep it real. I strongly believe that productivity is necessary as a way of taking the most of your dedicated time at work. Besides, work it’s the perfect team environment to proof all what you get from your side projects. 

So yes, love what you do, do what you want, and collect what you get with proud and satisfaction.


Cinefilica is my side project, and now I have the chance to take it back and share it with a very good friend of mine who’ll help me to try a different idea over the same concept.

El contexto del usuario

El hombre de la foto fue mi taxista hacia el Aeropuerto de Hong Kong. Le pedí si podía fotografiarle y me dejó con la condición de que él no saliera identificado.

Usaba hasta 5 teléfonos móviles, uno con peticiones entrantes de diversos hoteles, otro con las peticiones del radio taxi, otro con el resultado de la actividad de apuestas, otro para recibir llamadas con un listín de contactos y el otro no logré entenderlo.

Ninguno de ellos mostró un mapa en todo el recorrido. Si mostraron información sobre el tráfico, no lo sé. Pero ni un sólo mapa, ni un sólo sonido de voz humana explicando indicaciones de cómo dirigirse a un sitio. Sólo ‘beeps’, zumbidos y llamadas.

El taxista, un Toyota, y un montón de pantallas sobre el volante. ¿Qué diseñador/a podría imaginarse esto antes de empezar con el papel y el lápiz?