¿Qué significa esto para desarrolladores, diseñadores y gerentes de producto?

Creo que es un gradiente, dependiendo del equipo. Y lo que más estamos viendo en Webflow es que para los desarrolladores — aunque conceptualmente muchas personas piensan que estamos tratando de sacar a los desarrolladores del trabajo, ¿verdad? Pero realmente, lo que está sucediendo es que estamos tratando de automatizar las cosas que son más propensas a la automatización — así que para los desarrolladores están encantados porque ahora pueden trabajar en las cosas difíciles, en los problemas realmente interesantes.

Para los diseñadores los hace los héroes. Es un superpoder, ¿verdad? Porque ahora están haciendo el trabajo de dos personas. ¡Y se sienten más creativos!

Para los PM también se mueven más rápido. Pueden validar ideas más pronto. Pueden hacer pruebas de vapor más rápido. Pueden confiar más en sus diseñadores y en la fase de investigación, mucho más en comparación con la espera que ocurre con el cascada clásico donde diseñas algo y luego tienes que esperar a que el desarrollo lo implemente, o tienes que prototiparlo en código y luego de alguna manera presentarlo a los usuarios.

Muchas veces comienza desde el lado operativo de la casa. Son estas personas que, tal vez tienen un montón de ingenieros contratados, pero esos ingenieros a menudo se implementan contra el producto principal que están construyendo. Es como "Oye, nuestro trabajo es construir esta x de clase mundial. Y esa x es realmente en lo que queremos estar gastando todo nuestro tiempo." Sin embargo, para dirigir el negocio, necesitamos todas estas otras cosas. Necesitamos un CRM. Necesitamos una herramienta de facturación. Necesitamos marketing por correo electrónico. Necesitamos gestión de proyectos. Necesitamos todas estas otras cosas, y nuestros ingenieros a menudo no ayudan a hacer que esas cosas funcionen mejor juntas.

Los ingenieros se enfocaban en el problema realmente difícil de entregar un producto a los clientes finales. Y entonces la dirección del lado comercial de las cosas a menudo es donde el personal de operaciones comienza a intervenir e implementar una pila de código cero y hacer las cosas más eficientes, hacer que cada vendedor sea un poco mejor en su trabajo, hacer que esto que solía tomar todo el día o toda la semana suceda instantáneamente.

Los diseñadores de UX tienen la mayor oportunidad, porque pueden cerrar esta brecha de: lo diseñé, pero ahora tienes que enviar a alguien más para construirlo o enviar este diseño a alguien más para construirlo. Pueden cerrar ese ciclo e iniciar casi negocios de diseño más integrales o prácticas de diseño al tener acceso a estas herramientas sin código. Hay tanta similitud entre cómo funciona una herramienta de software sin código y cómo funcionan las herramientas de diseño que encuentro que los diseñadores la aprenden realmente rápido.

Para los desarrolladores, creo que es algo bueno para ellos. No estarán perdiendo su tiempo en proyectos que no funcionen. Las personas deberían tener más convicción sobre lo que están intentando construir antes de hablar con el desarrollador. Además, el 25% de nuestra comunidad son desarrolladores que ven sin código como una forma de lanzar y validar rápidamente sus propias ideas.

Para los diseñadores, pueden construir cosas en lugar de solo decir cómo deberían verse. Ya no tienen que convencer a los desarrolladores para que construyan cosas.

Para los desarrolladores, creo que les va a permitir enfocarse en construir tecnología central que mueva la aguja y de alguna manera liberarse. Muchas veces cuando era ingeniero, querría crear productos o sabía que el propietario del negocio tendría que volver. Entonces para hacer eso, los desarrolladores tienen que pensar en problemas mucho más grandes o en una escala mayor con mejor granularidad. Creo que hará que el software que crean sea mucho mejor.

Para los diseñadores, creo que les va a permitir enfocarse más en el contenido en sí versus la estética y el diseño. Entonces en lugar de tratar de averiguar cómo mezclar y combinar piezas de un rompecabezas, ahora estoy más interesado como diseñador en crear cómo se ve el rompecabezas real versus tratando de hacer que todo encaje dentro de esas limitaciones de plataforma.

Creo que los gerentes de proyecto y los propietarios de productos siempre son la persona que hace malabarismos con las prioridades, descubriendo cómo asignar recursos para tener la mayor cantidad posible de las plataformas principales hechas de una manera sin código que les permitirá enfocarse en priorizar características e construcciones que ayuden a mover la línea superior e inferior, no solo como el "Oye, tenemos que mantenernos a flote tipo de iniciativas."

Creo que lo que siempre he hablado con desarrolladores es que a los desarrolladores realmente les gusta construir funcionalidad que sea reutilizable, propósito general, y que pueda usarse para muchas cosas diferentes. Entonces, la mayoría de desarrolladores que conozco que son realmente hábiles, preferirían escribir un componente de propósito general que pueda reutilizarse en algún lugar, o una biblioteca de código abierto o algo así, en lugar de escribir esta cosa única que solo será usada aquí una vez. Creo que realmente aprovechar los conjuntos de habilidades del desarrollador para construir funcionalidad reutilizable que luego pueda conectarse y aplicarse sobre algo como Adalo, que proporciona la funcionalidad estándar de línea base, es realmente lo mejor de ambos mundos.

