Post-humanismo y diseño

No todos podemos sostener, con un alto grado de seguridad, que hemos sido siempre humanos. – Rosi Braidotti “Lo Posthumano”

El concepto de humano, nacido en la Ilustración, nos da cierta tranquilidad. Ser humano es lo natural en nosotros, es nuestra característica fundamental como especie, nuestra identidad.

Sin embargo, en el contexto de las sociedades globalizadas y tecnológicamente dirigidas, esta identidad y sus relaciones con los demás se vuelve más compleja. Robots, prótesis, neurociencias, biogenética nos llevan a un mundo de tecnotranscendencia y ciberdrama.

Read more

Not a single design process

We spend years and years exploring, trying and following guidelines about what’s right and wrong to do when “doing UX”. We look for the perfect process, the one that tells you: yes, you’re following a user-centred design methodology that will ensure the best user experience possible.

But let’s face it: there’s no one single process that helps you to solve any and every single problem, and not all designers can and must follow the same creativity path to build good solutions.

So what shall we do then? My suggestion, follow principles, not processes and get alignment, not agreement.

Read more

Diseñar con datos, más allá del A/B Testing

Resumen

Diseñar con datos parece sencillo: haces un test A/B y te quedas con la solución que más conversiones tenga ¿cierto? pero ¿somos conscientes de lo que nos dicen los datos? ¿cómo sabemos qué conviene evaluar? ¿qué hacemos si los resultados contradicen nuestras ideas originales?

¿Hay vida (y datos) más allá de los tests A/B? En esta charla me gustaría compartir algunas ideas y experiencias sobre cómo, cuándo, dónde y por qué podemos usar los datos a lo largo de un proceso de diseño para la Experiencia de Usuario, desde la investigación de usuarios (cuantitativa) hasta la toma de decisiones sobre un producto digital real.

Trataremos también de reflexionar (durante y después de la charla con un café) sobre cómo crear una cultura del diseño informado con datos, donde la experimentación y el desafío sean una constante.

Además, los datos están de moda, el diseño marca la moda, Netflix lo hace ¿qué puede salir mal?

Read more

6 examples of bad dashboard designs

Dashboards are used to present large amounts of information in a condensed and visual form. 

They are meant to be represented on a single screen, to make an efficient use of the space, avoid superfluous graphics and include actionable, meaningful and relevant data according to viewers objectives.

However, we can find some examples where dashboards display the information in the wrong way. These are some examples of bad designs that can make a nicely intentioned dashboards fail.

1. Tiny and spaced

Yet the dashboard is displayed in one single screen, the amount of white space between charts make it difficult to read as unique piece of information. Increasing font-size and adjusting proportions would make it more efficient.

Resultado de imagen de dashboard opensource
Pentaho Dashboard
Read more

Opensouthcode: resultados de la encuesta y datos de la experiencia

task performance opensouthcode survey

El pasado 1 de Junio mi colega Miguel Torres y yo hicimos una presentación en el evento sobre software libre Opensouthcode y hablamos sobre cómo podíamos analizar la Experiencia de Usuario (UX) con Javascript (JS). Durante nuestra charla presentamos un modelo con el que tomar métricas automáticas de usabilidad para poder conocer mejor a las personas que interactúan con nuestros productos digitales construidos con tecnologías web.

Al final de la presentación hicimos una demostración de cómo podía aplicarse a un caso real y para ellos utilizamos como excusa una encuesta que habíamos lanzado semanas antes. La encuesta no serviría más que a la presentación, sin embargo, ya que un buen número de personas se molestaron en contestarla, es nuestro deber compartir la información que recogimos.

Es importante aclarar que la forma en la que almacenamos los datos fue un poco peculiar, y por peculiar me refiero a que usamos el mismo Google Analytics, un servicio en principio destinado a analítica web. En cualquier caso, aquí están los resultados.

Read more

Reinventando los ‘formularios’ de registro

Daily UI Design Challenge es una suscripción de correo que te envía a tu buzón un reto de diseño cada día durante 100 días. Personalmente no creo que pueda seguir el ritmo, pero sentí curiosidad por saber qué es lo primero que mandarían y he aquí el reto: Diseñar un formulario de registro.

Sign-up Forms

A mí me gustaría darle una vuelta a este reto y re-imaginar otra vez los formularios de registro por varias razones:

  • Los encuentro contra intuitivos: no existe una necesidad de identificarse sino de ser identificados
  • A los usuarios no les gusta dar sus datos una y otra vez para acceder a los servicios de una web

Read more

Retrospectiva

