‌Si estás involucrado en la comunidad de diseño sin código (Low Code /‌No code), nos podríamos jugar el dedo meñique de la mano derecha, a que en las últimas semanas habrás recibido algún e-mail o te habrá asaltado algún ‘corazoncito’ en tu feed de Twitter hablando sobre la nueva herramienta que va a revolucionar el mercado.Una landing preciosa, muchas promesas, soluciones a todos los problemas en un click.

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.

‌Si estás involucrado en la comunidad de diseño sin código (Low Code /‌No code), nos podríamos jugar el dedo meñique de la mano derecha, a que en las últimas semanas habrás recibido algún e-mail o te habrá asaltado algún ‘corazoncito’ en tu feed de Twitter hablando sobre la nueva herramienta que va a revolucionar el mercado.Una landing preciosa, muchas promesas, soluciones a todos los problemas en un click.

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.