Será sonoro

Tenía dieciocho años menos, dieciocho kilos menos y probablemente dieciocho canas menos. Pero en ciertas cosas —no muchas— pensaba igual que pienso ahora.

Un 21 de septiembre publiqué un post titulado “Una apología del sonido en las interfaces web” y ¿sabes qué pasó? Que me cayeron tortas por todos lados: “¡pero qué tontería es esa!” “Menuda chorrada”, “la gente no quiere que la web sea una feria de sonidos”… Aquí está la prueba y aquí el enlace al artículo completo:

 Desde entonces, se me quedó una espinita clavada. La realidad probó mi hipótesis, el iPhone trajo las apps, con ellas vinieron los sonidos y ya no se van a ir.

Sin embargo, ese dolorcillo se mantuvo hasta que conocí a Javier Suárez Quirós. De poco sirven las complicidades si no se converten en conspiraciones, así que decidimos convertir todas esas intuiciones y observaciones en un plan. El objetivo era incorporar el diseño de lo acústico en los productos digitales (su sonificación), en la formación de todo diseñador de interacción que pasase por el Instituto. Lo hicimos, tímidamente con algunas charlas, después con un programa técnico, un curso para BBVA y con un módulo en el programa de diseño de interacción.

Pero cuando uno siente que tiene una verdad luminosa entre las manos, no puede quedarse sin compartirla. Lo presencial no es suficiente, tenemos que conseguir que esos conceptos lleguen a más personas, no sólo a quienes puede pisar la sede de Goya 27 en Madrid.

Antes de vacaciones decidimos que Enfoques.net, nuestra plataforma de cursos en video, podría servir. Al fin y al cabo, por el momento vemos la sonificación como una herramienta al servicio de quien diseña y quizás todavía no como una especialización. Esa es la esencia de esos cursos en video.

El curso está ya en el horno y este es el trailer que lo explica. A ver qué te parece:

Nuestro reto es triple: ser capaces de profundizar, conectar conocimientos con práctica y contagiar. Nuestro convencimiento es uno: el diseño de interacción de dentro de unos años será sonoro. Puede que hasta sea, en muchos casos, únicamente sonoro. Y de nada valdrán los conocimientos de UX actuales sin entender esa dimensión, igual que de nada valieron los conocimientos de arquitectura de información previos al iphone si no se entendía la dimensión interactiva de las apps y lo táctil.

Apuesto a que en tu entorno ya has percibido cómo lo sonoro empieza a importar, quizás discretamente o de maneras no intencionadas. Si es así, me hará ilusión que compartas esas impresiones en los comentarios.

Tengo la intuición de que este es un cambio que pocos vemos llegar y que esta vez no faltan dieciocho años.

Metaverso, lo inmersivo y lo emersivo

La idea de hacer la compra en el metaverso empujando un carrito hace más aguas que la nao Victoria en la Expo 92; sí, la que se hundió nada más se botada y casi acaba con la vida de Curro. Naufraga por dos motivos, veamos:

El primero: es un caso de efecto retrovisor McLuhaniano (usar tecnologías nuevas para afrontar retos viejos) de libro. Nos dan una tecnología que plantea escenarios completamente innovadores y a alguien se le ocurre usarla no sólo para algo ya resuelto, sino para resolverlo IMITANDO exactamente cómo se hace en el mundo real, con todos sus defectos. Es decir, confudiendo simulación con inmersión. Un clásico.

Mítin de Gaspar Llamazares en Second Life. Parecía una buena idea.

Vayamos con el segundo motivo, un error más común pero ojo, menos evidente. Lo explico con un ejemplo real:

Hace unos años, cuando Oculus sacó sus primeras gafas y Google empezó a promover sus gafas de VR hechas de cartón, aparecieron algunas empresas de consultoría de realidad virtual. El CEO de una de ellas me dijo en una ocasión que perdíamos el tiempo diseñando apps, porque en poco tiempo el correo electrónico lo despacharíamos virtualmente, pues todo el trabajo ‘ofimático’ que hacemos hoy en día (excels, presentaciones, correos electrónicos, etc.) se haría de forma virtual. Poco tiempo después, empresas como aquella malvivían haciendo demos en ferias de turismo.

Esta persona, quizás sobreentusiasmada con su propia tecnología, no entendió una cosa: hay experiencias que reclaman y demandan más inmersividad, pero hay otras que cuanta menos, mejor. En otras palabras, yo no quiero un email virtual, yo quiero poder resolver los mensajes sin siquiera mover un dedo, mientras me ducho o conduzco, gastando el mínimo de energía mental. El email es una tecnología que no quiere ser inmersiva, sino emersiva (por usar el antónimo). No me quiero meter en ella, quiero sacarla de mí. Y lo mismo pasa con hacer la compra en remoto (otra cosa es ir al mercado a comprar, mucho más senssorial y consciente, ojo).

Cómo hacemos que una tecnología sea ‘emersiva’

¿Cómo hacemos que una tecnología sea ‘emersiva’? Pues reduciendo su coste cognitivo al mínimo:

  • automatizando todo lo automatizable

  • minimizando la cantidad de interfaz

  • evitando los comandos y lenguajes específicos

  • haciendo que sea simultaneable con otras tareas

  • haciéndolo ubícuo e independiente del dispositivo

En el caso del correo electrónico, las autorespuestas y los filtros de spam son un paso, pero todos sabemos que el mejor cliente de correo será el que incorpore Alexa con su capacidad de procesar lenguaje natural. Ese día, cuando podamos contestar un mensaje en la ducha con un dile que lo apunte y lo vemos en la reunión del martes. Ah, y pregúntale que qué tal su Navidad, entonces habremos hecho un email más emersivo y, por tanto, mucho mejor.

A nadie se le ocurre hacer una interfaz virtual para la domótica del hogar, ¿verdad? Imagina tener que encender y apagar luces con las gafas y los guantes. Subir o bajar la persiana, encender una lámpara o encender la TV deberían parecerse a la magia; los comandos de voz son un avance, pero sería aún mejor, más eficiente y cómodo, poder hacerlo con un gesto de la mirada, levantando una ceja o con un sutil movimiento de la mano, que son comandos con mucha información cuando el receptor conoce tus códigos.

Habrá quien se pregunte qué usos, funciones, problemas o necesidades deben ser inmersivos y cuáles emersivos; cuál es el criterio de triaje de experiencias, cuáles van a una caja y cuáles a la otra?

La cosa se complica ahí, pero hay algunos criterios que pueden ayudarnos a decidir. Tareas tediosas y repetitivas, tecnologías que son medio y no fin… Casi todo lo que tiene que ver con finanzas, gestión o comunicación, mejor cuanto menos inmersivo.

Y qué demanda inmersividad