Hace un año cambié de trabajo. Buscaba fundamentalmente dos cosas esenciales para mí:

  • Un buen proyecto con vida
  • Un buen ambiente de trabajo

Un buen proyecto

En mis anteriores años como diseñadora he pasado demasiado tiempo creando ‘conceptos’ que nunca terminaban viendo la luz. No se vendían, se cancelaban a mitad de desarrollo, nacían muertos, no terminaban, no se implantaban de forma adecuada… A pesar del rodaje y de lo mucho, muchísimo, que se aprende en esas circunstancias necesitaba recuperar el contacto con el mundo real, ése en el que tu trabajo impacta en la vida de un producto digital, en el que tus errores y tus éxitos tienen consecuencias y en el que se puede ver el valor de cada decisión.

Empezar a trabajar en un servicio online me ha dado la posibilidad de:

  • Tomar mejores decisiones en base a datos de analítica web
  • Experimentar con métricas de UX para medir la adopción de nuevos diseños
  • Asumir las consecuencias de una mala decisión y rectificar
  • Establecer un modelo de trabajo y un proceso de diseño que se ajuste mejor a un entorno de despliegue contínuo
  • Integrarme en un equipo de desarrollo bien engranado con la menor fricción posible
  • Disfrutar del resultado en equipo y del impacto que tiene el diseño y el desarrollo en el propio negocio
  • Hacer más ingeniería del software de la que me imaginaba

Evidentemente hay cosas que no he podido conseguir aún y que me gustaría conseguir este año:

  • Mejorar la consistencia total de la interfaz de usuario y las comunicaciones con los clientes
  • Eliminar todos los elementos excesivos del diseño
  • Homogeneizar la navegación y los patrones de interacción
  • Aumentar el nivel de detalle y excelencia visual
  • Aumentar la satisfacción de los usuarios en su experiencia global con los productos y servicios digitales
  • Crear una plataforma totalmente flexible para que se adapte mejor al flujo de trabajo de cada usuario

Un buen ambiente

El segundo aspecto era igualmente importante ya que en la anterior empresa en la que estuve, pasada la euforia startupera y la motivación por la belleza de un producto tecnológico intelectualmente desafiante, la oficina se convirtió para mí en un lugar anodino, aburrido y tóxico. No puedo culpar ni exculparme. Los egos chocaban, no se tomaban (buenas) decisiones y no se veían los frutos por ningún sitio. Cuando esas circunstancias se dan lo mejor que se puede hacer es usar la poca energía que queda y marcharse con la lección aprendida, en lugar de resistir hasta el agotamiento (si las circunstancias personales te lo permiten claro).

Pero he tenido mucha suerte y quiero pensar que he trabajado para progresar. Cambiar de empresa, de cultura y de oficina es una apuesta muy fuerte que se hace con muy poca información (a penas alguna recomendación de trabajadores que conozcas y lo que captes durante el proceso de selección). Aunque en realidad el aspecto más desafiante es mantener y contribuir al ‘buen ambiente’ ante cualquier circunstancia.

 

Hace un año me propuse hacer retrospectiva como forma de disfrutar de los éxitos profesionales conseguidos y entender bien qué cosas me estoy dejando a medio camino o en tierra de nadie. Hoy ha pasado un año desde que dije adiós a la firma ITRS, y decidí apostar por la fintech Ebury. No puedo estar más satisfecha de este año e ilusionada por lo que queda por delante, espero que sigan confiando en mí porque aún no he terminado con este proyecto 🙂

