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.

But I’m a (cheer)Leader

But I'm a Cheerleader

Siempre que alguien me habla de liderazgo me viene a la mente esta película. But I’m a Cheerleader (1999) es un film estadounidense que critica en clave de humor la construcción social de los roles de género y la heteronormatividad a través de la historia de una chica que, en principio, no se reconoce como lesbiana (cinta divertida y recomendable).

Salir del armario en el sector tecnológico no está relacionado (sólo) con los roles de género, sino con los roles profesionales cargados igualmente de estereotipos, de orgullo e incluso de fobias. Esa obsesión por la carrera profesional que parece dibujarnos un único camino para alcanzar ‘el éxito’ tiene un componente clave: ser un/a leader (aunque te mueras de hambre). 

Pero ¿cómo se llega a ser directivo de una empresa? ¿quiénes son los jefes? ¿puede un CTO venir del campo del diseño? ¿qué esperan de nosotras/os? Fundadores, emprendedores, iniciadores, incitadores, hombres de bien vestir y de mal tratar, insoportables todos que nos hacen creer que nosotras, que nosotros, no podemos ser lo que nos dé la gana sin andar justificando esta especie de travestismo profesional o transgresión laboral. En cualquier caso, espero que nuestras aspiraciones no se curen nunca de sentido crítico, de empatía o de sensibilidad y que deconstruyamos cualquier identidad que no nos acepte como somos.

Menos charlas Ted y más performance.

La química de la experiencia (de usuario)

Desde el deseo o intención de uso, las expectativas, la presentación de la interfaz, pasando por la interacción de la persona con el producto, el aprovechamiento de su función y la fidelidad a lo largo del tiempo se construye un marco que podríamos denominar experiencia de usuario.

Esta relación de las personas con la tecnología pasa por establecer un lenguaje común (design system) y ciertas normas de comportamiento (interaction patterns) como mínimo. Pero ¿cuál sería la máxima aspiración que podríamos querer tener respecto a la experiencia?

Por muy Punset o muy Sinek que suene, si el objetivo del diseño para un producto es facilitar una experiencia positiva, de bienestar y felicidad ¿por qué no recordar cómo nos pueden ayudar los químicos del cuerpo a conseguirla? Las redes sociales son un gran ejemplo de cómo diseñar para aumentar los niveles de estos químicos de la felicidad.

“Hay que mirar a los otros no para fustrarse sino para cooperar” – Eduard Punset

La otredad de la tecnología

Oxitocina

Empiezo por la que seguramente es la más subestimada de todos los químicos pero el más importante: “la hormona de los vínculos emocionales” imprescindible para la supervivencia de la especie. Esta hormona dirige al resto y la solución para aumentarla es fácil: abrazar más, regalar, confiar en la gente. Es una hormona que muestra sus resultados a largo plazo, con el tiempo y el esfuerzo.

Soluciones de diseño:

Endorfinas

Las endorfinas son el más simple de todos los químicos y se considera un anestésico natural, su función es aliviar el dolor. Si queremos empezar un hábito las endorfinas nos ayudarán a eliminar el sufrimiento asociado por el esfuerzo que requiere alcanzarlo. Las endorfinas se sienten como una pequeña euforia que calma el dolor. El deporte, bailar, cantar o el trabajo en equipo aumentan el nivel de endorfinas en el cuerpo.

Soluciones de diseño:

  • Hacer una pequeña tarea de forma fácil (tu primer tuit, tu primera foto)
  • Los tours de inicio
  • Recibir un ‘me gusta’

Serotonina

La serotonina la notamos cuando nos sentimos importantes, también tiene su efecto a medio y largo plazo ya que nuevamente depende de nuestras relaciones sociales. Cuanto más respeto y reconocimiento se tiene de nosotros, mayores son los niveles de serotonina. Sentirnos orgullosos de nosotros mismos o recordar momentos felices son formas de incrementar la serotonina.

Soluciones de diseño:

  • Reputación en perfiles sociales a través de métricas (número de seguidores, de likes, etc.)
  • Recordatorios de aniversarios
  • Los tours de inicio