¿Y al revés? ¿Qué necesidades podemos resolver mejor desde la inmersividad? Partamos de tres axiomas del diseño emocional y la inmersividad:

  1. Sólo recordamos aquellas vivencias que nos han provocado una respuesta emocional.

  2. Al grabar una vivencia en el recuerdo, grabamos también el registro sensorial de la vivencia.

  3. Las experiencias inmersivas logran su intensidad desde la sensorialidad: apelan más fuerte a más de un sentido.

Está claro entonces, ¿no? Merece más la pena hacer inmersivas aquellas experiencias que tengan connotaciones emocionales, sean de ficción o no.

Las de ficción son obvias y el mundo del videojuego, que va veinte años por delante del diseño de interacción convencional, lo ha demostrado ya. En esos casos, lo virtual es ambas: simulación e inmersión. Y cuando ambas coinciden en coherencia, ocurre algo mágico en ficción: la suspensión de la incredulidad, el ingrediente imprescindible para que aceptemos como verdad, aunque sea por unos instantes, lo que en la realidad no contemplamos.

¿Y cuáles son las de no-ficción? Caben muchas respuestas ahí, dependiendo del sistema de valores en el que nos situemos como diseñadores, pues el diseño es cultura, especialmente cuando decide qué problemas y necesidades resolver y cuáles pasar a un segundo plano.

Propongo tres ejemplos y que cada uno decida con cuál se siente más representado:

Familia: mediante un sistema de altavoces y micrófonos, reproducimos el espacio acústico del salón de casa en el de casa de mi madre y viceversa, de modo que ella siente a sus nietos alrededor, los oye con altísima fidelidad, y ellos la oyen a ella, como sie estuviese sentada en el sofá con ellos. El sistema está activo toda la tarde y, aunque ella viva a seiscientos kilómetros, gracias a la realidad aumentada acústicamente, nos sentimos al lado.

Comunidad: ancianas de pueblos semi-abandonados de una comarca de Teruel se encuentran en el metaverso para habalar de sus cosas y recordar otros tiempos, ahora que su movilidad está reducida y el centro de salud donde se encontraban está cerrado.

Nostalgia y morbo: mediante imagen y sonido revivimos épocas de nuestro pasaado de las que ya hay suficientes registros digitales. Eliges un día de tu vida y lo vuelves a vivir, o incluso vives la de otra persona. La idea no es nueva, me suena de algún capítulo de Black Mirror. Pensando a futuro, quizás sirviese para revivir la vida de alguien de la familia o para que algún famoso se lucrase permitiendo que nos metiéramos en su piel y viviésemos lo que él vive.

Publicidad: nuestro proveedor de acceso al metaverso (o a la realidad modificada) nos hace un descuento por aceptar product placement constante. Nuestras amistades llevan zapatillas Nike y en la barra del bar está George Clooney tomándose un Nespresso.

Simulacro: los filtros que nos mejoraban el aspecto en Instagram van más allá, previo pago: hacen cancelación selectiva de sonido (fuera ruido de coches, fuera sonidos estridentes o incluso que todo suene con ‘skins’ acústicos que le den un toque u otro a la realidad). Yendo más allá, permiten “mutear” a ciertas personas o que cuando se hable de ciertos temas, suba o baje el volúmen de la voz de quien los emite.

Los ejemplos son infinitos y aplican a todos los ámbitos, más allá de los clichés de la educación, la cirugía y las que ya han anticipado multitud de series y películas (probablemente las que yo sugiero sean de esas sin yo saberlo).

Ficciones y futuribles aparte, el ejercicio más valioso a corto plazo para cualquier persona de diseño o producto digital está en entender que algunas necesidades mejoran con inmersividad y otras con lo contrario pues tan importante e innovador es lo inmersivo como lo emersivo, aunque lo segundo logre menos titulares.

Sobre el Diseñador de Desarrollo

Ayer, en una de las cartas del newsletter De Ulm a Cádiz, donde publico ideas y vivencias que tienen que ver con la creación del Instituto Tramontana, propuse un rol intermedio entre el diseñador y el desarrollador. Lo llamé Diseñador de Desarrollo, haciendo la analogía con el arquitecto de obra clásico, el que supervisa y ajusta, pero no necesariamente proyecta.

Creo que esa figura podría responder al problema eterno de las diferencias (a menudo déficits) entre lo que se define cuando se conceptualiza y diseña y lo que se acaba desarrollando, cuando surgen problemas, limitaciones (de tiempo o tecnológicas) o malas interpretaciones.

El rol del arquitecto de obra lo describí así:

El rol del arquitecto de obra, el que no proyecta, sino que supervisa y se encarga de aportar soluciones sobre la marcha cuando aparecen contratiempos (un material no llega, unos cálculos estaban mal) para que la obra no pare. Ese arquitecto, no siendo dueño intelectual del diseño, es su garante, pero desde el realismo: se encarga de que el resultado sea lo más fiel a lo proyectado dentro de las circunstancias y con los medios que se den.

Y mi propuesta para un diseñador de desarrollo la enuncié así:

El rol del Diseñador de Desarrollo, si me permitís el bautizo, tendría dos partes:

La primera sería interiorizar el trabajo de diseño previo, la naturaleza y propósito del negocio y del proyecto, la lógica de todas las funcionalidades y procesos, la consistencia de la solución a lo largo de todas las pantallas y la esencia de todas las armonías, la estética y los elementos comunicacionales, artísticos y demás. En esa parte, el diseñador de desarrollo (DD) habría estado desde el inicio, escuchando y empapándose.

En la segunda parte, el DD acompañaría a los desarrolladores (de front y back) en todo el proceso, explicando, aclarando, corrigiendo diseño cuando surgen cambios, diseñando elementos o pantallas nuevas y —esto es lo más importante— haciendo ajustes cuando por tiempo, coste o circunstancias hay que simplificar la complejidad de diseño en algún punto y facilitar la tarea de desarrollo.


La idea ha dado que hablar bastante, he recibido unos cuantos mensajes con experiencias y comentarios sobre el tema, tanto por email como en Twitter.

El comentario más generalizado ha sido que no habría que crear un rol específico, que se trata de que la persona de diseño y la de desarrollo hablen más, que haya diálogo y estén ambos involucrados desde el principio. Este hilo de Carlos Hernández ilustra bastante bien algunas de las reacciones:

Captura de pantalla 2019-08-23 a las 12.40.39.png

Carlos apunta en su hilo a algo que no puedo negar. Es obvio que la comunicación es importante y que es bueno que ambos roles sepan de lo que hace el otro. Pero no creo que con buena voluntad se resuelva un problema que es estructural. Trataré de describir unos escenarios muy comunes en proyectos que tienen cierta entidad, para que se entienda la dificultad —a veces imposibilidad— de comunicación entre equipos de diseño y desarrollo:

