Para ser sincero, hay algo que me duele en relación a esta disciplina, y es que es percibida en general (en mi experiencia profesional) de una manera muy frontal (muy ‘pantallil’) referida al lugar de contacto y al contacto en si mismo, a la interfaz como superficie que conecta sistemas. Pero amigos, una interfaz puede ser tantas cosas… desde la frente de tu pareja cuando le tocas para saber si tiene fiebre, hasta un saco de boxeo con sensores que mide tu fuerza y precisión. Hay mucho de interfaz en la interacción, por supuesto, pero es mucho más que eso. La parte más relevante para mí, de esta rama del diseño, es la conductual, más cerca del “porqué” que de el “qué”.

En esta linea, mi forma favorita de explicar qué es diseño de interacción es el de: “Una conversación en silencio”.

Cuando nos relacionamos con un objeto físico o digital, solos frente al mismo, tal vez en la intimidad de nuestro hogar se crea un sistema de comunicación (Emisor-Receptor). El objeto nos habla habla a través sus elementos de interfaz (UI) y de la interpretación de estos elementos nace en nuestro cerebro un chispazo que nos lleva a interactuar con el mismo (Información), a raíz de nuestra acción el cerebro de la máquina nos devuelve una respuesta y en este ir y venir, en este tira y afloja, ambos conseguimos un objetivo.

Quizás, el problema que veo en la forma que los diseñadores de producto digital proyectamos ideas, es que en muchos casos nos quedamos con el trigger, el acto y la respuesta… pero nos olvidamos del pensamiento de los sistemas cognitivos del humano y de la máquina, peleando en un debate intelectual para conseguir resolver algo. Esa es la parte donde sucede la magia.

Del mismo modo que comunicarnos con nuestro gato es a veces una tarea ardua y desesperante, aunque se acaben generando ciertos rituales que nos permiten entendernos. Comunicarnos con un sistema cuyas lógicas de procesamiento de la información no están bien trabajadas, siempre va a ir en detrimento de la experiencia de uso

Diseño de Interacciones y nocode

Vamos a pensar un momento en todos esos productos/servicios donde la interacción no está al servicio de una aplicación que descargar de una ‘store’, en las que no hay un montón de pixels bien organizados ni una fría pantalla de cristal líquido de por medio. (Porque no existen los recursos, porque no es necesario, o por lo que sea).

Nuestra misión, es hacer que la comunicación entre el sistema humano (Usuario) y el sistema máquina (Base de datos/Algoritmo), sea algo cómodo e intuitivo. Que no sean señales de humo, vaya.

Una interfaz visual (GUI) atractiva no es sinónimo de una buena experiencia o de una buena performance en términos de usabilidad, lo importante es diseñar un lenguaje que garantice la efectividad de la comunicación. Es decir, si yo te pregunto ¿Cuál es tu comida favorita? y tu me respondes a los 10 segundos “Plutón”, probablemente, me levante, pague mi cuenta y abandone la sala lo antes posible.

En este caso el nocode/lowcode también juega un papel interesante, su valor reside en posicionarse como un traductor entre sistemas accesible a perfiles con capacidades menos técnicas. Y en este caso su polifacético y desmesurado ecosistema de herramientas, permite que nos podamos adaptar mucho a las necesidades de negocios y usuarios variopintos de una forma impensable hasta ahora.

Lo explicaré mejor con otro ejemplo: Por las mañanas me levanto y quiero calentar mi café con leche. Podría calentarlo a través de un sistema de cristales convexos, que apunten al sol, con un angulo de refracción de 27º. También podría hacer una hoguera en mitad de mi cocina y calentar mi café en una pota gallega. Pero, por suerte (o por desgracia), tengo un microondas, al que con un par de ‘clicks’ puedo decirle “porfavor señor robot caliente mi café 30 segundos”, en una maravillosa conversación en silencio. Y ojalá, (de verdad) hubiese algo más sencillo aún que me permitiese decirle al sistema “café muy caliente” y me ahorrase esos dos clicks.

¡Eso es el nocode! caminos ágiles de resolución de problemas adaptados a las necesidades de tu momento vital y empresarial. Hay negocios que no necesitan invertir 120k en una plataforma adhoc para gestionar lo que sea que hagan. Seguro que hay un SaaS que se adapte a ellos, o al menos durante una buena temporada. Y sino, puede que alguien te ayude a crear y personalizar algo que cubra tu problema (o que lo hagas tu mismo) a través de un sistema de integraciones, que responda exactamente a lo que necesites. La interfaz de esa solución podría ser un sistema de SMS, un dispositivo alexa, un sensor de temperatura, o un botón rojo en mitad de una mesa que ponga: “no pulsar, salvo emergencias”.

