← Blog de Guindo Design, Diseño Estratégico de Producto Digital
Diseño de onboarding de producto mediante CLI
Lanzar una CLI (interfaz de comandos) ha dejado de ser una medalla exclusiva de ingeniería. Hoy, cualquier perfil de producto puede generar una herramienta de terminal funcional con un simple prompt de IA. Pero la capacidad de generar código no implica construir producto.
La mayoría de las CLIs pierden a sus usuarios en los primeros 30 segundos porque nadie ha pensado en su onboarding. El verdadero cuello de botella ya no es el código, es el diseño.
¿Qué es una CLI?
Tanto una CLI como un chat de IA son interfaces de texto, pero con una diferencia crítica que antes era una gran barrera de entrada: utilizar una terminal te obliga a memorizar comandos rígidos para poder operar con un sistema. Es una interfaz de «recuerdo», no de «reconocimiento».
En un chat de IA el LLM trabaja como intérprete, otra interfaz (el modelo) que traduce tu lenguaje humano («arregla esto») a la instrucción técnica que el sistema entiende. Por lo tanto, la fricción con el producto se desplaza y ya no es necesario aprenderse el manual de comandos: la barrera de entrada deja de ser técnica y se convierte en un problema de confianza y onboarding.
Que la barrera técnica haya caído no significa que las interfaces gráficas hayan muerto, simplemente son menos eficientes para ciertos casos de uso. Para que un LLM analice, edite y cree archivos en tu ordenador, es mucho más eficiente apuntar la IA a tus archivos que subir tus archivos a la IA. Por eso, plataformas como Anthropic u OpenAI suelen lanzar una CLI como pieza clave de su ecosistema:
- Rendimiento y latencia. Las interfaces web son lentas por definición (carga de assets, animaciones, esperas de renderizado). En la terminal no hay nada que decorar; el flujo de datos es directo y la ejecución es inmediata.
- Automatización de procesos. Un chat web está diseñado para resolver tareas de una en una mediante la conversación. Una CLI permite que la IA se integre en flujos de trabajo sistemáticos, procesando cientos de archivos de forma automática mientras tú te centras en otra cosa.
- Control del contexto. Es mucho más sencillo (y genera menos fricción de seguridad) autorizar a una herramienta de IA para que mire una carpeta local que obligar al usuario a seleccionar, empaquetar y subir manualmente información sensible a una web.
Si la conexión entre la IA y tus archivos está mal diseñada, la experiencia con el producto se rompe por muy inteligente que sea el modelo de lenguaje que haya detrás. El problema es que los perfiles de UX y producto solemos ignorar este territorio bajo el pretexto de que «es un tema técnico», una dejación de funciones que deja a ingeniería sola ante el peligro de construir herramientas potentes pero hostiles. Una CLI es, ante todo, una interfaz de usuario en modo texto que requiere la misma jerarquía, tono y gestión de la fricción que cualquier aplicación visual. Ingeniería pone la potencia, pero nosotros debemos diseñar el control para evitar que el usuario abandone el producto a los treinta segundos de abrir la terminal.
¿Qué datos necesitas para dar valor?
En diseño de producto, cualquier dato que exijamos antes de demostrar valor es un muro que levantamos en el onboarding. En el caso de una CLI, la estrategia de entrada se resume en una única pregunta: ¿aporta tu herramienta algún valor real antes de conectarse al servidor? Esta distinción es crítica porque determina si la autenticación debe ser una barrera de acceso o un paso opcional para usuarios que ya han probado el producto en sus máquinas.
Bando 1: la identidad como peaje
Si tu herramienta depende de un servidor externo para procesar la información del usuario, no existe valor posible sin identificarlo. Pedir el login en la primera línea es una necesidad de arquitectura, ya que la inteligencia reside en la nube y no en local, y su identidad es el único cable que conecta tu terminal con el cerebro que debe resolver el problema.
Sin embargo, este es el momento de mayor riesgo para el producto, ya que obligar al usuario a abandonar la terminal para ir al navegador supone una ruptura crítica de su flujo mental.
Sacar a alguien de la pantalla negra es peligroso porque lo lanzas a un entorno lleno de distracciones (otra pestaña del navegador) y rompes la promesa de inmediatez de la CLI. Por eso, el éxito del onboarding aquí se mide exclusivamente por la velocidad de retorno. La industria ha resuelto ese pequeño abismo mediante el Device Flow (RFC 8628), un estándar de diseño donde la terminal abre el navegador por ti y se queda escuchando en segundo plano. Referentes como Stripe o Claude Code han convertido lo que antes era un proceso manual y propenso a errores (copiar y pegar tokens alfanuméricos) en un trámite de apenas cinco segundos: un clic en la web, una autorización rápida y la terminal cobra vida automáticamente sin que el usuario haya tenido que manipular ni una sola clave.
En el extremo opuesto está la AWS CLI, que mantiene un modelo de configuración manual (aws configure) donde el usuario debe generar y pegar sus claves de acceso. Aunque este sistema responde a una arquitectura de seguridad pensada para entornos donde el navegador no siempre está disponible y la gestión granular de permisos es obligatoria, para un usuario casual representa un muro de entrada. AWS prioriza la robustez del protocolo sobre la agilidad del onboarding.
Bando 2: primero valor, después identidad
Para herramientas que pueden ejecutarse de forma autónoma, el login no es una barrera de acceso, sino una mejora opcional. El éxito reside en la gratificación instantánea: el usuario descarga la herramienta y comprueba que hace un trabajo útil en su propio ordenador antes de entregar su identidad.
Referencias como Supabase o Prisma tratan la experiencia local como una demo técnica de alta fidelidad. Puedes arrancar una base de datos completa o generar esquemas de código sin haber pasado por un formulario de registro. La autenticación solo aparece de forma orgánica cuando el usuario decide dar el siguiente paso: sincronizar un proyecto con la nube o contratar infraestructura gestionada. En este bando, el diseño de producto consiste en eliminar cualquier fricción inicial para que la utilidad sea indiscutible desde el primer segundo; el login es simplemente el paso final para vitaminar una herramienta que ya te ha demostrado que funciona.
Elegir bando: una cuestión de honestidad
Si tu herramienta es inútil sin la nube, el Bando 1 (login obligatorio) es el único camino honesto. Intentar disfrazarlo con una «prueba local» vacía es hacer perder el tiempo al usuario. En cambio, si puedes ofrecer utilidad inmediata en el ordenador del usuario, aunque sea mínima, el valor local es el anzuelo para construir la confianza necesaria antes de pedir el registro.
La clave está en saber transicionar entre ambos. Prisma es un buen ejemplo de ello: su estrategia consiste en no cambiar de interfaz, sino de profundidad.
- Si el usuario solo quiere configurar su proyecto en local, la herramienta le da los archivos y le permite trabajar con autonomía.
- Solo cuando el usuario intenta conectar una base de datos real, la CLI le pide identificarse.
La herramienta es invisible mientras trabajas en local y solo levanta la mano para pedir credenciales cuando la tarea realmente lo requiere.
Cómo se conecta el usuario: la logística de la «Auth»
Una vez que el usuario necesita identificarse, la UX de la CLI se traslada a la gestión del permiso. Como no hay formularios, el diseño consiste en elegir cómo conectar la terminal con el navegador minimizando la carga cognitiva. Las herramientas profesionales han convergido en cuatro métodos que priorizan, según el caso, la comodidad o la robustez:
- Device Authorization Flow (resiliencia de contexto). Es la solución para cuando la terminal y el navegador no están en la misma máquina (SSH, Docker o servidores remotos). La CLI muestra un código y el servidor espera la autorización externa. Es el estándar en Vercel o Railway porque es el único que sobrevive en entornos donde no existe una conexión directa entre aplicaciones.
- Localhost callback (fricción cero). La CLI captura el login automáticamente, como en Claude Code. Es la experiencia más fluida en un ordenador personal, pero requiere que la terminal y el navegador hablen directamente, algo que los entornos corporativos a menudo bloquean.
- Pairing phrases (validación humana). En lugar de códigos abstractos, la terminal y la web muestran la misma frase aleatoria (por ejemplo, enjoy-enough-outwit-win). Stripe usa este recurso para convertir una validación de seguridad en una comprobación visual de medio segundo.
- API Keys (seguridad y automatización). El método de generar una clave y pegarla a mano. Aunque es manual, es el único viable para procesos automáticos (CI/CD) y entornos que requieren una gestión estricta de permisos o 2FA. Es el fallback de seguridad obligatorio: si todo lo demás falla, la clave manual siempre funciona.
Antes del auth: la primera ejecución también cuenta
El éxito de una CLI se decide antes de pedir el primer dato. Mientras que un mal diseño obliga al usuario a hacer deberes (configurar regiones o claves) antes de ver nada, las herramientas que dominan el ecosistema invierten la carga: primero entregan una muestra de valor y luego piden el registro.
Cuando comandos como create-next-app o supabase start generan archivos y levantan un servidor en segundos, no están simplemente configurando carpetas; están ejecutando una demostración de fuerza. Al ver algo moviéndose en su terminal, el usuario recibe una gratificación inmediata que compra su paciencia. En ese momento, el login deja de ser una barrera para convertirse en un trámite lógico para proteger o ampliar el trabajo que ya tiene delante. El diseño aquí no consiste en pedir permiso para empezar, sino en demostrar que vale la pena quedarse.
Donde muere la conversión
Incluso el mejor flujo se estrella si los detalles son malos. En la terminal, la mayoría de los errores suelen ser fallos de UX disfrazados de ingeniería.
El copia-pega de claves, por ejemplo, es una negligencia: obliga al usuario a manipular datos sensibles que acaban expuestos en el portapapeles o publicados por error. Cualquier flujo que dependa de que el usuario gestione manualmente una clave larga es una fábrica de frustración y tickets de soporte.
A esto se suma el error estratégico de exigir la cuenta antes de la instalación. Forzar a alguien a navegar por una web para generar credenciales antes de que la CLI demuestre su valor tiene un coste de conversión enorme. Lo mismo ocurre con el diseño de los errores: en una pantalla de texto, un mensaje genérico de «Fallo de autorización» es un callejón sin salida. Si el diseño no explica si el problema es el reloj del sistema o un proxy corporativo, el usuario simplemente cerrará la terminal.
Finalmente, hay que huir del espejismo de las métricas de vanidad. Celebrar las descargas en registros como npm (el repositorio público desde el que se distribuyen estas herramientas) es engañarse. Entre escaneos de seguridad y procesos automáticos, el volumen de descargas es puro ruido. En una interfaz de texto, la única métrica real de éxito no es cuánta gente descarga el paquete, sino cuántos llegan a completar el primer comando de valor. Si optimizas el número de descargas en lugar de la tasa de éxito del onboarding, estás diseñando a ciegas.
«Gratis durante la beta» no es gratis
En plena incertidumbre sobre los costes de la IA, la tentación de esconderse tras el «gratis por ahora» para no asustar es un error. La forma de gestionar la burbuja no es la ambigüedad, sino la transparencia del consumo. Si el cómputo es caro, trasládalo al diseño y no lo subvenciones: muestra límites de uso claros o permite que el usuario traiga su propia infraestructura conectando su propia API (Bring Your Own Key).
El diseño de una CLI en 2026 no consiste solo en mover datos, sino en demostrar que el valor que entregas compensa el coste de la energía que consumes. La confianza del desarrollador no se gana regalando dinero de inversores, sino ofreciendo un modelo de gasto predecible desde el primer comando. Si el usuario tiene el control sobre el taxímetro, el miedo al pago por uso desaparece: el coste deja de ser una barrera de adopción para convertirse en una variable más de su arquitectura.
El diseño de lo invisible
Si vienes del diseño UX/UI de producto, la mayoría de tus instintos son correctos, pero necesitan traducción. En la terminal no hay grids ni estados hover; la jerarquía es temporal, no espacial. La primera línea de output es tu titular y la última es tu llamada a la acción. El descubrimiento no vive en un menú lateral, sino en un –help impecable y en unos valores por defecto tan sensatos que el usuario no necesite el manual para avanzar.
Sin embargo, las reglas físicas de este entorno exigen una gestión distinta del riesgo. Aquí no existe el botón de deshacer, por lo que el diseño consiste en gestionar la irreversibilidad mediante confirmaciones explícitas o modos de prueba (–dry-run). Además, tu interfaz debe ser bilingüe: el resultado tiene que ser legible para un humano, pero procesable para una máquina. El flag –json no es un lujo decorativo; es el estándar que permite que tu herramienta deje de ser una isla y se convierta en parte de un engranaje mayor, permitiendo que otros scripts conecten con tu producto sin que nada se rompa.
Diseñar para la terminal es, en última instancia, un ejercicio de minimalismo donde la estética nunca va por delante de la compatibilidad. Respetar estándares como NO_COLOR o usar correctamente las secuencias ANSI no es un detalle técnico, es diseño inclusivo: asegura que tu herramienta funcione igual de bien en un monitor moderno que en un registro de errores o en un lector de pantalla. Si ignoras este espacio por considerarlo un tema de ingenieros, estás dejando que tu producto muera en la herramienta más importante del ecosistema actual.
Las dos referencias para tener cerca son clig.dev, que es lo más parecido a un manual que existe en el campo, y el artículo «CLI for Everybody» de Adedayo Agarau, que es la introducción en lenguaje llano para no desarrolladores.
Una CLI es una interfaz de usuario con una superficie de salida restringida. Tiene primera impresión, tiene curva de abandono, tiene voz. Las herramientas que la tratan como tal parecen sencillas sin esfuerzo. Las que no, pierden usuarios en silencio a los treinta segundos, y le echan la culpa al producto.