Diferentes empresas

A menudo la empresa que hace diseño no es la que desarrolla. Esto puede pasar porque el cliente ha elegido a una empresa especializada en diseño y luego el trabajo de desarrollo lo hace internamente. Yo mismo he diseñado y dirigido equipos de diseño para clientes que han trabajado así. En esos casos puedes reservar tiempo para acompañar a desarrollo, pero la realidad es que no tienes facilidad para tener a personas de tu equipo físicamente al lado de otras de otra empresa que trabaja desde su propia oficina.

Diferentes tiempos

A menudo se hace el diseño y no se sabe cuándo se implementará el desarrollo. Cuando se trabaja en modo consultoría, es importante tener a las personas asignadas a proyectos con la mayor antelación posible. Si el diseño se hace entre enero y marzo y el desarrollo se sabe que se hará entre abril y junio por otra empresa distinta, ¿Cómo demonios puedo reservar yo tiempo de alguien que debería estar en esos días en otro proyecto para que acompañe al equipo de desarrollo asistiéndole constantemente?

Diferentes ubicaciones

A lo anterior sumemos cuando el diseño se hace, por ejemplo, en Madrid y el desarrollo en Bilbao o en Argentina. En esos casos, el acompañamiento y la asistencia, en el mejor de los casos, se queda en unas videoconferencias rápidas, a menudo incómodas, para resolver dudas.

Lo cierto es que en muchísimos casos concurren esos tres escenarios. De hecho, cuanto mayor es el proyecto, más probable es que concurran: proyectos con equipos deslocalizados que trabajan de forma asíncrona y hasta en idiomas diferentes. ¿De verdad creemos que la buena voluntad y el espíritu de comunicación van a ser suficientes para asistir a desarrollo cuando se encuentre dificultades con los diseños?

Como en todo, la buena voluntad y la actitud son importantes, pero a medida que los sistemas humanos se vuelven complejos, tenemos que convertir lo deseable en legal, trasladar los buenos hábitos en leyes y normas y asignar tiempo y personas a ello. Por eso, a partir de cierto tamaño, creo que un proyecto debería tener un Diseñador de Desarrollo.

Un par de aclaraciones:

  • Estoy hablando de la creación de productos digitales desde consultoría, como proveedores a un cliente, no como equipos internos.

  • Esto tiene sentido para proyectos medios-grandes, con planificaciones relativamente complejas y equipos numerosos, donde se trocea el trabajo. En proyectos sencillos obviamente no aplica.

  • Que haya un DD no quiere decir que los diseñadores no deban saber de tecnología o que en la fase de concepto inicial no deba haber gente técnica. Ojo, lo aclaro antes de que se me tiren al cuello. Eso me parece una MAG-NI-FI-CA práctica. Pero lo uno no quita a lo otro, porque por mucho que sepan de programación o sistemas los diseñadores, habrá contratiempos, habrá cambios, habrá imprevistos.

En la carta propongo que el Instituto Tramontana hospede un evento, mitad encuentro de debate mitad curso, donde quienes saben de esto puedan aportar sus puntos de vista, puedan enseñar y entre todos podamos reflexionar sobre el tema y quizás hacer cambios en el modo en que trabajamos y proveemos diseño. ¿Qué os parece?

La foto es de una de las obras en las que ha trabajado Jara. Aquí más fotos suyas.

La foto es de una de las obras en las que ha trabajado Jara. Aquí más fotos suyas.

Retórica para diseñadores

El lenguaje tiene un ancho de banda muy limitado para la amplitud y complejidad de los conceptos que podemos llegar a crear en nuestra mente. Y sin embargo, en demasiadas ocasiones es nuestro único instrumento para trasladar una idea, unos conceptos, un diseño a la realidad.

Pensémoslo, casi todas las disciplinas creadoras tienen su propio sistema de notación estandarizado: la música tiene las partituras, la arquitectura tiene los planos, el diseño industrial tiene también sistemas de planos estandarizados, la ingeniería informática tiene sistemas de diagramas (y el código)… Pero el diseño de interacción no. No tenemos una forma estandarizada y abstracta de contar algo con precisión y en toda su complejidad sin tener que construir un prototipo, sin tener que hacer el trabajo casi entero.

En este video del canal de Tramontana (de hace unos meses) me marco yo solito un buen monólogo al respecto:

Sonetos sobre sistemas de diseño

O la historia de cómo y por qué los miembros del Programa Vostok acabaron escribiendo poesía sobre la racionalización del diseño. Eso y los siete sonetos, incluido el de un poeta muy reconocido.

Una lectura poética que transcurrió entre la racionalidad de Ulm y la emoción de Cádiz.

Una lectura poética que transcurrió entre la racionalidad de Ulm y la emoción de Cádiz.

¿Limita la creatividad un sistema de diseño? ¿Hasta qué punto condiciona el contenido y la capacidad narrativa? ¿Es deshumanizante? ¿deja lugar para la emoción y la sorpresa? Estábamos debatiendo eso mismo el Programa Vostok cuando Juan Morales hizo una pregunta que nos dejó a todos en la duda:

– ¿Un soneto es un sistema de diseño?

Según la wikipedia:

Un soneto es una composición poética compuesta por catorce versos de arte mayor, endecasílabos en su forma clásica.1 Los versos se organizan en cuatro estrofas: dos cuartetos (estrofas de cuatro versos) y dos tercetos (estrofas de tres versos).

En efecto, es un conjunto de normas acerca de forma, estructura y relaciones entre partes. Además tiene recursividad, simetrías y armonías formales, ¿verdad?

No hizo falta decirlo, todos lo estábamos imaginando en nuestras cabezas… La mejor forma de entender la relación entre norma y contenido, entre estructura poética y mensaje, era precisamente escribir uno. Y ya que estábamos en faena… ¿por qué no escribirlo precisamente sobre sistemas de diseño?.

Una semana después, entre sorbos de Amontillado viejo y luz de atardecer, tras una magnífica clase impartida por Jesús Terrés, leímos y escuchamos nuestros poemas que, con gusto, hoy compartimos aquí:

 

Dejando de lado todos los clichés,
dando la cara a un problema pactado,
libre como un pájaro anillado,
un temple heredado estilo japonés.

Cuidando la forma campo a través,
siendo fiel y obviando lo obviado,
podrás caminar sobre cimentado,
con el orgullo de un viejo guardés.

Solamente queda tener cuidado,
no dejes a nadie jugar con él.
Pequeño Fabergé acorazado.

Puede que sea algo zarandeado,
que se sobreescriba como el papel.
Pequeño Fabergé adulterado.

María Moreno


Tan sencillo y tan honesto que parece
un lenguaje extremo por naturaleza,
en su exceso reside la belleza,
pues a reglas y normas obedece.