Dopamina

He dejado la dopamina para el final ya que se parece mucho a la serotonina pero a corto plazo. La dopamina es la responsable de la motivación. Cuando comenzamos un nuevo hábito, el mero hecho de comenzar a trabajar por un objetivo hace que se disparen los niveles de dopamina. La dopamina provoca un placer instantáneo, como comer, o incluso ver la comida ya es un disparador de este químico.

Soluciones de diseño:

Desafiar al usuario

La dopamina, enforfinas, serotonina y oxitocina son claves para sentirse bien. Cuando nuestro cerebro emite estos químicos para cumplir con su función podríamos decir que nos sentimos felices.

Cuando un producto digital plantea propósitos a sus usuarios, objetivos alcanzables, o retos interesantes, por ejemplo, lo que asegura es un entorno perfecto para provocarlos de la misma forma que provocar estos químicos nos ayudará a alcanzar esos mismos objetivos.

Un ejemplo:

Facebook te ayuda a comunicarte y compartir con las personas que forman parte de tu vida.

Facebook, al igual que muchas otras redes sociales nos desafían, nos alientan a alcanzar un objetivo que parece necesario y vital. Como red social que es, la interacción y cooperación con tus ‘contactos’ es esencial.

Sin embargo es curioso que cuando nos proponemos una meta a nivel personal muchas veces no contamos con la gente que nos rodea, creemos que es algo que debemos alcanzar solos (sólo tenéis que sondear esos propósitos de año nuevo entre vuestros amigos).

Ésto es algo que las redes sociales hacen muy bien, primero porque ponen a nuestros contactos como medio para que ‘comunicarte y compartir’ sea algo significativo. Y segundo porque como hemos visto, ésta es la base fundamental para aumentar los niveles de oxitocina: ser fieles y sentir que mantenemos las relaciones a lo largo del tiempo.

Cada pequeño paso que hacemos (publicar contenido) para cumplir el propósito (comunicarnos) nos provocará un ‘chute’ de placer instantáneo en forma de endorfinas. El esfuerzo que cuesta alcanzar el objetivo se convertirá en placer inmediato, por ello no debemos preocuparnos por si seremos capaces, ya que la satisfacción estará ligada al trabajo que invertiremos.

Por otra parte, es natural compartir cada logro una y cien veces, ésto ayudará a aumentar la serotonina y reducirá, por otra parte, el riesgo de depresión.

Finalmente, las pequeñas metas (una reacción, un comentario) provocará a que la dopamina fluya y nos ayudará a mantenernos motivados.

La ausencia del miedo

Los comportamientos que provocan las redes sociales son habitualmente del tipo proactivo, aunque como en el caso de los propósitos personales, no todos consisten en comenzar a hacer algo nuevo, sino en dejar de hacer algo que no nos conviene.

Esto tiene que ver con evitar el aumento de otro químico igualmente importante: el cortisol. Este químico que se libera en situaciones de estrés e inhibe la oxitocina, surge en situaciones de miedo o ansiedad extrema.

Tener en cuenta estas situaciones es esencial para el éxito del producto. Aspectos como la privacidad, la seguridad en términos informáticos, físicos y morales, o la autenticidad de los individuos (de los usuarios) hace que se reduzcan posibles situaciones de miedo que provoquen altos niveles de cortisol.

No debemos olvidar que algunas redes sociales también matizan o deciden los contenidos que nosotros (los usuarios) vemos con más frecuencia y más prioridad, e incluso el contexto en el que aparecen (porque es popular o lo más comentado). Este ajuste de contenidos intencionado o no también podría afectar a los niveles de cortisol.

 

 

Nota sobre este artículo

Sobra decir que yo no soy experta en química ni biología, pero todas estas cosas me resultan muy interesantes, leo sobre ellas, comparo y escribo en voz alta. Por otra parte, la relación de estos químicos con la experiencia de usuario es algo de lo que ya se ha hablado en la industria. Si te ha gustado esta entrada y tienes más enlaces interesantes me encantaría que los compartieras 🙂

 

Dar formación como recurso