Y si el medio es el mensaje, como decía McLuhan. Las APIs realmente son los canales que capacitan la construcción de estos sistemas, son puentes entre islas. Por algo su acrónimo es “Interfaz de programación”, y una vez más recaigo en la misma frase, una interfaz sirve para que dos entidades independientes, hablen el mismo idioma y puedan colaborar entre ellas. - “Quiero esto así“ - ” ¡Aquí lo tienes!“

Durante el proceso de diseño y entrega de producto. El equipo de ingeniería (casi con toda seguridad) intentará hacer los productos lo más funcionales y menos complejos posibles y el equipo de negocio estará sacando la tijera a pasear para reducir costes, nosotros, como diseñadores, debemos estar pensando entremedias en como lograr que la conversación que se produzca tenga el mínimo de interferencias posibles, a pesar de todo esto.

Y eso pasa por entender muy bien el famoso sistema de integraciones. Construir ‘flujos de usuario’ desde el lenguaje de la lógica de desarrollo significa tener en cuenta que tus decisiones como diseñador afectan a multiples plataformas, tecnologías, dispositivos y modelos de datos: si hago esto pasa esto, y si pincho aquí sucederá esto otro, y efectivamente, no, no hablo de pantallas, hablo de producto siempre.

Solemos decir que en Experiencia de Usuario ayudamos a la gente a que tome decisiones sin pensar‌(O sin pensar mucho, al menos), pero también debemos hacer que las máquinas piensen lo ‘justito’ y solo en lo que realmente necesitamos.

Es en este punto donde los diseñadores de interacción deben empoderarse y ganar importancia en el proceso de construcción, como negociadores, filtradores y encauzadores de las toneladas de información que nos pueden ofrecer nuestras queridas bases de datos. En ese viaje del dato, nuestras decisiones deben contribuir a que los datos vayan avanzando de la forma más limpia posible para poder diseñar un lenguaje (¡Esto es la clave de todo!). Poder disponer de todas las “palabras” posibles, de un ritmo adecuado y un tono ideal, que logre que la interacción humano-máquina sea como una cita en la que hay química desde el minuto uno.

Entendiendo el todo

¿Cómo logramos todo esto? Pues como hemos hecho siempre en diseño de experiencia: !Mapeando¡, Definiendo los qués, cómos y cuándos que nos permitan determinar si nuestras intenciones son posibles o no. Si lo hacemos, nos acabaremos dando cuenta de que hay cosas que serán, literalmente, imposibles de comunicar al usuario, y ese ‘Journey Map/Flujo de tarea/‌Documento funcional’ será la mejor herramienta para tomar decisiones inter-departamento, que afecten lo menos posible a la construcción del lenguaje, en base al alcance del proyecto.

Y ahí amigos míos nace la creatividad de la lógica, si no puedo comunicar esto de la manera que me gustaría, ¿Cómo logro que estos dos mundos opuestos se entiendan?. A veces la solución puede pasar por determinar que tal vez una App no es el mejor camino, o que debemos prestar más atención a la narrativa visual… La clave está en determinar cómo construir un nuevo sistema de comunicación en base a las “palabras” que podemos usar, ¿Quizás tu producto se deba comunicar con gestos, con sonidos o con vibraciones? ¿Tal vez con metáforas?¿Con ronroneos?.

Al final todo esto trata de alguna manera de escribir un poema capaz de evocar imágenes claras, no se necesitan 800 páginas, ni todas las palabras del diccionario para trasladar un mensaje. Pero desde luego aquellas que aparezcan en nuestro diálogo deben ser las mejores entre las disponibles para expresar lo que queremos de la forma más sencilla.

En cierto modo un diseñador de interacción es un poeta de la lógica, no solo alguien que une pantallas en Figma con cablecitos azules. Se trata de comunicar lo más posible con lo menos posible. Porque las mejores conversaciones ocurren en silencio.

El problema que desgraciadamente existe con el ecosistema de herramientas, es que cada equipo y cada proyecto siempre van a tener necesidades diferentes. Las herramientas hablan sobre ‘Happy Paths’ y los creadores de contenido cubren los casos sencillos, pero nadie habla de las necesidades de la lógica negocio y de cómo adaptarnos a las necesidades de nuestros clientes, priorizar funcionalidades para un MVP o escribir una propuesta de valor que refleje la historia de tu producto.

Diseñar pantallas, integrar herramientas de forma frontal o automatizar procesos, NO es diseñar productos.

Diseñar productos, o diseñar experiencias de usuario para productos, consiste en entender las necesidades de negocio y acotar nuestra propuesta a la viabilidad del stack tecnológico en el tiempo disponible. Y por supuesto, hablar con personas, entender cómo se comportan y ayudarles a resolver problemas en su vida. Que algo se pueda hacer no significa que haya porque hacerlo.