A cientos de miles enloquece,
se les sube un poco a la cabeza,
transforman su obviedad en mi pereza,
dudemos si tanto lo merece.

Sometido a una eficiencia recursiva,
Neutral, escalable, multifuncional,
enemigo íntimo de la narrativa.

La sorpresa a veces no está mal.
No lo usemos de forma abusiva,
dejemos hueco a lo emocional.

Isabella de Cuppis


DOCTRINA

Un buen diseño no es un chamuyo,
porque los programadores tienen un gran dote
ya que siempre se rompen el marote
y por eso nunca me lo atribuyo.

Utilizando un sistema les instruyo
que como buen método necesita un garrote
pero como jamás hago uso de mi chicote
siempre termino y se los retribuyo.

A veces la idea se vuelve fulera,
pero ojo, ellos nunca me atacan
ni aunque el trabajo les demoliera.

Al buen resultado se lo achacan
y no quiero parecer una simple mechera,
al gran sistema que machacan.

 

Nicolás Amateis

GLOSARIO: chamuyo: (lunfardo) Hablar o escribir con intención persuasiva, sin argumentos sólidos. Marote: (lunfardo) Cabeza de una persona. Inteligencia, capacidad de entender. Chicote: Látigo (azote). En América. Fulera: (lunfardo) Que es chapucero o poco útil. Mechera: (lunfardo) Mujer que roba en las tiendas.


 

Luces en capsulas encarceladas,
hijas del orden y la sumisión,
mas desconocen la satisfacción
de sentirse empoderadas.

Y es así, como esa falsa quimera
de narrativa y belleza,
nos muestra con vergüenza
su naturaleza primera.

¡Oh sentimiento evocador!
sin ti andan desnudas y vacías
las luces a tu alrededor.

El equilibrio suena delicado,
pero en él se haya el reto
de humanizar lo frío, lo helado.

Laura Caro Navarro


 

Ponemos todo nuestro empeño
en las lecciones de Javier
Cuando, diligente, nos hace aprender
maravillosos sistemas de diseño

¿Cuántas veces tendré que repetir
la horrible aplicación de la alergia
para que mi querido Pedro y su sinergia
entiendan que lo que me gusta es vivir?

Locuacidad, cultura y pasión
hacen que este feliz y manso rebaño
pongan cada viernes todo su tesón

En comprender lecciones que antaño
dominábamos cual Maradona el balón
mientras llega el final del año…

Xabier Mauleón


 

Las normas de un sistema de diseño
debería de cumplir un soneto
para querer tener vuestro respeto
más allá de debatir con empeño.

Neutral y eficiente en su desempeño,
la sílaba forma el buey del cuarteto,
la rima hace predecible al terceto
ensamblando palabras como enseño.

Si los de Ulm dicen de abrir la mente
para que enriquezcamos el debate,
el dejarse llevar es sorprendente.

Intenta olvidar el escaparate,
busquemos secuencias precisamente.
Aspirar a narrar no es disparate.

Juan Morales


 

Como regalo final, dejamos aquí el que hizo José Luis Morales, padre de Juan y poeta, que se interesó por el tema y se animó a hacer uno. Imaginad el privilegio: José Luis tiene obra publicada y gran reconocimiento, ostenta los premios de poesía José Hierro, el Blas de Otero, el Miguel Hernández o el Rafal Morales, entre otros. Aquí va su pieza, en referencia y guiño a Un soneto me manda hacer Violante, de Lope de Vega:
 

Un soneto me manda hacer Cañada
que tenga las diez reglas del diseño:
que sea funcional(1), neutral(2) y dueño
de unidad(3), predecible(4) y modulada

su estructura(5), escalable(6) y, de pasada,
eficiente(7), geométrico(8) y tan dueño
de todo que, tras él, cualquier empeño
se someta(9) a su ley, aquí enunciada.

Alguna regla falta, estoy seguro,
pues sólo dos cuartetos he empleado
y me quedan tres versos para el sello.

Las cuento, las recuento — vaya apuro,
tengo nueve y aún no he terminado — ;
por poco se me olvida: ¡que sea bello(10)!

José Luis Morales

 

Poder compartir algo así con y entre los alumnos, esa apertura de corazón y de mente, hablar de diseño sabiendo que hablamos de lo divino y lo humano, de lo útil que no es bello y de lo bello que por serlo deja de ser inútil, bailar los proyectos que tenemos entre manos entre dos mil años de referencias tecnoloógicas, culturales, políticas, religiosas o económicas para volver a aterrizarlos en el momento actual… Pocas veces he disfrutado tanto y le he visto tanto sentido a lo que hacemos.

Una historia de sistemas de diseño (Parte II)

Este post es la continuación de Una historia de sistemas de diseño (parte I). Te recomiendo leer el anterior para que te de contexto, antes de continuar.

Había pasado una semana de la charla de Wences en el UXSpain y yo seguía acordándome de los ejemplos que dio, que se mezclaban con mis propios recuerdos del inicio de internet. Pero, ¿de qué habló Wences que tuvo ese efecto en mi? ¿Qué contó?

Wences Sanz recordó la web de los inicios, en la que las páginas estaban hechas a mano, con mucho cariño y oficio. Recordó las sensaciones que le producía recorrer algunos sites en los que había sorpresas en cada rincón, donde el mensaje estaba por encima de las reglas o la estructura. Habló de la web de Space Jam, de Kaliber10000 y de lo emocionante que era descubir y recorrer los rincones, las formas variadas, las sorpresas, los guiños y las habitaciones de todas aquellas webs.

Captura de la web de Space Jam, todavía online.

Captura de la web de Space Jam, todavía online.

A medida que hablaba yo me acordaba de algunos juegos de mi Spectrum, de cómo aquellos limitadísimos 48k podían crear mundos tan inmersivos de los que no queríamos salir, en los que siempre había territorios que descubrir. Eso era… Wences estaba hablando de las primeras webs como si fueran juegos, webs en las que sumergirse o perderse y disfrutar descubriendo los regalos que había escondidos en cada rincón…

Mientras Wences hablaba yo me daba cuenta de que todo estaba en los nombres ¡Y ni siquiera nos habíamos fijado! Los visores de html se llamaron Netscape Navigator e Internet Explorer. Navegar y explorar, porque la web era un lugar de descubrimiento, de sorpresa y hasta un poco de aventura. Era terra incognita.

 

El timon, la navegación, las cartas navales, lo desconocido.

El timon, la navegación, las cartas navales, lo desconocido.


¿En qué momento la web dejó de ser así? ¿Por qué dejamos de hacer páginas como aquellas? Las preguntas que Wences hacía dejaron a la audiencia en silencio, tanto que se podía escuchar su respiración desde el otro lado del auditorio.

