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?

Wearing a wereable

Hace un mes me compré un (nuevo) smartwatch. – En realidad iba a ser un regalo, pero como siempre me pasa, acabó siendo un autoregalo y una promesa de un regalo mejor).

El modelo es el LG G Buddy en negro con Android Wear, algo muy básico que conseguí por 99€, un precio razonable para experimentar. – Sí ya sé, vaya birria de regalo, qué le vamos a hacer…

Por sus características, es un reloj que debe estar conectado por Bluetooth a mi móvil Android, y cargarse cada 3-4 días de uso. No me parece demasiado grande para mi muñeca, ni con un estilo demasiado marcado, ni pesa mucho. Creo que es cómodo como cualquier otro reloj y cumple mínimo las dos funciones básicas que debe tener:

  1. Da la hora
  2. Puedes ponértelo en la otra muñeca si quieres acordarte de algo

La experiencia de la tecnología llevable

El uso que le he dado al reloj ha sido un uso cotidiano. No me he atrevido a llevarlo mientras hacía deporte, no me parecía tan apropiado para eso a pesar de que es resistente al agua. El caso es que me resulta bastante incómodo cualquier tipo de pantalla que no tenga botones físicos. Uso un Polar, antes de eso usaba el Nike+ Sportwatch y antes de eso mi iPod de 3º generación. Cuando corro me resulta más cómodo presionar, que tocar o deslizar el dedo mientras estoy en movimiento y esperar que la interfaz reaccione.

Sin embargo, para el día a día, mientras trabajo o hago mi vida fuera de casa, lo tengo conectado con mi móvil tanto como la batería de éste me lo permite.

El reloj es un reproductor de notifcaciones el 90% del tiempo, un acceso rápido a contestar a esas notificaciones un 5% y el otro 5% es ese desconocido que te encontrarías en un ascensor que te hablaría del tiempo, del tráfico y además te chivaría lo poco o mucho que te has movido ese día.

Éste último 5% es todo mérito de Google Now (y Google Fit), que me encanta y creo que entiende muy bien el contexto y la información relativa al usuario. Fuera de bromas, creo que llevarlo en la muñeca es mucho más oportuno que en el móvil.

Sobre el exceso de notificaciones podría decirse que ‘ahorra tiempo’ si no se acumulan. Si lo hacen ya no puedes previsualizarlas en el reloj pero sí en el móvil. Es cómodo porque es discreto, puedo estar todo el día moviéndome por la casa o la oficina, dejar mi móvil en el bolso y enterarme de si alguien me está hablando por alguna red social o por mail mirando rápidamente la muñeca sin interrumpir ninguna conversación ‘en directo’.

En el coche también es útil, pero peligroso. Recibir un mensaje y poder contestarlo hablándole a tu reloj como en el coche fantástico es más seguro que intentar hacerlo manipulando el móvil. Aún así, hay que irse con cuidado.

En general este uso de receptor o canalizador de notificaciones para que resulte útil te convierte en un poco esclavo, como ya lo hace el móvil. Cuanto más quieres que te comunique, más inoportuno o estresante se convierte.

Las reacciones de la gente han sido curiosas. No se puede negar que tiene un toque moderno, techie o frikie. El diseño de cada skin para el reloj es divertida y ‘chanante’. Los smartwatch molan porque aún no está muy extendido.

Finalmente un uso curioso es mientras trabajo con el ordenador (entro 8h-10h al día), escucho música en Spotify (4-5h al día) y me da por saltar una canción desde el reloj. ¡No sirve para nada porque falla! Si bien salta la canción, parece que el móvil recibe la interacción y entiende que debe ser él el reproductor, así que paso de escuchar música por mis cascos a compartirla con quien haya en la habitación. Absurdo e incómodo porque tienes que cerrar la app en el reloj para que no te moleste.


Llevar un wereable es, en mi opinión, algo que me resulta de lo más natural y útil según qué contextos. Cuando hago deporte no puedo vivir sin mi reloj, cuando estoy en casa no me resulta interesante a no ser que pudiera verlo conectado a otros dispositivos o electrodomésticos, y en el trabajo me funciona bastante bien cuando realmente me muevo de mi puesto (en reuniones, en la mesa de algún/a compañero/a, etc.)

No descarto comprar algo mejor en el futuro, seguramente con WiFi y con mejor diseño. Pero como siempre, lo que vale de un reloj son sus aplicaciones y sus servicios. Es imprescindible que estén adaptados a contextos de uso reales y útiles. Seguro que Apple vende millones de relojes estas navidades, pero está en nosotros/as, creadores de productos digitales, aprovechar la oportunidad para construir soluciones que sirvan para algo más que para recibir notificaciones.