¿Te ha picado alguna vez el gusanillo de la formación? Entonces sabrás como yo lo que se siente cuando quieres empezar a compartir todo lo que has aprendido y no sabes por dónde empezar.

En realidad la tarea de formar es más compleja ya que no se trata sólamente de aportar experiencia sino rigor y una base teórica y práctica sólida para que los estudiantes sean incluso mejores de lo que tú fuiste alguna vez.

Sin embargo, viendo la cantidad de oferta formativa que hay por la red parece difícil de competir. Por esto hace un par de años cuando me entraron ganas de meterme en este campo de la formación me lo planteé de la siguiente manera

  1. Recopila todos los materiales que has usado durante tu trabajo
  2. Fórmate y lee mucho
  3. Escribe y publica lo que has aprendido
  4. Haz talleres y cursos que te permitan recoger feedback de los asistentes
  5. Da charlas en público
  6. Grábate hablando y explicando ideas
  7. No empieces sola
  8. Practica lo que sabes en tu trabajo diario
  9. Ofrece recursos sin dar lecciones a nadie
  10. No trabajes gratis (el precio no es siempre económico)

No puedo decir que éste sea un objetivo cumplido, de hecho lo comparto hoy como uno de mis propósitos recurrentes. Aún me queda muchos proyectos de formación que poner en marcha pero sí es cierto que ya he empezado a trabajar en ello, gracias a Lemoncode, a este blog y a Yes We Tech puedo llevar a cabo mi estrategia.

Nueva estrategia de blogging

El blogging no ha muerto o eso quiero pensar. Como siempre me ha gustado escribir, pero siempre me ha costado mucho seguir una disciplina y una estrategia de contenidos razonable, he decidido intentarlo por undécima vez de una forma diferente.

Inspirada por el último podcast de Paul Boag: How to boost your business reputation with blogging, he empezado por crear ciertas estructuras para los artículos que voy a ir publicando que me faciliten desarrollar los contenidos que quiero contar en cada entrada.

Las comparto con vosotro/as por si os resultan útiles.

Conferences, events, etc.

  • What is the conference about?
  • Why it is important for me?
  • What I’ve learnt?
  • How can I apply the knowledge?

Problems

  • What’s the problem I’m trying to solve
  • How this became a problem
  • Which are the alternatives I’ve looked at
  • Which solution I’ve taken
  • How do I expect to evaluate if it was good or bad solution
  • Resources where you can learn more

Books, Resources

  • What is the book main topic
  • Why did I decided to read it / What I was looking for in it
  • What I’ve discovered
  • How can I apply it in practice

Tools review

  • What is the tool for
  • What’s good
  • What’s bad
  • What makes it excellent or unique from my perspective
  • How can I integrate it in my process

Content curation

  • Recover some good old posts
  • Mention why it worth to be reconsidered
  • Provide new thoughts

 

Seguramente os habréis dado cuenta de dos cosas:

  1. I, me, personally… creo que lo mejor es escribir desde un tono personal. Es donde me siento más cómoda, desde donde puedo ser más honesta, aportar una opinión diferente y desde donde nadie podrá acusarme de intentar darle lecciones. Y ya de paso me quito de un plumazo el tan temido síndrome del impostor. Para todo lo demás hay muy buena literatura muy bien editada.
  2. A veces escribo en inglés otras en castellano y otras lo mezclo todo. También me parece algo natural para los hispanoparlantes en el sector tecnológico. No creo que nadie se asuste a estas alturas por esto ni por mis faltas de ortografía atención tipográfica.

 

Otra cosa que quiero intentar en esta ocasión es no darme prisa en publicar. No voy a mantener una agenda porque no lo he conseguido hacer ni para las cosas más importantes de mi vida, pero básicamente intentaré mantener cierta frecuencia de publicaciones. Para eso tendré en la cola siempre dos o tres entradas.

Espero que con esto pueda darle una nueva vida al blog y aprender de vuestros comentarios mientras comparto algo de mi experiencia.

Y ¿vosotros? ¿cuál es vuestra estrategia de publicación de contenidos?

Eventos y conferencias