¿Habrían sido las plantillas, o quizás los sistemas, los que ayudando a producir más fácil y rápido, habrían aplanado esa magia del viejo internet? ¿Habríamos matado la web con la producción en masa de templates, módulos, widgets y componentes?

Su charla fue breve, con más preguntas que respuestas. No fue –y le agradezco la humildad en eso– una reflexión intelectual, sino vivencial.

Al final de la charla yo tenía una certeza: quería que esa charla, esa reflexión, la conociese mi equipo en Tramontana. Todo lo demás eran ideas y conceptos que no sabía aún cómo digerir.

Fue, como dije antes, una piedrecilla que golpea el parabrisas del coche. Clack! Una marca. Y unos días después una grieta. Yo llevaba casi diez años diseñando sistemas y defendiendo su uso. Abogando por la belleza de su geometricidad, por la recursividad y la optimización, por la lógica, la previsibilidad y la escalabilidad de los sistemas de diseño bien pensados.

Creía en los sistemas pero no quería ser un diseñador de ‘cosas’ sin alma.

Ha pasado casi un año de esa conferencia y unas pocas semanas desde que Wences tuvo el detalle de impartirla de nuevo en Tramontana. En este tiempo creo que he encajado las piezas. Por lo menos la grieta del parabrisas se ha desvanecido y vuelvo a ver con claridad; que no todo sigue en su sitio –porque una buena idea te cambia y te marea un poquito mientras no seas un testarudo– y que creo que he aprendido y mejorado mi visión sobre los sistemas de diseño.

¿Qué he aprendido exactamente? Pues para lo que NO SIRVEN los sistemas, lo que no nos dan, su mayor limitación:

 

Los sistemas de diseño no sirven para estructuras narrativas o inmersivas.

 

De hecho, las matan. Son anti-narrativos, apisonadores. Dejadme explicar esto por partes, que aunque parezca una perogrullada, creo que tiene miga.

Todo lo que Wences recordaba de la vieja web era precisamente lo maravilloso de los universos narrativos: la capacidad de sumergirnos en una realidad paralela, con sorpresas, emociones, descubrimiento…

No me entendáis mal, no quiero soltar el rollo del storytelling que todos hemos escuchado alguna vez. Hablo de narrativa, pero no sólo la de las películas o los libros. Narrativa es también una aventura conversacional en un juego (como la que hemos hecho para BNE) o el diseño de un jardín romántico como el del Cármen de los Mártires en Granada (recorredlo y lo entenderéis), el proceso de unboxing de algunos productos o el onboarding de una app.

La buena narrativa tiene algunas características comunes. ¿Son compatibles con los sistemas de diseño? Por definición no. Veamos en qué difieren:

 

1. LA NARRATIVA SE APOYA EN PERSONAJES, LOS SISTEMAS SON IMPERSONALES.

Las evocaciones necesitan siempre darnos un punto de vista subjetivo. Se construye un personaje y ese personaje nos da una visión del mundo, de su mundo. Batman y su Gotham de crimen, el viejito de UP y su mundo deshunmanizado del que quiere huir porque ya no vive su amada, Inception y la agonía de Cobb…

Los sistemas de diseño, por el contrario, son estructuras diseñadas desde lo impersonal. No son subjetivos sino todo lo contrario. No son la visión de una persona sino la formulación que acomoda al mayor número de personas posible. No tienen carácter, no están amargados ni son perezosos, no tienen cultura, raza o momento vital. Son constructos sin lugar ni momento. Buscan esa belleza, esa universalidad de lo que ha funcionado siempre y en cualquier lugar.

 

2. LA BUENA NARRATIVA CONSTRUYE UNIVERSOS EVOCADORES, LOS SISTEMAS SON SILENCIOSOS.

Trata de recordar cualquier historia, juego, lugar que tengas en la cabeza. Si lo has recordado es porque en algo te transportó, te evocó cosas. El punto de partida de una buena historia es que aceptemos entrar en su universo imaginario, lleno de color, con una luz, unos sonidos, unas texturas y una temperatura.

Los sistemas de diseño, por lo contrario, buscan ser invisibles y silenciosos, no manifestarse, ser neutros. Un buen sistema de diseño deja que el contenido o la función se manifiesten pasando él desapercibido. Es blancura y transparencia, no tiene olor, luz, textura… No es sensorial. Es la nada.

 

3. LAS BUENA NARRATIVA TIENE RITMOS, LOS SISTEMAS SON ESTÁTICOS.

Las historias son itinerarios con diferentes ritmos y aceleraciones. Hay momentos en los que se detienen en los detalles y otros en los que se vuelven trepidantes con acción que ocurre a gran velocidad. En el ritmo está parte de su capacidad de transmitirnos cosas, de evitar monotonía. Piensa, por ejemplo, en lo que se veías cuando eras niño o niña desde la ventanilla del coche en un viaje. Era mucho mejor se veían cosas diferentes, cuando cambiaba el paisaje. O piensa en el modo en que algunas películas juegan con la cámara rápida o lenta en cómo la música acelera o decelera escenas. El ritmo es primordial en la narrativa.

Los sistemas son monotonos. Pueden proponer recursividades y plantear ritmos visuales entre sus partes, pero eso no les da ritmo narrativo. En el mejor de los casos, tenderán a ser de ritmos constantes, como el sonido de los travesaños al ir en tren: tac-tac, tac-tac… Monótono y repetitivo.

 

4. LA BUENA NARRATIVA TIENE SORPRESA Y MISTERIO, LOS SISTEMAS SON PREVISIBLES.

Lo inesperado, lo desconocido tras un fundido a negro, un giro de guión que cambia la naturaleza de los personajes o un ‘deus ex machina’ son recursos de la narrativa para sorprendernos. Y en esa sorpresa está el entretenimiento.

Los buenos sistemas, sin embargo, necesitan ser previsibles para funcionar bien. Es una de las normas básicas: en su previsibilidad está su utilidad: hacen que todo sea esperable en forma y consiguen ser fáciles de proyectar para diseñadores ajenos a ellos, también ser intuitivos para los usuarios. Su clave es la repetición de patrones, tamaños, proporciones, medidas… No hay lugar para la sorpresa en la lógica de un buen sistema de diseño. De hecho, no sólo deben ser previsibles, sino que son normativos: necesitan reglas y normas que se cumplan siempre.

 

5. LA NARRATIVA EXISTE EN EL PLANO TEMPORAL, LOS SISTEMAS EN EL ESPACIAL.

Para contar algo necesitas contenido y tiempo, que las cosas pasen una detrás de otra, en la secuencia que hayas diseñado. La historia existe independientemente del soporte. Se puede contar casi lo mismo con una secuencia de fotos, con una sinfonía o con un paseo por la costa. Lo que importa es qué se evoca y en qué orden.

