Una plataforma no es una web con inicio de sesión. Lo difícil no es dibujar las pantallas, es decidir qué se le permite al usuario no saber.
Casi todo producto SaaS que cuesta de usar cuesta por el mismo motivo. En algún momento de su historia quedó una decisión sin tomar y la interfaz la heredó.
Si este campo debería ser obligatorio. Si esto ocurre solo o el usuario lo confirma. Cómo se llama esta cosa. Cada una de esas es una decisión de producto, y cuando nadie la toma, la toma la interfaz enseñando la opción. Junta unas cuantas y acabas con una página de ajustes de noventa casillas y una cola de soporte que no baja.
Diseñar bien una plataforma es, en buena parte, la disciplina de volver a sacar esas decisiones de la pantalla.
¿Qué hace buena a una interfaz SaaS?
Una interfaz SaaS es buena cuando el usuario completa su tarea principal sin tener que aprenderse cómo está construido el producto por dentro. En la práctica son cuatro cosas: que la primera pantalla enseñe algo útil y no un contenedor vacío, que la navegación se parezca a cómo piensa el cliente su trabajo y no a cómo está montada la base de datos, que los estados que de verdad se dan (vacío, cargando, error, demasiados datos) estén diseñados y no dejados por defecto, y que el número de decisiones que el producto le pide al usuario sea el más bajo que el producto pueda permitirse honestamente.
La primera pantalla es casi todo el producto
El usuario nuevo decide si el producto es para él mucho antes de haber usado nada. La pantalla que decide eso suele ser la que nadie diseñó, porque cuando el equipo la construyó había datos de prueba en la cuenta y se veía llena.
Para un cliente nuevo de verdad está vacía. Una tabla sin filas, una gráfica sin línea, un panel de ceros. El producto funciona exactamente como se construyó y parece roto.
Lo que hay que medir aquí es cuánto tarda alguien en ver algo cierto sobre su propio negocio. No en terminar la configuración. No en acabar el tour. En mirar la pantalla y reconocer ahí su trabajo. Todo lo anterior a ese momento es un coste que el cliente paga a cuenta de un beneficio que todavía no ha tenido.
De ahí sale una instrucción sin matices para la primera sesión: quita cualquier paso que no haga falta para que ese momento ocurra. El logo de la empresa se pide después. Los compañeros de equipo, después. La facturación, mucho después.
¿Qué tiene que conseguir el onboarding de un SaaS?
Llevar al usuario al primer momento en el que ve algo cierto sobre su propio negocio, lo antes posible, y aplazar todo lo demás. Los pasos de configuración que no contribuyen a ese momento deberían moverse a sesiones posteriores o resolverse con valores por defecto sensatos. Una prueba útil: cuenta las pantallas que hay entre registrarse y ver datos reales, y los campos obligatorios antes de que el producto haga algo. Las dos cifras suelen ser dos o tres veces más altas de lo necesario, porque cada una la añadió alguien resolviendo su propio problema y no el del usuario nuevo.
Tu navegación es tu modelo de datos, lo quisieras o no
Los menús laterales suelen escribirlos quien estuviera construyendo en ese momento, así que acaban listando las tablas de la base de datos. Empresas. Contactos. Oportunidades. Actividades. Etiquetas. Informes. Ajustes.
Eso describe fielmente el esquema y describe muy mal un trabajo. Nadie llega a la oficina con la intención de interactuar con la tabla de actividades. Llega con la intención de saber qué oportunidades se han quedado calladas esta semana.
Rehacerlo no es cosmético ni es gratis, porque en cuanto la navegación deja de calcar el esquema hay varias pantallas que tienen que juntar datos que antes vivían separados. Ese es justo el trabajo que se está esquivando cuando un menú se deja como un listado de tablas: la dificultad se movió del equipo de desarrollo a todos los clientes, para siempre.
Una prueba que lo destapa rápido: pídele a un cliente que te cuente qué hizo ayer en el producto. Si las palabras que usa no son las de tu menú, el menú está mal y ese cliente lleva traduciendo en silencio desde el primer día.
Los estados que nadie diseña son los que todos ven
Una pantalla tiene más estados que el que está en el archivo de diseño, y los otros no son casos raros. Son la mayor parte de lo que se ve en el uso real.
- Vacío, que es como está toda cuenta el primer día y como se quedan algunas.
- Cargando, que con mala conexión no es un parpadeo sino varios segundos de duda sobre si el clic ha entrado.
- Con error, donde la diferencia entre un producto útil y uno irritante es si el mensaje dice qué hacer a continuación.
- Con demasiado, el cliente con cuatro mil filas donde el diseño suponía una docena.
- Con textos largos, el nombre, la dirección o la nota que se sale del hueco donde se dibujó.
El estado vacío merece atención aparte porque se malinterpreta. No es un hueco para disculparse por la falta de datos. Es la mejor superficie para enseñar que tiene el producto, porque es la única pantalla en la que tienes toda la atención del usuario y ningún contenido compitiendo. Di qué va ahí, por qué merece la pena tenerlo y da la única acción que lo empieza.
Los permisos son diseño, no una pantalla de ajustes
Los roles se tratan como una función administrativa para añadir más adelante. En realidad cambian lo que significa cada pantalla, porque una pantalla la define lo que puede hacer quien la está mirando.
Puestos encima al final, producen los dos peores patrones del software de empresa. Botones que se ven y luego se niegan, que le enseñan al usuario que la interfaz miente. Y funciones que desaparecen sin explicación, que generan tickets de gente convencida de que algo está roto.
Ninguno de los dos es difícil de evitar, pero los dos hay que decidirlos en el diseño y no descubrirlos en la construcción. Si una acción no está disponible, di por qué y di quién sí puede. Esa sola frase elimina una categoría entera de confusión y cuesta una línea de texto.
Cuándo se paga solo un sistema de diseño
Los sistemas de diseño se venden como siempre acertados y no lo son. Son una inversión con un umbral, y montar uno por debajo de ese umbral es una manera de pasarse un trimestre sin sacar producto.
El umbral es más o menos este: más de una persona diseñando, más de una persona construyendo el front y suficientes pantallas como para que nadie las tenga todas en la cabeza. Por debajo, un archivo compartido de tokens y una docena de componentes es la cantidad correcta, y lo demás es ceremonia.
Por encima, la cuenta se da la vuelta deprisa. Lo caro de una plataforma madura no es dibujar la pantalla número cuarenta, es que un cambio en el comportamiento de una tabla haya que encontrarlo y repetirlo en cuarenta sitios, y lo haga alguien que no estaba cuando se escribió el primero.
Qué se rompe cuando llegan los clientes de verdad
Las plataformas se diseñan en ordenadores rápidos, con buena conexión y cuentas de prueba pequeñas. Después se encuentran con un jefe de ventas en el móvil, con datos móviles, en una cuenta con tres años de historial dentro.
Esos veinte puntos de diferencia son el problema entero en un número. El INP mide cuánto tarda la interfaz en responder a una interacción, y un producto lleno de interacciones es justo donde eso duele. La brecha no viene tanto de que los móviles sean lentos como de que el trabajo se dimensionó para la máquina en la que se escribió.
Las costumbres que mantienen esto a raya son poco vistosas y de sobra conocidas. Paginar en el servidor en lugar de mandarlo todo y filtrar en el navegador. Pintar las listas largas por ventanas y no enteras. Hacer el trabajo caro cuando el usuario lo pide, no en cada tecla. Nada de eso es ingenioso, y todo eso se salta con la fecha encima.
¿Cuánto se tarda en diseñar una plataforma SaaS?
Para una primera versión con un alcance real de cara al usuario, el diseño suele llevar entre seis y doce semanas antes de construir, y se reparte de forma desigual. La mayor parte se va en los dos o tres flujos que sostienen el valor del producto, más las decisiones compartidas que esos flujos obligan a tomar: navegación, roles y permisos, comportamiento de tablas y formularios, y los estados vacío, cargando y de error. Las pantallas que son variaciones de un patrón ya resuelto se hacen en horas. Lo que consume el calendario son las decisiones, no los dibujos.
La parte que cuesta vender
Casi todo lo que hace que una plataforma se sienta obvia es invisible en una demo. Nadie elogia la opción que se quitó ni la confirmación que resultó no hacer falta. El trabajo se nota después, en una cola de soporte que no crece al mismo ritmo que la cartera de clientes.
Eso queda incómodo en una propuesta y sigue siendo la línea más valiosa que puede llevar. Un producto que se tarda una semana en aprender es un producto con un impuesto permanente sobre cada empleado nuevo de cada cliente que tengas.