No seamos como consumidores y usuarios sólo el producto de la industria, no nos convirtamos sólo en ‘donantes de datos’, seamos capaces de aprovechar la naturalidad de la tecnología llevable, vestible, ponible y portable, para ofrecer algo distinto, para percibir algo evolucionado.

Más allá de la moda y el diseño, los wereables se convertirán en la tecnología que nos ayude a ampliar nuestros sentidos de la forma más natural y menos disruptiva.

Trabajemos para conseguirlo.

Insider

Me gusta la ingeniería, me gusta pensar en procesos y metodologías como forma de coordinar el esfuerzo de un equipo de gente con perfiles diferentes para sacar el mejor producto viable. Cerebro y músculo con objetivos comunes. Como me gusta, disfruto del proceso, más cuando la repercusión del beneficio al finalizarlo no está siempre clara.

Creo que pensar en procesos y metodología forma parte de cualquier ingeniero y también de cualquier persona dedicada a la Experiencia de Usuario (incluso en equipos de un sólo miembro).

De la ingeniería también me gustaba programar, sobre todo cuando era una tarea sencilla, cuando no tenía que salir del shell para hacer cosas chulas, o cuando trabajaba con entornos de desarrollo completos. Cuando el lenguaje que usaba no requería de aprender una serie de cosas inútiles porque no estaba bien pensado para el propósito o arquitectura sobre el que se desplegaría.

Me gustan las cosas sencillas, es decir no me gustan las cosas innecesariamente complicadas por complejas que sean.

Ya sea porque soy ingeniera o me he pasado la vida rodeada de frikies amantes de la tecnología, me gusta conocer las novedades en tecnología que hay en el mercado o en investigación. Me gustan los prototipos, las ideas nuevas y el impacto que ésto tiene en la sociedad.

Y me gusta formar parte de esto como creadora, pensadora, desarrolladora y diseñadora. Por eso pienso que forma parte de mi preparación fundamental mantener siempre la visión más amplia posible en la creación de productos tecnológicos.

Sin embargo, durante varias etapas de mi carrera desde que me matriculara en la factultad en 2001, me he ido encontrando con una serie de mensajes contradictorios de quienes creen estar ahí para enseñarte algo, a saber:

  1. Si no eres un amante del cacharreo no eres informático, pero si no sabes nada sobre matemáticas puedes ser lo que quieras.
  2. Aprender tecnologías frontend, desarrollo web o diseño de interfaz es algo accesorio, pero trabajar en un desarrollo y no tener dorma de que lo utilice un humano es secundario.
  3. Los diseñadores tenemos que aprender a programar, pero no podemos dar nuestra opinión sobre tecnología.
  4. En los negocios la seguridad en uno mismo es importante, pero ojo, lo que para unos es muestra de pasión para otros es muestra de cabezonería.
  5. Las habilidades sociales y emocionales son imprescindibles, a no ser que seas muy crack que se te disculpará todo y podrás tener a un equipo entero envenenado.
  6. A tus empleados, estudiantes, compañeros hay que criticarles siempre para que aprendan, eso sí, el refuerzo positivo será siempre virtual en forma de notas o sueldo, si ninguna de estas cosas llegan allá cada uno con sus frustraciones.

Como decía, me gusta mi profesión, aunque a veces te invadan las dudas, las dudas de otros.

Interfaz de línea de comandos: ¿un paradigma poco popular?

Han pasado ya unas cuantas semanas desde que empecé en mi nuevo trabajo y tenía muchas ganas de hablar de unos cuántos temas que han ido surgiendo durante todo este tiempo.

Uno de los que más interés me está causando, debido a su estrecha relación con la Interacción Persona-Ordenador (HCI) es el de las Interfaces de Línea de Comandos (CLI) y lo usable (o no) de su diseño.

No es éste un tema habitual ya que, usualmente, todo lo que tiene que ver con la Usabilidad y Experiencia de Usuario se termina ligando inevitablemente a las Interfaces Gráficas de Usuario (GUI) ya sean web, móviles, de escritorio u otras superficies. Lo cierto es que, desde que la metáfora visual se utiliza como representación del modelo de comunicación entre personas y computadores, la necesidad de diseñar estas interfaces de una forma eficiente para su uso se convierte en una obligación.

¿Pero qué ocurre con las CLI? ¿Se les puede aplicar criterios cualitativos de usabilidad? Más allá de los estándares que ya existen ¿representa la línea de comandos un paradigma relegado a un modelo de uso en declive o poco popular?

Haciendo un poco de investigación me topé con algunos recursos interesantes que me sorprendieron.

El primero que recomiendo es este libro: Build Awesome Command-Line Applications in Ruby 2: Control Your Computer, Simplify Your Life

