Más opciones hacen que los usuarios abandonen

En pocas palabras: La fatiga por funciones y la ley de Hick hacen que más opciones suelan volver los productos más difíciles de elegir, aprender y usar. Las funciones extra pueden ayudarte a ganar en la tabla comparativa, pero a menudo empeoran la experiencia real.

Diste más a los usuarios y empeoraste el producto. Esa es la trampa de las funciones.

Los equipos siguen añadiendo capacidades porque más opciones parecen más valor. Después el usuario abre el producto y tiene que elegir, examinar, comparar y dudar a cada paso en algo que supuestamente debía ahorrarle tiempo.

La gente compra más complejidad de la que necesita

Debora Viana Thompson, Rebecca Hamilton y Roland Rust pusieron nombre al patrón en 2005: fatiga por funciones. Antes de tener el producto, las funciones adicionales lo hacen parecer capaz. Después de tenerlo, esas mismas funciones se convierten en cosas entre las que hay que elegir y abrirse paso.

Barry Schwartz abordó el mismo problema desde otro ángulo. Más elección suele generar más arrepentimiento y más evitación, no más satisfacción. William Hick midió el coste en términos más sencillos mucho antes: más opciones ralentizan las decisiones.

Aquí el problema no es el esfuerzo en general. Es el momento en que el usuario tiene demasiados caminos, funciones, ajustes o acciones, y elegir se convierte en la carga.

Esa carga aparece dos veces. Primero en la compra, cuando el producto más completo parece más seguro porque parece cubrir más casos. Después, durante el uso, cuando esa misma abundancia se convierte en menús pesados, una configuración laboriosa y dudas. Lo que ayudó al producto a ganar la comparación puede ralentizar el trabajo real una vez dentro.

La mayoría de lo que añadiste no se usa

En 2019, Pendo analizó 615 productos informáticos y encontró que el 80 por ciento de las funciones se usaba rara vez o nunca. Esa cifra importa porque las funciones sin usar no se quedan solo en el código. Aparecen en menús, ajustes, procesos de bienvenida, navegación y páginas comparativas.

Cada función es otra cosa que el usuario debe examinar y descartar o sobre la que debe decidir. Aquí los equipos se engañan. Creen que las funciones sin usar son inofensivas si la tarea central sigue funcionando. No lo son. Siguen pidiendo al usuario que separe la señal del ruido. Lo he visto en páginas de ajustes donde la gente venía a cambiar una cosa y se encontraba con quince.

También cambian la impresión que da el producto antes de que nadie use la función. Una barra de herramientas abarrotada dice que esto dará trabajo. Una página de ajustes llena dice que necesitas entender el sistema antes de confiar en él. Aunque los usuarios ignoren la mitad de los controles, siguen teniendo que entender el producto a través de todo ese desorden.

Jira se convirtió en un producto lleno de decisiones

Jira empezó como un gestor de errores. Después creció. Campos personalizados. Capas de permisos. Tipos de incidencias. Reglas de automatización. Más estados de flujo. Más módulos. Más complementos. A gran escala, muchos equipos terminan necesitando administradores solo para mantenerlo comprensible.

Todavía recuerdo cuando pasamos a Jira en Degreed. Lo que me golpeó no fue una función mala. Fue la acumulación: navegación, opciones, acciones, ajustes, elecciones por todas partes. Me resultaba pesado antes incluso de hacer aquello para lo que había entrado. Mi equipo y yo empezamos a evitarlo siempre que podíamos.

La complejidad no siempre es mala. El problema es que un producto siga entregando decisiones al usuario mucho después de que la tarea principal esté clara. Linear construyó parte de su atractivo yendo en la dirección contraria: menos decisiones personalizadas, más opciones predeterminadas, menos preguntas.

Jira es un buen ejemplo porque el dolor no es solo que exija esfuerzo. Es que sigue obligando a los usuarios a decidir cosas que nunca vinieron a decidir.

Eso no significa que toda herramienta experta deba ser sencilla en el sentido de un producto de consumo. Algunos productos realmente necesitan profundidad. El problema empieza cuando ofrecen a todo el mundo, por defecto, decisiones propias de expertos, incluso a quienes solo vinieron a hacer algo sencillo y salir.

Esa distinción importa. La profundidad no es el enemigo. La profundidad prematura sí. Si una herramienta crece con el usuario, la capacidad adicional llega cuando el contexto ya acompaña. Si vuelca todo el árbol de decisiones el primer día, hace que el usuario pague por una potencia que aún no necesita.

Esa es una razón por la que las opciones predeterminadas importan tanto aquí. Las buenas dejan que el producto tome la decisión fácil por el usuario. Las malas le devuelven toda la carga y lo llaman flexibilidad.

Cuenta las decisiones

Haz una auditoría de opciones. Cuenta las decisiones reales que pide una pantalla: elementos de navegación, acciones secundarias, filtros, pestañas, modos, ajustes anidados y cosas configurables que rara vez necesitan configurarse. Después pregunta si cada una ayuda a la tarea principal de la mayoría de los usuarios la mayoría de las veces.

Si no, elimínala. Y si no puedes porque los usuarios avanzados realmente la necesitan, mantenla fuera del camino principal hasta que el usuario la necesite de verdad.

Aquí la revelación progresiva demuestra su valor. Una opción predeterminada evidente. Un conjunto menor de primeras elecciones. Control adicional cuando el usuario lo pide o llega a necesitarlo. Eso no es empobrecer el producto. Es mover la complejidad a un momento posterior, cuando responde a una necesidad real en lugar de descargarse sobre todos de entrada.

La diferencia se siente enseguida al usar un producto construido así. El camino principal avanza. El avanzado espera. Ese suele ser el orden correcto. Pide menos al principio. Pide más cuando el usuario tenga un motivo para interesarse.

Cada opción que añades es otro momento en que el usuario puede frenarse, dudar o abandonar.