Parece que la primavera trae consigo un periodo intenso de alergias y de concentración de eventos, meetups y conferencias profesionales. Desde hace cinco semanas tres de ellas han ocupado gran parte de mi tiempo, me gustaría compartir lo que he aprendido como organizadora, asistente y colaboradora.

Women Techmakers

El Women Techmakers tuvo lugar en Málaga el 1 de abril, en el Rayo Verde. Esta iniciativa de Google organizada por los grupos de desarrollo locales GDG se celebra todos los años con motivo del día de la mujer. Ésta es la segunda edición en la que Yes We Tech participa en la organización.

Lo mejor

  • 50/50 de participación y gran apoyo de la comunidad
  • Conocer nuevas mujeres que hacen tecnología en Málaga
  • Ponencias de excelencia que merecen aún más visibilidad, más tiempo y recursos
  • Colaboración entre comunidades tecnológicas locales

Lo peor

  • El formato irregular de las charlas hace difícil mantener el ritmo
  • El Rayo Verde no sirve para hacer un evento tan largo (ya que no permite el almuerzo dentro de sus instalaciones)
  • Algunas personas aún menosprecian el valor del evento y de tener una audiencia y ponentes profesionales

UX Spain

UX Spain es el encuentro de profesionales de la Experiencia de Usuario más importante de España. En esta edición reunión a unos 500 participantes y se quedaron en la lista de espera casi tantos como los que pudimos asistir. El UX Spain de 2017 se celebró el 12 y 13 de Mayo en Gijón.

Lo mejor

  • El encuentro, la gente, las ponencias… todo de 10 como siempre
  • Descubrir a alguien que no sabías ni que existía haciendo cosas alucinantes
  • La premisa de la organización de que debe haber paridad entre los ponentes
  • Saber con qué se están peleando el resto del país en temas de UX, dejando a un lado el hype

Lo peor

  • Las ciudad de Gijón tiene una malísima combinación de viaje
  • El centro de Gijón no estaba demasiado cerca del Palacio de Congresos
  • El derroche de testosterona de algún ponente demasiado encantado de conocerse

J On The Beach

J On The Beach es el evento tecnológico por excelencia en Málaga y se centra en temas de Big Data, IoT, DevOps, JVM, programación funcional y visualización de datos. Tuvo lugar en La Térmica el pasado 17-19 de Mayo. Yes We Tech formó parte del comité organizativo y celebramos un meetup durante las conferencias.

Lo mejor

  • Estar cerca de la gente que cuida su carrera profesional, que cree en Málaga como ciudad de innovación, que aporta y quiere aprender
  • Los ponentes y las ponencias de un nivel estratosférico
  • Una de las mejores organizaciones que he visto nunca desde la perspectiva de la experiencia del asistente: impecable
  • Es un encuentro internacional celebrado en una ciudad sin complejos
  • Conocer nuevamente a mujeres de otros países con ganas de dar caña a una red Yes We Tech global
  • El proyecto a modo hackathon que presentamos para Yes We Tech y el apoyo de nuestro core :_)

Lo peor

  • Los fallos técnicos que desmerecen a los ponentes al retrasar o desfavorecer sus charlas, fueron pocos pero los hubo
  • Los comentarios o salidas de tono de algún tío que aún no se da cuenta que a nadie le interesa sus complejos machirulos
  • La falta de coordinación para poder descansar y disfrutar del evento desde la organización, acabamos todos exhaustos física y mentalmente.
  • Las realidades de algunas empresas malagueñas que aún tratan a sus empleados y empleadas de forma desconfiada

Conclusiones

En las últimas semanas he dedicado mucho tiempo personal en formar parte de la comunidad profesional, siempre es enriquecedor por quién llegas a conocer, por cómo puedes ayudar a otros y otras a relacionarse, a aprender y a hacer networking. Sin embargo, hace falta una pausa para reflexionar y volver a lo básico, a las raíces, y sobre todo para no agotarse.

En temas de igualdad hay luces y sombras y mucho que hacer. En esta especie de burbuja de los eventos donde tus oportunidades laborales y profesionales parecen depender tan claramente de a quién conozcas y por dónde te dejes caer es más importante que nunca que las mujeres estemos aquí. También me hace reflexionar si no estaremos contribuyendo a una desigual forma de acceder a puestos de trabajo.