Claramente destinado a programadores de interfaces de comandos pero con un enfoque muy serio en cuanto al respeto hacia los estándares para desarrollar algo suficientemente familiar. En el libro se destacan varias ideas en su introducción y conclusión:

  • Las CLI están focalizadas a scripting.
  • Las CLI no suelen utilizarse para el trabajo final, sino como recurso.
  • Las CLI son un white canvas (con los problemas de usabilidad inherentes que eso conlleve).

Pero por el contrario

  • Las GUI son interfaces muy difíciles de automatizar.
  • Las GUI no son interfaces fácilmente portables.

Quiero referenciar también el post que encontré en Biko que, curiosamente, trata el aspecto gráfico o visual de las CLI para hablar sobre UX. Sin faltarle razón creo que es un tema en el que se puede profundizar hacia muchos más aspectos.

Otro interesantísimo recurso que encontré fue este artículo escrito por Florian Cramer y Kamen Nedev que me parece simplemente imprescindible: Poética de la línea de comandos donde ejemplifica la diferencia entre los dos paradigmas de una forma muy sencilla:

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.

[…] O, también, el paradigma Lego de un juguete auto-definido frente al paradigma Playmobil de un juguete predefinido.

Finalmente, me gustaría incluir algunos ejemplos de interfaces que, si bien no son líneas de comandos clásicas orientadas a usuarios administradores de sistemas, sí hacen uso del lenguaje natural en formato textual para interaccionar con los usuarios.

Seguramente haya muchos más ejemplos, si conoces alguno te animo a que los compartas conmigo.

Una última reflexión que me surge es sobre la necesidad/oportunidad de evolucionar las CLI para que aprovechen mejor el factor de forma de algunos dispositivos móviles como Blackberry (que se niega a morir). A fin de cuentas aún hay millones de usuarios que se comunican y se entienden con mensajes de menos de 140 caracteres.

Google podría considerar otra interfaz más de comandos.

El diseño móvil como parte de la experiencia: la importancia del contexto.

El diseño móvil como parte de la experiencia: la importancia del contexto.

Google Design como recurso de aprendizaje

Si hay un recurso web que considero imprescindible tanto si deseas desarrollar algo para móviles como si sólo quieres aprender algo útil sobre diseño o programación es el portal de la plataforma Android.

Ya en el pasado enlacé alguna de sus buenas prácticas dirigidas a desarrolladores, pero no hay duda de que en este portal hay muchos más recursos útiles. Y es que, en general, las guías de estilo de las diferentes plataformas nos enseñan mucho más que directivas, sino los principios fundamentales de diseño en los que se basan los nuevos paradigmas de interacción y experiencia de usuario desde la capa visual hasta la construcción de la arquitectura.

En este caso Android, en sus secciones de Design, Development y Distribute, estructura unos contenidos valiosísimos para apreciar los detalles y los conceptos básicos con los que trabajar cuando te enfrentas a un desarrollo móvil (o casi de cualquier tipo si sabes abstraerte bien).

Si aún no has navegado por su web donde fundamentan las bases del lenguaje visual Material Design, te recomiendo que empieces por ahí ya que éste puede aplicarse a cualquier plataforma y detalla con infinidad de ejemplos múltiples principios de diseño.

Igualmente importante es la sección de estilo y patrones, la sección de training de desarrollo y los contenidos esenciales sobre la distribución de apps.

A veces me parece necesario no acumular demasiada cantidad de recursos, webs, libros, etc. para poder focalizarte en una sola cosa, sencilla, directa y bien estructurada sobre todo cuando el objetivo es aprender. La documentación de Android en este caso es un ‘gustazo’ no como la de iOS que en mi opinión sólo usa la verborrea para destacar de forma inconsistente y desestructurada algunos de sus iluminados principios de diseño. Pero quién soy yo para criticar al gran Ive o a su equipo…

Creo que mi apuesta queda bastante clara, más aún viendo cómo de bien le sientan los años a Android y lo bien que está madurando. Prueba de ello es la reciente salida de Android Studio 1.0, que pasó de la beta recientemente y se presenta como un entorno de desarrollo completo el cual espero trastear en profundidad en breve.

Innovar buscando la perfección

Dick Fosbury

Como mucha gente sabe hace más de 60 años el atleta estadounidense Dick Fosbury revolucionó la técnica de salto de altura haciendo algo que nunca antes nadie había hecho: pasar por encima del listón de espaldas.

Esta idea original le hizo ganar unos juegos olímpicos estableciendo un nuevo récord mundial en los 2m 24cm. Él sabía que, a pesar de no ser el atleta mejor dotado de su generación y de las mofas de sus compañeros de instituto, su técnica innovadora le podía llevar al éxito.