A lo largo de las diferentes aventuras profesionales que llevo transitando durante los últimos años, he tenido la suerte de caminar cerca de muchas personas que son referentes y que han influenciado mi forma de entender la innovación, el negocio y el mundo profesional. Uno de ellos ha sido Octavio Egea, que escribió junto con Nieves Padilla este paper en frogdesign:

https://www.frogdesign.com/designmind/the-business-value-of-customer-experience

No puedo hacer más que recomendar a cualquiera que esté dentro del sector y quiera entender el porqué de lo que hacemos que lo lea con detenimiento.

En el paper Octavio escribe lo siguiente:

“ By clarifying the customer need during the design phase, companies are able to better anticipate outcomes before deployment, when costs are at their lowest.”

Octavio habla del proceso de diseño tradicional. Pero, pensando en ello, realmente es lo que marca la diferencia en la forma de construir producto en No code. Por eso el diseño estratégico cumple una función fundamental dentro del proceso de construcción. Céntrate en la necesidad que quieres cubrir, y luego decide cómo hacerlo.

En ese decidir, el Diseñador ‘Maker’, va a ser capaz de reducir los tiempos del proceso de trabajo y salida a mercado. ¿Porqué?, Porque solo va a proyectar soluciones realizables y alineadas con las expectativas de cualquier equipo de desarrollo, el tiempo disponible y las métricas a validar en el momento del producto. Eso amigos míos, es un verdadero cambio en el juego. Nosotros lo llamamos “Product Moment Design”, diseñadores ‘end to end’ que entienden el proyecto de inicio a fin.

¿Y qué tiene que ver la experiencia de usuario con todo esto?

La experiencia de usuario es vital en un mercado donde la diferenciación entre soluciones a veces simplemente pasa por la percepción o comodidad en el uso de una plataforma por parte de los usuarios. Las grandes ideas, sean hechas con código o centradas en una herramienta, pueden verse absolutamente desbancadas por soluciones que se han preocupado por hacerse las preguntas correctas antes de prototipar una sola solución.Soluciones más sencillas (que no simples) y más enfocadas a la tarea a resolver pueden ganar la partida a sistemas monstruosos de funcionalidades desarrolladas en unos costes y unos tiempos difíciles de asumir. La featuritis es un mal endémico, que debemos corregir y evangelizar a nuestros clientes.

En esta línea, ya no hablamos de MVPs, hablamos de MAPs (Minimum Awesome Products). Ya no basta con salir, hace falta salir e impactar. Cuidar la narrativa, el visual, el uso de la interfaz y por supuesto la forma de interacción con la misma .

El Nocode o el Lowcode (Nos gusta más esta acepción), en definitiva son una forma de accesibilidad para diseñadores y personas de negocio. Son un brazo biónico que nos permite construir en digital. Neo conectado a Matrix, saliendo de su trance y diciendo: “Ahora puedo hacer realidad mis ideas”. Un súper poder, en definitiva, que no consiste en saber programar, consiste en entender la parte lógica del desarrollo que se adapta al momento de mi producto y en ese acercamiento, aprenderás (casi seguro) a programar sin darte cuenta. Un poco los artesanos digitales del siglo XXI, por fin somos capaces de alcanzar soluciones por nosotros mismos con el mimo y cariño que requieren.

Me parece bien llamar nocode a hacer una página en Webflow, pero creo que el verdadero valor es sistémico y no nodal.

¿Cuál es el reto del Nocode/LowCode?

Ya lo decían hace muchos años, en el libro “La Economía de la Experiencia”, Joseph Pine II y James H.‌Gilmore. A mayor diseño, mayor coste asociado. Starbucks vs. Cafetería Jose Luis.

Si queremos que el Nocode sea relevante y se convierta en una industria o un modelo de trabajo rentable para todos, debemos evitar las soluciones paquetizadas, las templates y los videos de Youtube donde te enseñan a replicar AirBnb en 5 minutos. Porque Airbnb no es la interfaz. Airbnb fueron dos diseñadores industriales que detectaron un problema, que iteraron y montaron una lógica de negocio y un sistema que era capaz de rentabilizar un vacío que existía en la época. Y ‌a esa solución , le pusieron una cara bonita en HTML.

Reducir tiempos es el fin de todo esto. Todo las innovaciones históricas han permitido que las cosas sucedan más rápido. Todas. En TiempoRelativo creemos en que las cosas se pueden hacer de otra manera, más eficiente, si. Pero sin llegar a soluciones que no tengan alma. Codeless is not souless.