(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.

Testear la Experiencia de Usuario

Hace más de un año de la publicación Measuring UX with your own tools en la revista nosolousabilidad.com, desde entonces he seguido trabajando y viendo el testing como una de las formas más prácticas para tomar decisiones en diseño. Me gustaría volver a reflexionar sobre algunas cosas que menciono en el artículo y ‘actualizar’ algunas ideas.

Aunque los datos no tienen todas las respuestas, es importante establecer ciertas métricas para medir de la forma más objetiva posible si el producto que estamos desarrollando va a funcionar para las personas que están destinado a usarlo.

Efectivamente los datos no nos cuentan todo, de hecho, el riesgo de ‘medir mal’ puede hacer incluso que nos desoriente a la hora de buscar una respuesta. Sin embargo, incluso cuando un dato parezca demostrarnos algo a lo que debemos prestar atención, seguimos teniendo la posibilidad de corroborarlo con más experimentos.

El proceso de Validación es contínuo, desde la generación de la idea inicial hasta las sucesivas mejoras e iteraciones que sobre el producto vivo se realizan.

Un enfoque de diseño guiado por datos no es más que asumir la experimentación como parte del proceso, que viene a ser el mismo principio fundamental que nos mueve a trabajar con prototipos antes de lanzarnos a desarrollar el producto final.

Los tests de usabilidad no consiste en testear a usuario. Es decir, no evaluamos cómo de buenos o malos son las personas usando nuestra solución, sino que medimos la calidad de producto en términos de una experiencia de usuario satisfactoria. También afirmábamos que hacer UX Testing es hacer User Research. Como proceso iterativo que es, los descubrimientos hechos deben ayudar a un mejor entendimiento de los usuarios, cómo son y cómo interactúan real y finalmente con nuestro producto a pesar de nuestras creencias.

Hay dos ideas fundamentales que me gustaría dejar claras:

  1. Los usuarios no siempre tienen la razón, pero debemos conocer cómo son y cómo se comportan. En ningún momento testear con usuarios debe suponer juzgarles o estereotiparles.
  2. Testing y Research son dos caras de la misma moneda

Los objetivos de la validación persiguen generalmente:

  • Reducir la incertidumbre
  • Validar hipótesis
  • Guiar el proceso
  • Facilitar la toma de decisiones informada
  • Identificar nuevos requisitos de producto
  • Entender mejor el modelo mental de los usuarios
  • Encontrar y resolver problemas de usabilidad

Las métricas de UX tienen algo de especial o diferenciador con el resto de métricas y es que revelan información no sólo del sistema sino de las personas, de su comportamiento y sus actitudes. Por eso cuando interpretemos las métricas debemos tener especial cuidado y calcular también intervalos de confianza, al igual que razonar sobre los principios de diseño las posibles conclusiones que se obtenga.

¿Cómo podemos cuantificar la Experiencia de Usuario? Métricas y Métodos

Para poder tener una idea del estado de usabilidad de un producto digital, es posible obtener información de tres formas diferentes:

  1. Basado en lo que los usuarios hacen
  2. Basado en lo que los usuarios dicen
  3. Basado en lo que nosotros (como testeadores) observamos

Estos tres puntos de vista son igualmente importantes y, aunque no todos ellos se pueden considerar cuantificables, hay una intención clara de analizarlos de forma combinada como parte de un indicador global de la UX.

¿Por qué es importante un score de UX global? Un score global de UX puede ser interesante en grandes empresas para tener una visión de aquello que afecta puramente a la experiencia donde múltiples procesos de desarrollo confluyan. Sin embargo, incluso en esos contextos donde es muy apetecible para los ‘managers’ demandar un indicador global, no es en absoluto recomendable y es, incluso, contraproducente. Los KPIs de UX deben ser accionables y ayudarnos a tomar decisiones, no a justificar diseños.

Midiendo la User Performance (lo que los usuarios hacen)

Las métricas de rendimiento serán calculadas basadas en comportamientos, escenarios y tareas concretas de los usuarios. Estas métricas nos hablarán de eficacia y eficiencia y nos servirán para entender la magnitud los problemas de usabilidad que encontremos. Eso sí, nos indicarán qué está yendo mal, no por qué está yendo mal.

Las métricas más comunes son:

  • Éxito de la tarea: cómo son de eficaces los usuarios a la hora de realizar las tareas planteadas en un test con usuarios. También se puede medir la tasa de errores.
  • Duración de la tarea: cuánto tiempo ha utilizado el usuario en realizar una tarea del test.
  • Errores: el número de errores que ha tenido un usuario al realizar una tarea.
  • Eficiencia: cantidad de esfuerzo que un usuario gasta en realizar una tarea, por ejemplo el número de clics.
  • Curva de aprendizaje: cómo el rendimiento mejora o empeora a lo largo del tiempo.

Me gustaría hacer especial hincapié en la forma en la que se expresan y se describen esas ‘tareas’ propuestas para los usuarios.

Las tareas propuestas deben tener sentido dentro de un escenario y contexto de uso específico. En lugar de pedir a nuestros usuarios ‘hace esto’ o ‘haz lo otro’ lo que tendemos a pedirles es que se imaginen en un determinado escenario y proponerles una serie de retos u objetivos para ver cómo podrían lograr hacerlos.

Algunas reglas que deben seguirse para estas tareas son

  1. Hacer la tarea realista
  2. Hacer la tarea accionable
  3. Evitar pistas o descripción de pasos

Independientemente de si estáis haciendo un test de usuario formal o de ‘guerrilla’, esto último es muy importante. Al fin y al cabo no sólo enlaza con la forma en la que describimos y entendemos el problema, sino que también es la mejor conversación que podemos tener con los usuarios, sentarnos junto a ellos, verlos interactuar en un contexto real, con unas necesidades reales y quizá con uno o varios prototipos que le permitan alcanzar sus objetivos. Éste es feedback es mucho más valioso que un simple ‘me gusta/no me gusta’.

Google Analytics al rescate

Una forma alternativa, que no sustituye a la anterior pero sí aporta información parecida (según queramos medirla) en un contexto diferente, es hacer uso de eventos y de Google Analytics para monitorizar en un producto online sin necesidad de organizar sesiones de tests de forma continuada.

Midiendo la Usabilidad Percibida (lo que los usuarios dicen)

No todas las personas sabemos expresar con palabras los problemas que encontramos. A veces simplemente reaccionamos con gestos, expresiones o guardamos silencio.

Nuestros usuarios no son menos, a pesar de que nuestra expectativa por conocer qué piensan y a veces nuestras críticas sobre cómo expresan los problemas nos lleva a creer que sólo lo que se dice es relevante, nos puede inducir a equivocaciones.

Sin embargo es importante escuchar y hacerles ver que son escuchados. Durante una sesión de test con usuarios una técnica muy efectiva es el think-aloud. A los usuarios se les pedirá que cuenten qué están intentando hacer durante la resolución de una tarea. Después de haber completado la tarea se les puede preguntar que califiquen el grado de complejidad percibida en la tarea, De esta forma podremos saber cómo varía su percepción a lo largo del tiempo. Si además les solicitamos esta información antes de realizar la tarea podríamos comparar sus expectativas con su experiencia final.

Finalmente, tras la realización de una sesión de test completa se les puede pasar una encuesta estándar conocida como Software Usability Survey para que puedan expresar con escalas de uno a cinco cuál es el grado de usabilidad general percibida en la solución.

En resumen, conseguiremos información mucho más valiosas si no hacemos preguntas directas a los usuarios sobre ‘gustos’ sino pidiéndoles que valoren soluciones específicas para tareas y problemas concretos expresándose como grados de satisfacción, al mismo tiempo que escuchamos y observamos sus comentarios y expresiones durante el intento de realización de dichas tareas.

Midiendo las Issues evaluadas (lo que observamos)

Cuando realizamos revisiones de experto o heurísticos de usabilidad iremos identificando una serie de issues que en principio nos darán una métrica puramente cualitativa. Normalmente, una issue viene descrita por un título y una descripción del problema, aunque es recomendable añadir también un grado de severidad del problema y relacionarla con la tarea específica que el usuario estaría intentando hacer en ese momento.

El grado de severidad y la frecuencia de aparición de las issues nos van a ayudar de nuevo a cuantificar esta métrica.

Hablábamos al principio de la sesión de los principios heurísticos de Nielsen, y son ciertamente estos principios los que se observan y evalúan siguiendo ciertos escenarios de tests donde los expertos nos ponemos en la piel del usuario y tratamos de analizar cómo está siendo la experiencia con la solución.

Estas revisiones de experto las podemos realizar con la frecuencia que queramos, generalmente de sprint a sprint, ayudan a cazar ciertas issues antes de que llegue a un cliente. No tiene ningún valor esperar a que un usuario se queje (ya que posiblemente no lo hará) de que algo está mal alineado o es inconsistente, sin embargo lo que sí hará será percibir desorden en la interfaz y notar cómo dificulta su aprendizaje.

Errores comunes

De entre los errores más comunes que me he encontrado cuando he realizado heurísticos se encuentran:

  • Mensajes de información y error
  • Formularios
  • Colocación de elementos en la pantalla, dificultad de escanear
  • No hay manera de encontrar o buscar
  • Inconsistencias en iconografía, verbos (acciones), patrones de navegación
  • La información está mal organizada
  • Demasiada densidad de información
  • Las llamadas a la acción no están claras
  • Los usuarios tardan en interpretar la información
  • Los usuarios tienen miedo a interactuar, si hay errores más

 

Conclusiones

Medir la Experiencia de Usuario no es una tarea imposible ni inabarcable, simplemente hay que tener claro qué preguntas queremos contestar en cada momento y una vez tengamos respuestas hacia dónde debemos explorar más. Ya sea para monitorizar la usabilidad de un software o como guía de un diseño informado, aplicar métricas cuantitativas aporta una visión única a la forma en la que desarrollamos software. En futuros artículos hablaré sobre cómo visualizar y analizar dichas métricas.

 

Photo by Dawid Małecki on Unsplash