Fosbury, quien no se sentía cómodo afrontando el listón de frente y no terminaba de adaptarse a las técnicas clásicas, tuvo no sólo que crear una nueva idea transgesora sino que pasó meses y meses poniéndola en práctica y mejorándola totalmente en solitario hasta que pudo demostrarle al mundo, en una competición de máximo nivel, que efectivamente había mejorado todas las marcas.

Mientras Fosbury practicaba sólo, los más cercanos a él sabían de sus intenciones de probar suerte en el campeonato que le dio su primer oro. Hoy en día nadie duda de que la suya es la mejor técnica de salto de altura para competición. Lo curioso es que las técnicas anteriores tales como rodillo ventral aún se usan aún durante los entrenamientos para entender la mecánica del cuerpo y la clave más importante del salto: la necesidad de levantar la cadera.

Para el atleta, su triunfo no venía por ganar muchos oros en los subsiguientes campeonatos, seguramente porque sabía, entre otras cosas, que su físico no era el más talentoso y que pronto otros atletas más potentes le copiarían su nueva técnica. Sin embargo sabía que su objetivo primordial era el de conseguir el mejor salto posible.

Toda esta suma de cosas, toda esta historia que parece desconexa me ha hecho siempre reflexionar sobre la necesidades personales de innovación y especialización.

En el caso de este gran saltador de altura innovar le llevó a sentar un precedente, a ser el mejor (por un tiempo) pero sobre todo a demostrar que no era necesario afrontar la barrera como todo el mundo solía hacerlo para superarla de forma más óptima.

Por otra parte cuando por fin la asumió como una idea posible fue cuando decidió llevarla a la perfección buscando el máximo rendimiento, optimizando el giro de su cuerpo, el arco de su espalda, el levantamiento de los brazos y todo aquel gesto que contribuía a la superación del listón.

La necesidad de una alternativa a causa de una limitación propia disparó la idea creativa. La práctica resultó necesaria para convertir su idea  en innovadora. Y de ésta se sentó una base para el desarrollo de una nueva técnica.

Albert Einstein dijo

La creatividad nace de la angustia, como el día nace de la noche oscura… En tiempos de crisis la creatividad, supera el conocimiento.

Ésto es algo que bien sabe Fosbury y que a modo de tópico escuchamos mucho aunque no queramos oírlo. La crisis personales, que no tienen por qué ser la económicas, ponen a prueba el tipo de ser innovador que somos.

Mi pregunta es ¿estamos dispuestos a reconocernos como tales o queremos seguir dejando que todas las barreras nos parezcan inalcanzables?

Y si encontramos una idea mejor ¿tenemos miedo a no ser los más talentosos para sacarle el máximo rendimiento? ¿A caso importa esto para innovar?

Nota final: otro pequeño gran detalle que contribuyó a este atrevimiento fue el de colocar un colchón tras el listón en lugar de un montón de arena. Lo que demostraba que era valiente, pero no un loco, lo último que un atleta busca es una lesión que le aparte de su objetivo. Hagan ustedes la sobrelectura del simil.

Sobre los conceptos

Vivimos una profesión cargada de términos y matices que, reconozcámoslo, a veces se hacen imposibles de definir sin invadir la semántica de otros tantos.

Cuando trato de explicar algunos de estos términos me dejo llevar por una simplificación radical:

  • Usabilidad significa Testing.
  • Diseño centrado en el usuario significa User Research.
  • Experiencia de usuario significa Transformar.
  • Diseño de Interacción es Comunicación.

Podré estar más o menos acertada, pero a veces resulta vital ser así de contundente ya que en las empresas ‘tochas’ que buscan constantemente afinar con sus procesos hay preguntas recurrentes en lo que a los departamentos de User Experience se refiere:

  • ¿Estamos haciendo las cosas bien?
  • ¿Son nuestros productos usables?
  • ¿Hemos adoptado las prácticas del DCU?
  • ¿Es esta la UX que espero para mis productos?
  • ¿Están mis diseñadores añadiendo valor?
  • Etc. etc.

La respuesta a esas preguntas se torna fácil y franca: ¿conoces a tus usuarios? ¿estás tomando decisiones en base a ese conocimiento? ¿pueden decirte si estás acertando con la solución? ¿has influenciado para bien en su uso y relación con la tecnología? ¿tu equipo de UX es el mejor canal entre Producto, Desarrollo y Usuarios?

Por otra parte hay indicadores que nos pueden ayudar a saber cómo de cerca o lejos estamos de convertir estas cuestiones en realidades. Nuevamente, en un afán muy simplista, suelo ver a ciertos ‘roles’ como aliados que, si dejaran de serlo, nos pondrían las cosas muy difíciles:

  • Márketing y Ventas.
  • Desarrollo y Arquitectura.
  • Product Ownership y Project Management.

Ésto es sólo una opinión (la mía), pero recuerda:

Si te incomoda, es arte.