Para diseñadores, habrá algo de cambio donde las líneas se están difuminando entre lo que son las fases de diseño inicial — como la fase de diseño hasta el prototipo, hasta el desarrollo con desarrolladores, hasta la producción. Si lo que estaba describiendo con los componentes realmente se convierte en realidad, entonces los sistemas de diseño combinados con herramientas no-code significarán que los diseñadores realmente pueden construir el producto en cierta medida, y luego conectar las cosas que los desarrolladores están construyendo.

Para PMs, ya no tendrán que pedir permiso, simplemente pueden ir a construir algo ellos mismos y luego decir, hey, diseñador ayúdame a arreglar esto. En lugar de tener que pasar por el canal tradicional de — quiero construir un producto, necesito que un diseñador se una, que un desarrollador se una, que mi jefe autorice este proyecto. Simplemente pueden construirlo ellos mismos en un fin de semana y luego mostrarlo. Eso va a transformar completamente la velocidad a la que las organizaciones pueden moverse porque a menudo una de las cosas que más ralentiza a las personas es simplemente las dependencias dentro de una organización y la disponibilidad de recursos.

Sé que muchas personas en estos roles podrían comenzar preguntando: "¿Voy a perder mi trabajo por estas plataformas?". No lo creo — las plataformas sin código surgen porque hay tal escasez de ingenieros de software, diseñadores y gerentes de producto — y todos quieren construir. No creo que estos roles desaparezcan — creo que las personas en estos roles siempre serán necesarias para construir algo verdaderamente excelente, pero podrían no ser necesarias para construir algo básico. El futuro del sin código es permitir que los desarrolladores y diseñadores se enfoquen en las cosas en las que son buenos y no se preocupen por las cosas que no valen su tiempo.

Además — lo que realmente obtienes con el mundo sin código es verdadera colaboración, permitiendo que los equipos eviten tanto trabajo de "poner trabajo en cola" — y simplemente hagan el trabajo directamente. En la mayoría de las empresas de software, el 98% de las personas en la organización simplemente están poniendo trabajo en cola para que los ingenieros completen. Por ejemplo, si estás haciendo trabajo de diseño, terminás creando historias y especificaciones, y simplemente va a un rastreador para que un ingeniero lo implemente. Eso es tan ineficiente — ¿por qué no simplemente implementar los cambios de diseño tú mismo? La verdadera colaboración significa construir juntos. Creo que las herramientas sin código y bajo código nos permiten realmente trabajar juntos.

En cuanto a los desarrolladores, pienso en esto como acelerar todo, y el no-code, en muchos sentidos, es el impulso de intentar hacer algo. No necesariamente significa que sea tu producto final en el que estés trabajando. Pero va a ser mucho más rápido sacar esa estructura para que puedas jugar más, hacer más, y tal vez intentar esa cosa que de otro modo habría tomado un tiempo realmente largo para aprender.

Con los diseñadores, creo que el no-code ha sido un movimiento increíblemente empoderante para ellos. Donde, por ejemplo, yo, vengo de un trasfondo de diseño y me encantaba poder hacer estos diseños hermosos y completos en mi computadora, pero no respiraban. Hay algo un poco especial en ver cómo se mueven esas cosas, cómo funcionan las interacciones reales, y a veces es un poco frustrante tener esto y no poder comunicarlo completamente o quedarte un poco atrás cuando intentas hacerlo realidad. Así que creo que las herramientas de no-code realmente han superpoderizado a los diseñadores cuando se trata de poder animar muchas de las cosas que están haciendo, hacerlas vivir, crear sitios web, aplicaciones web, mercados; hay tantas cosas que han hecho.

Con los PMs o miembros no técnicos de los equipos, ha abierto no solo más formas para que puedan traer MVPs a la vida, ensuciarse las manos, sino también construir empatía hacia otras personas en su equipo. Personalmente, encuentro que al sumergirme en herramientas de no-code, he aprendido más sobre la lógica, las expectativas y las complejidades detrás de lo que estoy pidiendo, lo que me ha hecho, creo, más empático como líder, pero también en términos de cómo administro o espero lo que se puede lograr en el alcance.

El PM que obviamente necesita algo del desarrollador o del diseñador podría ser capaz de tachar una serie de tareas por su cuenta. Cualquiera de los colegas que no se suponía que estuvieran haciendo esos cambios podría estar haciendo esos cambios.

[Ben] Creo que esto realmente depende del liderazgo de un espacio a otro. Creo que hay muchos desarrolladores que ven la ventaja. [Escucharé cosas como] "Solo quiero que sepas que encontré Webflow, y oh Dios mío, como lo ha hecho por mí, en lugar de tener que pasar todo este tiempo trabajando en microinteracciones, puedo realmente volver a lo que sucede en el backend y pasar más tiempo allí".

Lo mismo ocurre con los diseñadores y PMs también. Para que un diseñador no solo te muestre un mockup de Figma o Sketch, sino que realmente te muestre, 'mira cómo se ve esta microinteracción', o 'mira cómo fluye', como, puedes realmente hacer clic en esta aplicación y pasar por todo el flujo de la aplicación. Simplemente creo que va a ayudar a las personas en general —desarrolladores, diseñadores, PMs—, creo que juega un papel muy importante. Ya puedo verlo haciendo eso. Y creo que solo va a continuar haciendo esas cosas.