El sistema de diseño se manifiesta siempre en lo espacial. Puede cambiar el soporte (papel, pantalla, lo físico…) pero sin soporte no es nada. Existe allá donde haya soporte, existe en lo material y lo espacial.

 

6. LA NARRATIVA NECESITA FINALES, LOS SISTEMAS NECESITAN NO TENERLOS.

Una historia no lo es sin un final. Es una sucesión de eventos que terminan en un final del que extraemos una serie de valores o emociones. Final feliz, triste, estimulante o final a la imaginación del receptor, pero final siempre. Si no hay final, la narrativa está inconclusa.

Un sistema de diseño bien hecho está pensado para crecer indefinidamente. En su lógica se definen no sólo las piezas sino la manera en que se relacionan entre ellas para permitir el crecimiento infinito. Un sistema de diseño que tuviese topes se quedaría pequeño pronto. La escalabilidad es uno de los objetivos más importantes del sistema, su capacidad de crecer y crecer sin perder fuerza.

¿Qué quiero decir? ¿Qué conclusión se saca? ¿Qué aplicación tiene todo esto?

Pues una muy sencilla: diseñar es definir la forma adecuada, la relación entre función y contenido para un usuario, un contexto y a menudo un dispositivo concretos.Ese ejercicio suele necesitar que moldeemos algunos mensajes, que marquemos secuencias, que evoquemos sensaciones… Los sistemas son un buen mecanismo para definir la forma pero no la secuencia.

¿Se puede hacer narrativa usando sistemas? Pues quizás sí, pero son siempre un limitador. O dicho de otro modo, se puede hacer narrativa y luego encajonarla y normativizar su presentación para que nos quepa en el sistema.

En otras palabras, los sistemas de diseño son instrumentos asombrosos y necesarios para el buen diseño, pero no son ‘el diseño’. Son sólo una parte:

Son contenedor, no contenido.
Son una estantería, no un libro.
Son un macetero, no flores.
Son armarios, no ropa.
Son urbanismo, no peatones.

Y qué triste sería ser diseñador si sólo creásemos sistemas.

"Me gusta" no es un argumento de diseño

“Me gusta” no es un argumento de diseño. Lo diga un cliente, un alumno, un diseñador de mi equipo o yo mismo. Sea un proyecto de pocos euros o de muchos miles. Hablemos de un proceso complejo, una secuencia narrativa o el color de un botón.

Quienes han trabajado conmigo lo saben: no tengo miedo de interrumpir a un cliente si le escucho algo así. Lo haré con educación, desde luego, pero lo haré las veces que haga falta.

¿Que por qué esa dureza?

En el momento que aceptamos un “me gusta” como argumento estamos abriendo la puerta a la subjetividad. Ya juzgamos en base a opiniones, a percepciones y a pálpitos. En ese momento todo ha cambiado, ya no eres el especialista, ya no eres el médico que prescribe un remedio ni el ingeniero que proyecta en base a cálculos. Ahora eres un tipo con una opinión frente a otro con otra, que además paga la cuenta. Ya no diseñas. Ahora eres un pintamonas y nada más.

En el momento que aceptas un me gusta como argumento de diseño te has puesto al servicio de la opinión de quien paga la cuenta. Ya no haces diseño. Ahora eres un pintamonas.

No estoy diciendo que todas las decisiones de un diseñador sean objetivas, ni mucho menos. Digo que debemos reducir la subjetividad todo lo posible.Obviamente estamos condicionados por influencias conscientes e inconscientes, por lo que sabemos hacer y por lo que nos seduce. Es difícil librarse de eso. Por eso se dice que el diseñador debe dejar su ego de lado. Lo que importa no es su preferencia sino la solución óptima al problema.

A diferencia del cliente, el diseñador debe entender el problema desde muchos ángulos distintos: debe entenderlo visualmente, secuencialmente…Debe comprender las partes del problema y encajarlas con una solución que también se divide en partes. En esas partes el diseñador debe buscar eficiencia, efectividad, consistencia, coherencia, armonía y belleza. Y en la búsqueda debe haber simulado mentalmente (o en el cuaderno) docenas de alternativas que ha descartado, como cuando un maestro de ajedrez simula partidas en su cabeza y descarta movimientos hasta dar con el bueno. Todo eso no lo hace el cliente (ni un grupo de cocreación, pero esa es otra conversación).

Para poder pensar así, hace falta construir sobre certezas: entender todo lo posible acerca del usuario y del contexto y su relación con el propósito (la función, el problema a resolver). Cada paso, cada caja, cada píxel debe poder apoyarse en una certeza. Donde no haya una certeza habrá siempre especulación, habrá un “a mi me parece” o un “a mi me gusta” y el tuyo valdrá menos que el de tu cliente.

El me mola, el me gusta y lo que es guay es entendible en un junior. Al fin y al cabo acaba de empezar y no ha entendido que las modas y las tendencias pasan; sacian como sacia un pastelito industrial, dulce, sí, pero que nos deja más gordos y peor alimentados.

Nuestro trabajo es fruto de unas técnicas para entender un problema y otras para solucionarlo. Nuestras soluciones son visuales pero también estructurales y secuenciales. Buscamos entender la complejidad del problema para dar con la solución que mejor encaja con ella. Nuestras formulaciones no gustan, son adecuadas. No molan, son óptimas. No son guays, son efectivas. Somos diseñadores, no trendsetters o influencers.

¿Focus Groups?

Podría empezar suave pero voy a decir lo que quiero decir de golpe y luego lo explico: los focus group son una técnica de investigación nefasta. Deberías evitarla a toda costa si pretendes hacer buen diseño.

Y ahora que lo he dicho, lo voy a razonar.

A menudo se habla del Focus Group como una técnica de investigación de usuario, una práctica que nos sirve para conocer más acerca de los usuarios de un producto, su contexto y su relación con el producto (o la función que busque cumplir). A diferencia de las entrevistas o la observación contextual, en el focus group no sólo se saca al usuario de contexto, sino que además se le hace interactuar con otros en una especie de conversación guiada en la que el investigador espera obtener información. La premisa es que esa interacción entre usuarios hará que aflore más información.

Nada más alejado de la realidad. Esa interacción entre usuarios, ese diálogo es precisamente lo que corromperá, distorsionará y sesgará toda la información que realmente necesitas para tomar decisiones. 

Antes de que alguien me ataque diciendo que es que no tengo ni idea, diré que sí, que he leído mucho sobre focus groups, que he estudiado mucha metodología de investigación social en la universidad y que también tengo experiencia práctica en empresa: ayudé a conducir bastantes cuando era junior y conduje yo bastantes más después. Experiencia no me falta. 

Pero ¿Por qué son nefastos los focus groups?