Por otra parte, como co-organizadora creo que si el equipo no comparte 100% unos valores básicos sobre la identidad y el saber-hacer del evento, se corre riesgo de implosión. Me gustaría que el próximo evento que co-organice empiece precisamente por poner en común estas ideas.

Por ahora volveré a nuestros modestos meetups a los que estáis todas y todos invitados y en los que espero poder reforzar el core de Yes We Tech para que la comunidad se sienta más cerca que nunca.

Optimismo sin reservas

No he triunfado. No importa. Recuerdo que cuando estudiaba, cuando entrenaba, cuando me preparaba para afrontar retos, lo que me hacía sentir capaz no era el miedo a no dar la talla, ni el ser consciente de las dificultades del proceso, sino el desafío del esfuerzo.

Soy una convencida de que las mejores cosas que te da la vida requieren esfuerzo. Por eso, cuando pienso en qué cosas desalientan a la gente para superarse a si mismos, para atreverse con una u otra carrera profesional o proyecto, para arriesgar el corazón en una batida no está el miedo al fracaso, sino la pasión misma por vivirlo.

No, quienes actuáis con condescendencia no tenéis razón, solamente erráis en lo más básico: nadie espera alimentar su motivación con las frustraciones de otro.

Dejad de dar consejos y empezad a aceptar que por los demás lo más sensato es construir colectivamente. O quedaos solos. 

Adiós a la competencia del incompetente, así como a la irresponsabilidad del responsable. A partir de ahora me limito a no dar consejos, a hacer lo que tiene sentido, a ofrecer un rato de conversación sobre cómo podemos dejar de preocuparnos por triunfar y empezar a sentirnos orgullosos.

Pasen y vean, empezamos desde abajo.

Always solving the same problem: data model vs mental model


Information design is one of the most interesting fields to me that relates with the User Experience. How users perceive and understand the information based on what we show them and how they interact with it, it is like trying to create a language that goes beyond the interface and the standards. It is challenging and, sometimes, uncertain.

However the other day I had a déja vu while one of my mates was sharing a research made on an data analysis use case. Suddenly I felt I’ve been solving the same problem of information design over the last three years.

We talked about how raw data becomes information, and how there should be another data that represents the meaning of that information, and how past events may affect to current indicators or not. We talked about the visualization of multiple charts were the only way to understand some concepts, and how users should decide the events and configuration to provide real meaning beyond the data values.

I’m not going to enter into specifics on that use case, but the problem that reminds me the same kind of question was the one that I worked for years: the Electronic Patient Record (EPR).

In an EPR there are some information which indicates current health status: vital signs. This can tell you if you’re alive, getting better or getting worse. It is also a clue to start investigating what made you feel bad.

That’s one level of information based on data collected directly from a person. Of course you can collect more data like a blood test or a urine test or similar.

Another level of information is just the history of every visit to your doctor. All of them with symptoms, diagnosis, and treatments. Those events could be related between them by episodes (let’s say a flu, a pregnancy, a surgery…) and, in a different level, related by the diagnosis of an illness (let’s say cancer, diabetes, etc.).

The problem you have is that you need to navigate information from different layers based on different levels of the data abstraction. And you want to find correlations, make differential analysis and causations at any level, because you don’t really know what’s the cause of the problem.

What I thought it was similar is that when we model the problem, we have to provide meaning to the data abstraction and that requires an understanding of the user mental model (In my case how doctors research on data).

Another leg of this problem is how users can interact with the data to find how it is related. We cannot solve everything with a static picture of the data.

Last, but not least, we needed to represent very clearly what is the data in a relevant present (24hours, 7 days,…) and what belongs to the history, and how history is explored and contrasted with present data.

 

Somehow I felt the problem was always the same, and the only thing that makes it different is the kind of person who typically interacts and uses the data. So the solution should start to understand his/her mental model and define the model of the data meaning based on them, instead of the defining the data model of the system that is meant to represent it.