Lo que Roger Dooley no te dijo sobre formularios, onboarding y esos clicks de más.
Una guía practica para desarrolladores que construyen sistema de administración web.
Hace unos meses termine de leer «Friction» de Roger Dooley por segunda vez. La primera lectura fue rápida, con esa energía de «esto lo aplico mañana». La segunda fue distinta. Fue con un proyecto web abierto en otra pestaña, revisando cada modulo contra lo que Dooley describe. Y lo que encontré no fue bonito.
El libro define fricción como el gasto innecesario de tiempo, esfuerzo o dinero para completar una tarea. Suena simple. Pero cuando empiezas a desmenuzar tu propio producto con esa lente, descubres que la friccion se esconde en lugares que nunca hubieras sospechado. No solo en formularios largos o en procesos de checkout. Esta en la forma en que nombras un botón. En la cantidad de opciones que ofreces en un dropdown. En el color de un mensaje de error que nadie lee.
Este articulo es un intento de traducir las ideas de Dooley al lenguaje de quienes construimos sistemas de administración web, CRMs, ERPs y plataformas SaaS multi-tenant. No es un resumen del libro. Es mas bien un mapa de aplicación, pensado para colegas que ya saben programar y que necesitan una guía concreta, no otra charla motivacional sobre «experiencia de usuario».
El cerebro de tu usuario no quiere pensar
Dooley se apoya mucho en el trabajo de Daniel Kahneman y su distinción entre el Sistema 1 (rápido, automático, intuitivo) y el Sistema 2 (lento, deliberado, que consume energía). La mayoría de interacciones que un usuario tiene con tu plataforma deberían resolverse con el Sistema 1. Cuando lo obligas a activar el Sistema 2 sin necesidad, estas generando fricción.
Yo lo vi con claridad en un modulo de facturación que estábamos construyendo. El formulario pedia 14 campos para generar una factura. Técnicamente todos eran necesarios. Pero al analizar el flujo, descubrimos que 9 de esos campos podían pre-llenarse con datos que ya teníamos del cliente. El usuario solo necesitaba confirmar y ajustar lo que fuera diferente. Pasamos de 14 campos activos a 5. La tasa de facturas completadas subió casi un 40%.
No fue magia. Fue lo que Dooley llama «smart defaults», valores predeterminados inteligentes. Amazon lo hace con su compra en un click. WhatsApp lo hizo con su onboarding1 de dos minutos. La idea es la misma: si ya tienes la información, no la pidas de nuevo.
Onboarding: los primeros 60 segundos deciden todo
Hay un dato de la industria que me parece brutal. En aplicaciones B2B, si un usuario no encuentra valor en los primeros 60 segundos después de registrarse, la probabilidad de que abandone se dispara. Y no vuelve. Te costo dinero adquirirlo, y lo perdiste porque tu formulario de registro pedia el nombre de la empresa, el tamaño del equipo, la industria, el país, la zona horaria y el color favorito antes de dejarlo ver una sola pantalla funcional.
Dooley cuenta el caso de Buffer, cuyo proceso de onboarding era extremadamente simple y ademas amigable. También menciona como WhatsApp creció exponencialmente en parte porque su registro tomaba menos de dos minutos, sin contraseña, todo diseñado para velocidad. Y como invitar amigos era tan fácil que el crecimiento se volvía viral.
Para un SaaS de administración, yo recomiendo algo concreto: deja que el usuario entre y use el producto antes de pedirle datos. Duolingo lo resolvió de forma elegante. Abres la app y lo primero que ves no es un formulario de registro sino una pregunta funcional: «Que idioma quieres aprender?» Solo después de completar tu primera lección, cuando ya invertiste esfuerzo y sentiste un logro, te pide crear una cuenta para «guardar tu progreso». El usuario ya se engancho.
En un CRM o ERP, la versión de esto seria: deja que el usuario cree su primer contacto o su primera factura antes de pedirle que complete su perfil empresarial. Que toque el producto. Que sienta que funciona. Después le pides los datos complementarios, cuando ya tiene algo que perder si abandona.
Formularios: cada campo es una negociación
Este punto es personal, porque yo he cometido el error muchas veces. Como desarrolladores, pensamos en datos. «Necesitamos el NIT, la razon social, la direccion fiscal, el telefono, el correo, el nombre del representante legal…» Y tecnicamente es cierto. Pero Dooley insiste en algo que deberia estar pegado en el monitor de todo desarrollador: si no necesitas esa informacion en este momento, no la pidas ahora.
Cada campo adicional en un formulario es una micro-decisión que el usuario tiene que tomar. Y cada micro-decisión consume energía cognitiva. El efecto acumulativo es lo que produce esa sensación de «esto es demasiado» que termina en un tab cerrado.
La regla practica que usamos ahora en nuestro equipo es esta: para cada campo del formulario, preguntamos «que pasa si este dato no esta cuando el usuario hace submit?» Si la respuesta es «nada inmediato», ese campo se va a una segunda pantalla o a un momento posterior. En nuestro caso, redujimos el formulario de registro de organizaciones de 11 campos a 4. Los otros 7 los pedimos durante la primera semana de uso, en momentos contextuales donde el dato tiene sentido.
La interfaz tiene que ser obvia, no inteligente
Hay una trampa común entre desarrolladores con buen gusto estético: diseñar interfaces que son bonitas pero no evidentes. Un botón minimalista sin texto, solo con un icono que «debería ser obvio». Un menú hamburguesa que esconde las tres funciones mas usadas. Un sistema de navegación tan limpio que el usuario no encuentra nada.
Dooley habla de como demasiadas opciones generan fricción. El concepto viene de la famosa investigación de Sheena Iyengar sobre la mermelada: cuando ofreces 24 variedades, la gente mira pero no compra. Cuando ofreces 6, las ventas suben. En un SaaS, esto se traduce directamente al diseño de dashboards y menús.
He visto paneles de control con 15 tarjetas de métricas en la pantalla principal. El usuario entra, ve todo eso, y no sabe por donde empezar. La solución no es mostrar menos datos, sino mostrar los datos correctos en el momento correcto. Cuando un usuario entra al modulo de ventas, no necesita ver las métricas de inventario. Cuando esta en configuración, no necesita el gráfico de ingresos mensuales.
La navegación progresiva funciona bien aquí. En lugar de presentar todo el sistema de golpe, revela funcionalidades a medida que el usuario avanza. Es la diferencia entre entregarle un manual de 200 paginas y darle una guía de «tu primera semana con la herramienta» que lo lleva paso a paso.
Velocidad percibida vs. velocidad real
Dooley distingue entre dos tipos de velocidad: la cuantitativamente mas rápida (el proceso realmente toma menos tiempo) y la cualitativamente mas rápida (el proceso se siente menos largo). Las dos importan, pero la segunda es mas fácil de implementar y muchas veces la ignoramos.
Disney es el ejemplo clásico. Las filas para las atracciones populares son inevitables. No pueden meter mas gente en los juegos. Pero lo que si pueden hacer es poner entretenimiento en la fila, sobreestimar el tiempo de espera (si el letrero dice 30 minutos, probablemente sean 20), usar sistemas de reserva para que la gente no tenga que estar parada, y redirigir trafico a áreas menos congestionadas.
En un SaaS, esto tiene equivalencias directas. Cuando tu sistema esta procesando algo pesado, no pongas una barra de progreso que avanza lentamente y en silencio. Algunos proveedores han implementado mensajes rotativos que le dicen al usuario que esta pasando: «Sincronizando contactos…», «Verificando duplicados…», «Preparando tu reporte…». El proceso toma el mismo tiempo, pero la espera se siente menos frustrante porque el usuario entiende que algo esta ocurriendo.
Otra táctica: procesos en segundo plano con notificación. Si generar un reporte toma 30 segundos, no obligues al usuario a quedarse mirando la pantalla. Déjalo seguir trabajando y avísale cuando este listo. Es un cambio de arquitectura menor que reduce la fricción percibida de forma considerable.
La confianza como reductor de fricción
Este capitulo del libro me pareció el mas subestimado. Dooley argumenta que la confianza es una forma de reducir fricción porque permite que la gente actué sin verificar cada paso. En un contexto interno, eso significa menos aprobaciones innecesarias, menos formularios de justificación, menos burocracia.
En un SaaS multi-tenant, la confianza se traduce en el sistema de permisos. He visto plataformas donde un vendedor necesita aprobación de su jefe para modificar el teléfono de un contacto. El proceso existe porque alguien, alguna vez, cambio un dato importante por error. Pero la solución no es poner un candado en cada campo. La solución es tener un buen sistema de auditoria y reversión. Que el vendedor pueda editar lo que necesite, pero que quede registro y que cualquier cambio sea reversible.
Esto conecta con lo que Dooley menciona sobre Jack Welch en General Electric. Welch elimino capas de gerencia que no aportaban valor operativo, acercando a los directivos al frente de operaciones. En tu SaaS, el equivalente es revisar cuantos clicks de aprobación tiene un flujo y preguntarte honestamente cuantos de esos clicks realmente previenen errores y cuantos solo existen porque a alguien le dio miedo eliminarlos.
Fricción intencional: cuando si tiene sentido agregar pasos
Seria deshonesto hablar solo de eliminar fricción. Dooley lo reconoce y la industria SaaS lo ha aprendido a la fuerza: hay momentos donde agregar un paso tiene sentido estratégico.
El ejemplo mas claro es el modelo freemium. Dropbox ofrece un plan gratuito con limitaciones que funcionan como fricción diseñada. Cuando llegas al limite de almacenamiento, esa incomodidad te empuja hacia el plan de pago. No es un error de diseño. Es un mecanismo deliberado para que el usuario sienta el valor de lo que podría tener.
Otro caso: Smartlook agrego campos adicionales a su formulario de registro para segmentar usuarios por rol e industria. La tasa de registro bajo un 5%, pero la calidad de los datos mejoro tanto que pudieron personalizar el onboarding de forma masiva. Menos usuarios, pero mucho mas activados y con menor tasa de abandono.
La clave esta en la palabra «innecesario» de la definición de Dooley. Fricción es gasto innecesario de tiempo, esfuerzo o dinero. Si el paso que agregas tiene un propósito claro y genera valor tanto para el usuario como para el negocio, no es fricción. Es parte del producto.
Guia de aplicación: 8 pasos para auditar tu desarrollo
Basado en lo que aprendi del libro y en la experiencia de aplicarlo en proyectos reales, esta es la secuencia que sigo para encontrar y reducir fricción en un sistema de administración web:
Primero, mapea el recorrido completo del usuario. Desde que llega a tu landing page hasta que completa su primera tarea productiva dentro del sistema. Cada click, cada formulario, cada pantalla de carga. Ponlo en un diagrama. Los puntos donde el usuario tiene que detenerse a pensar son los candidatos a friccion.
Segundo, cuenta los campos de cada formulario. Para cada uno pregunta: lo necesito ahora mismo, o puede esperar? Si puede esperar, sacalo. Implementa smart defaults con los datos que ya tienes.
Tercero, revisa los tiempos de carga. Si algún proceso toma mas de 3 segundos, necesita feedback visual. Si toma mas de 10, necesita ejecutarse en segundo plano.
Cuarto, simplifica la navegación. Las funciones mas usadas deberían estar a un click de distancia. No a tres. Si no sabes cuales son las mas usadas, pon analytics y mide antes de reorganizar.
Quinto, revisa tu sistema de permisos. Cada nivel de aprobación que no previene un error real es fricción pura. Sustituye aprobaciones por auditoria y reversión cuando sea posible.
Sexto, prueba tu onboarding con alguien que no conoce el producto. Cronometra cuanto tarda en completar su primera tarea. Si tarda mas de 5 minutos, hay trabajo por hacer.
Séptimo, busca mensajes de error que no ayudan. «Error 422» no le dice nada a nadie. «El NIT que ingresaste ya esta registrado. Quieres vincular este contacto a la organización existente?» es un mensaje que reduce fricción porque ofrece una salida.
Octavo, establece un mecanismo continuo. Dooley insiste en que la fricción se acumula con el tiempo. Cada nueva funcionalidad, cada campo extra, cada paso adicional. Haz una revision trimestral de flujos con datos reales de uso.
Pensar en fricción es pensar en respeto
Hay algo en el libro de Dooley que va mas allá de la conversión y las métricas. Cuando reduces fricción, lo que realmente estas haciendo es respetar el tiempo de la persona que usa tu producto. Y eso, en un mercado donde todos compiten por atención, es quizás la mejor estrategia de retención que existe.
No digo que sea facil. Cada vez que propongo eliminar un campo, alguien en el equipo tiene una razón para mantenerlo. Cada vez que sugiero simplificar un flujo, aparece un caso borde que «necesita» el paso extra. La resistencia interna es real, y Dooley lo admite también. Pero el costo de no hacer nada es peor: usuarios que se van sin decir nada, que abandonan carritos, que empiezan el registro y no lo terminan.
Lo que me quedo del libro, y que intento aplicar cada semana, no es una metodología cerrada. Es mas bien una pregunta constante: «esto se puede hacer mas fácil?» A veces la respuesta es no. Pero la mayoría de las veces, si te tomas el tiempo de observar como la gente realmente usa tu producto, la respuesta te va a incomodar un poco. Y esa incomodidad es justo el punto de partida.
- El onboarding es el proceso de guiar a un nuevo usuario (o cliente) paso a paso cuando entra por primera vez a una aplicación o servicio, para que entienda cómo funciona, configure lo básico y pueda empezar a usarlo sin perderse.
Pensalo como el equivalente digital de cuando llegás a un hotel y alguien te recibe, te explica dónde está todo y te entrega la llave de tu habitación. Sin ese recorrido inicial, el huésped queda perdido.
En el contexto de un SaaS, el onboarding típicamente incluye cosas como crear la cuenta, configurar el perfil o empresa, elegir un plan, y un recorrido rápido por las funciones principales para que el usuario sienta que ya puede trabajar. ↩︎