Los problemas más grandes de un Focus Group están precisamente en su naturaleza, en la interacción entre las personas de las que quieres obtener información. Un focus group crea un contexto que condiciona brutalmente el comportamiento de las personas. De repente, al entrar en una sala con otras que no conocen, a las personas les preocupa más la interacción con los demás que la transparencia. Cosas que ocurren en un focus group:

Dinámicas de poder

Hay gente que busca dominar el grupo, imponer sus puntos de vista y coaccionar a los demás para que les apoyen. Esa gente hará que pases más tiempo moderando que obteniendo información. Lo puedes suplir con observadores auxiliares, pero lo cierto es que cuando tienes a un perfil dominante (y siempre lo tienes), es como cuando cae lejía en el agua. Muere la vida.

Búsqueda de aprobación

Hay gente que busca aprobación y dirá lo que crea que le hará lucir mejor, ser aceptado, ante ti o ante los demás. Y no podrás hacer nada por arreglarlo. No ante el grupo. Usuario perdido.

Timidez o introversión

Hay gente tímida o introvertida que aunque tenga información, no participará. El grupo sólo acrecenta su situación. Serán usuarios valiosos desperdiciados.

Interrupciones

Hay gente que interrumpe, que no respeta el turno de palabra, que supone un coste mayor que el beneficio. Incomodarán a otros, estropearán el flujo natural de la sesión, te fastidiarán el guión… Te pisotearán todo lo que pueda nacer en ese jardín.

Vergüenza

Hay gente que en público siente vergüenza de reconocer cosas (incompetencia o errores con una app, por ejemplo) que sí reconocería en una entrevista cara a cara. Nos pasa a todos. Ciertas cosas sólo se confiesan en la intimidad o en confianza. Usuario perdido.

Mala verbalización

Hay gente que no sabe expresarse, no es buena verbalizando, aunque tenga muy buena información. Esto no es sólo un inconveniente de los focus groups, cierto, pero en un FC añade distorsión extra a la conversación que esté teniendo lugar.

En fin...

Los focus groups tienen muchos inconvenientes y muy pocos beneficios. En realidad ninguno, no nos engañemos. Pueden parecer una forma rápida de obtener información pero requieren mucho trabajo de agenda y organización. Sí, te van a dar fotos y frases chulas que poner en un powerpoint de investigador mierdecillas, pero si quieres ser ese user researcher, eso también te lo dan las entrevistas. Por cierto, las frases “chulas” se llaman verbatim. Si vas a perder el tiempo, que parezca que dominas el lenguaje.

Ya en serio, si vas a trabajar con usuarios te recomiendo la observación contextual y/o las entrevistas uno a uno. Sacarás muchísima más información, crearás un clima de confianza con el usuario mucho mejor en el que se sincerará, te expresará dudas y te hará entender mejor su contexto y motivaciones... Hazme caso,  no busques en un grupo mejor información de la que sacarás de cada uno de sus individuos por separado.

 

El único focus group que me gustaría conducir.

El único focus group que me gustaría conducir.

Un cisma trágico

Me acuerdo muy bien de esos años, mis primeros en Madrid. Trabajaba en la mejor oficina posible, en Calle Alcalá 21, octava planta. Imaginad las vistas. Empezábamos a pedir cosas a Amazon UK, AOL entraba en España con un ordenador medio tonto apodado el ‘Paquito’ y las torres gemelas acababan de caer, igual que Teknoland, los únicos que podían hacernos sombra a nosotros, el equipo de HCI de IconMedialab; la élite escandinava que iba a cambiar la web, los que entraban antes que nadie en los proyectos. Nadie pintaba nada sin que antes hubiéramos hecho… los wireframes. Por algo éramos HCI. Human-Computer Interaction, así, en inglés y con todas las letras.

IMG_0961.PNG

 Al principio tenía sentido

La web de aquellos años era sólo comunicación: papel, folletos, pósters y catálogos. La diseñaban ‘directores de arte’, un perfil heredado de las agencias de comunicación y publicidad clásicas. Nosotros, los de HCI, los ‘Arquitectos de Información’ entramos aportando algo más. Éramos humanistas, veníamos del periodismo, la biblioteconomía, la sociología o la psicología: entendíamos al usuario, lo estudiábamos, y nos hacíamos cargo de definir lo que él quería: la función.

No trabajábamos con color ni con fotos ni siquiera iconos. Nos sentíamos libres de la esclavitud de lo estético. ¿Qué digo? ¡Si hasta lo despreciábamos! Nuestro lenguaje era más estructural, era arquitectónico: planos, líneas, posiciones… Árboles de contenidos y wireframes.

Al cliente se lo explicábamos así: “Primero entramos nosotros y definimos la función. Usaremos cajas grises para que podamos hablar sin que usted se distraiga por lo estético”. Cuando eso esté acordado, ya otros ‘pintarán las pantallas’. Así, tal cual, con estas palabras.

En ese momento tenía sentido. Nuestros clientes eran marketing, estaban acostumbrados a opinar sobre piezas de comunicación hechas por directores de arte. Pero nosotros estábamos empezando a diseñar otras cosas más complejas y funcionales: intranets, algo de e-commerce y los inicios de la banca online. Marketing mandaba sobre los presupuestos de internet y estaba acostumbrado a juzgar con la vista. Teníamos que cambiar eso. Con los wireframes centrábamos las decisiones en función y evitábamos que una foto, un color o una ilustración despistasen a nuestro cliente y vetase una interacción bien definida.

Con el tiempo, nuestros entregables -ojo al termino- crecieron igual que crecía internet. La web de ‘quiénes somos, dónde estamos’ se había convertido en un portal de inversión online. Los doce wireframes ahora eran un documento hecho en Visio, Powerpoint o Freehand con 300 layouts en gris, titulares y mucho lorem ipsum.

 

Y se nos fue de las manos

En 2005 ya habíamos tomado el control por completo. El golpe de estado estaba consolidado y los analistas funcionales no pintaban nada. Nosotros, los arquitectos de información, mandábamos. The Cocktail estaba empezando: Knapp, Furilo y yo. Empezamos a tener a diseñadores pero ya no les llamábamos directores de arte sino ‘visuales’. Tener a gente llamando a su trabajo ‘arte’ era una distorsión. Visual era mejor que arte. Si pintabas píxeles eras bienvenido, siempre y cuando quedase clara la jerarquía: nosotros definíamos, los demás ejecutaban.

No había proyecto que no tuviera doscientas páginas de cajas grises. Nos seguían poniendo cachondos los entregables. Wireframes con encuadernación de espiral gruesa, pósters con árboles de contenidos infinitos a tamaño A0, facturas de copistería que no bajaban de cien euros.

Dos meses de cajas grises y otros dos de ponerlo en colores. A 60€ la hora, echad cuentas. En otras palabras: ¡Cha-ching!

Y no sólo era The Cocktail, ya eran todas. Se había consolidado una forma de hacer: primero los wireframes, después el visual.

 

Pero… ¿Pudimos superarlo?

Algunos años antes, unos pocos empezamos a llamarnos ‘diseñadores de interacción’. recuerdo leer a Henry Dreyfuss y a Otl Aicher y empezar a entender que lo que hacíamos era más que arquitectura de información. Mucho más. Era una forma de diseño, igual que el de producto lo era a los bienes tangibles o la arquitectura lo era a los inmuebles.Entendimos que la función necesitaba ser expresada por la forma, y que si no dominábamos la forma seríamos meros analistas funcionales con mentalidad pro-usuario.

Nos interesamos por el color, el uso del tamaño, los ritmos, la relación entre forma y emoción, y entre emoción y percepción. Rams, Gugelot, Nagamachi y su ingeniería Kansei. Estábamos plantando una pica en el funcionalismo, otra en la percepción de la belleza y la tercera en los principios estructurales que podían conectarlo todo. Éramos capaces de definir forma y función sin separarlas. Por fin nos sentíamos séniors, con la serenidad que da saber que pisas suelo firme.

Esa seguridad, con los clientes y en los proyectos, nos permitía simular escenarios en nuestra cabeza mucho mejor que antes: proyectar las posibles alternativas a diseñar en nuestra mente, como un jugador de ajedrez visualiza movimientos, y decidir pintando apenas cuatro garabatos en un cuaderno.

Sabíamos que nuestros enunciados tenían espacio, tiempo y forma. El color, las sombras, los tamaños, las posiciones, las fotografías, los iconos y sus significados, eran todo información. Como las narrativas pictóricas de Neurath o el wayfinding de Mijksenaar. Usábamos estructura y forma, conceptual con visual, para crear más señal y menos ruido. Hacíamos mejor nuestro trabajo. Era completo.

 

Mientras tanto, en las empresas y las academias…

A pesar de que nuestra forma de entender el diseño es más completa, las empresas (la mayoría) se han mantenido cómodas vendiendo UX y visual como piezas separadas, o lo que es lo mismo, wireframes por un lado y pantallas por otro.

Con el incremento del negocio online, la necesidad de profesionales de diseño de interacción se ha multiplicado (a lo bestia). Si en 2005 Cadius podía juntar a treinta personas, hoy el UXSpain -congreso de referencia en nuestra profesión- junta a quinientos especialistas sin apenas hacer publicidad. Ahora mismo debe haber unas mil personas en toda España definiendo apps, webs y otros artificios interactivos. Y no son suficientes. La industria pide más desesperadamente.

A falta de suficiente oferta formativa, las agencias, consultoras y estudios han sido quienes han nutrido al sector de profesionales, contratando juniors que aprendían trabajando. Y lo han hecho siguiendo la fórmula que les resultaba más rentable: separando lo estructural/funcional de lo visual. Llamando a unos UX y a otros ‘visuales’. ¿Por qué lo han hecho así? Por dos motivos:

1. Beneficios: es mucho más rentable vender dos meses de UX junto con otros dos de visual que vender tres de buen diseño que combine ambas cosas.

2. Velocidad: es mucho más sencillo y rápido formar a alguien que componga cajas grises que a un diseñador de interacción completo. Además, hay más oferta de perfiles potencialmente convertibles a UX. Al fin y al cabo, sólo hace falta que sepan completar el entregable conforme a las convenciones del momento. Qué más da lo que hayan estudiado.

 

La cosa se retuerce

Fijaos en lo perverso del asunto: hacia afuera damos la imagen de un sector sin paro, donde se pagan sueldos aceptables y donde los profesionales generan un tipo de documento relativamente ‘fácil’ de producir, sin mucho conocimiento técnico: el wireframe. Si eres alguien que busca trabajo y ves esto desde fuera, lo lógico es que quieras aprender justo eso para poder entrar.

Y si eres una empresa de formación que prima beneficio sobre prestigio (la mayoría), lo lógico es que sepas aprovechar esa circunstancia. No tienes que ofrecer formación completa de diseño. Basta con que enseñes a tus alumnos lo básico de la toma de requisitos, de contexto de uso y de plasmar las ideas en wireframes. Un plus si se vuelven interactivos con inVision, Axure o la herramienta de moda. Eso, adaptarles a la necesidad empresarial del momento, la que separa UX de ‘los visuales’. Obviamente, las academias más oportunistas sabrán sacar mejor partido y tener otro master para formar a gente ‘de visual’. El negocio es redondo, ¿Por qué desaprovecharlo?

 

¿A dónde nos ha llevado todo esto?

Fuera paños calientes: tenemos un sector lleno de profesionales entrenados para producir cajas grises, pero incapaces de entender el diseño en su profundidad formal, que no saben ni pueden usar la mitad de las herramientas que deberían. Podría decir que son diseñadores a medio hacer, pero creo que es más grave: son profesionales profundamente discapacitados.La metáfora es dura pero creo que válida: viven en una especie de oscuridad respecto a la realidad. Donde un buen diseñador ve cuatro dimensiones y millones de matices a través de todos los sentidos, ellos ven un mundo plano, sin profundidad. Donde un diseñador completo ve colores, sabores, olores o sonidos, ellos ven gris, insípido, inerte.

Pensad que esta división del trabajo la paga también la otra mitad, los ‘visuales’ que salen de escuelas de diseño donde prima la moda, lo que se lleva. Entran al sector como decoradores, sin que nadie les cuente los por qué’s de las cosas y se acostumbran a ello. Puede ser cómodo pero además es rápido. “Ponme esto bonito” es su orden de trabajo. Son el maquillador, la esteticien o el túnel de lavado de un negocio del que no serán parte ni influencia, porque ni entienden ni manejan los motivos, los por qués.

 

Bastardos profesionales

Formar a perfiles para encajarlos en la cadena de montaje del supuesto ‘diseño centrado en el usuario’, haciendo sólo wireframes, tiene consecuencias nefastas. Es matar su sentido histórico y de pertenencia a una profesión. No tienen referentes ni antepasados, son bastardos, profesionalmente hablando. Vagan desorientados, pendientes de la última tendencia o la herramienta para prototipar, sin entender cómo los contextos económicos e ideológicos afectan a nuestros métodos, nuestras herramientas y el propósito de nuestros productos. No saben cómo era el diseño de interacción hace cincuenta años ni alcanzan a imaginar cómo podrá ser el de los próximos cincuenta. Están encerrados en el presente. Es muy difícil que se conviertan en grandes séniors, que tengan sentido de trascendencia.

 

Si como diseñadores queremos ganar protagonismo e influencia (en las empresas, en el sector, en el mundo) necesitamos enderezar esto, recomponer ese cisma entre UX y visual ¿Seremos capaces?