No escondan mis controles: cómo los controles ocultos de la interfaz afectan la usabilidad

• Los controles ocultos deterioran la usabilidad de las interfaces de usuario
• En el pasado, los menús visibles en pantalla marcaron un punto de inflexión que mejoró enormemente la usabilidad
• En móviles y otros dispositivos recientes, está resurgiendo una lógica de uso que vuelve a exigir operación basada en la memoria
• La complejidad del diseño de interfaces y los factores estéticos son las causas principales del aumento de controles ocultos
• Ahora los diseñadores deben replantear la estructura para hacer visibles todas las funciones principales y permitir que los usuarios las descubran

---

Introducción: la ubicación del conocimiento y la interfaz

• En la década de 1960, Douglas Engelbart planteó la idea de “si el conocimiento está en el mundo o en la cabeza”
• “knowledge in the world” significa que los controles de operación están visibles en la interfaz, de modo que el usuario puede encontrarlos y usarlos directamente sin tener que recordarlos
  • Ejemplo: una interfaz gráfica con menús desplegables
• “knowledge in the head” se refiere a un entorno en el que el usuario debe memorizar todos los controles y comandos
  • Ejemplo: en el símbolo del sistema de DOS, si no conoces comandos como DIR, no puedes hacer prácticamente nada

Por qué aumentan los controles ocultos y sus efectos negativos

• A medida que aumenta la complejidad de la interfaz, cada vez más controles quedan ocultos visualmente
• En apariencia puede verse más limpio, pero para los usuarios principiantes operar resulta mucho más difícil
• La aparición de menús desplegables y otros “controles visibles” impulsó de forma decisiva la masificación de la computadora y la productividad
• Sin embargo, en dispositivos móviles y electrónicos recientes vuelve a expandirse una situación en la que se exige una operación basada en un “mapa mental” recordado
  • Ejemplo: funciones como la linterna del iPhone, ver notificaciones o activar Apple Pay solo son accesibles si se conocen de antemano acciones ocultas o gestos específicos, sin pistas adecuadas

Ejemplos de controles ocultos en la vida cotidiana

• También hay controles ocultos en llaves inalámbricas de autos y manijas de puertas, por lo que, si no sabes cómo se usan, incluso el acceso básico puede volverse difícil
  • Ejemplo: la ubicación de la llave interna, el ojo de cerradura escondido o ciertas secuencias de botones
• Los sistemas de navegación del vehículo (como Apple Maps en CarPlay) también tienden a ocultar controles esenciales para mostrar el mapa más grande, por lo que solo puedes usar ciertas funciones si sabes que debes tocar una zona específica
• Los controles basados en el tiempo también funcionan como una forma de control oculto
  • Ejemplo: el botón de encendido de la computadora solo apaga correctamente si se mantiene presionado, y el bloqueo de una cerradura electrónica puede requerir una tecla aparte o una pulsación larga

Problemas generales causados por los controles ocultos y su impacto incluso en usuarios expertos

• Incluso si el volumen está en 0, algunas apps emiten sonido por decisión propia; estos “ajustes ocultos” terminan anulando la orden directa del usuario
• Incluso los usuarios avanzados experimentan una fuerte dependencia del “knowledge in the head” en interfaces de comandos (por ejemplo, R o una ventana de DOS)
• Hay una tendencia gradual a regresar a interfaces más primitivas

Por qué aumentan los controles ocultos

• Hay tantas funciones que ya no es posible mostrarlas todas en pantalla, lo que reduce la visibilidad
• La interacción entre modos del sistema, el aumento de la complejidad y la búsqueda de estética o facilidad de implementación por parte del diseñador hacen que ocultar controles sea cada vez más frecuente
• En la práctica, esto suele ocurrir porque se priorizan objetivos de diseño (como la estética visual) por encima de la consideración hacia el usuario

Casos exitosos y la diferencia con los sistemas de misión crítica

• Algunos sistemas, como la navegación de General Motors, mantienen siempre visibles todos los controles necesarios en pantalla, lo que facilita la exploración incluso para principiantes
  • Ejemplo: la función de zoom mediante la perilla física del Buick LaCrosse
• En sistemas de misión crítica (aviones, fábricas, etc.), el diseño casi siempre se basa en controles permanentemente visibles
  • Nadie acepta el riesgo de que controles ocultos dificulten una operación rápida

La defensa de las interfaces ocultas y sus límites

• Los controles ocultos no son un tema de quejas entre generaciones, sino un problema real de usabilidad
• Algunos promueven como ventaja el hecho de explorar “funciones ocultas”, pero en realidad la pérdida de accesibilidad es evidente
• Desde la perspectiva del usuario, un control que no se puede encontrar es igual a uno que no existe

Computación ubicua y automatización/transparencia de los controles

• Mark Weiser y Donald Norman anticiparon un futuro en el que la tecnología funcionaría de manera “transparente”, pasando al fondo
  • Ejemplo: el control del motor de un automóvil se ajusta automáticamente por completo en segundo plano, sin necesidad de intervención del usuario
• En los casos en que la automatización hace que un control quede completamente oculto, la necesidad y el contexto están claros
  • Pero cuando se requiere la acción del usuario, deben existir controles explícitos

Conclusión y dirección para los diseñadores de interfaces

• Los diseñadores de interfaces deben evitar el uso de controles ocultos y llevar todas las funciones hacia un modelo basado en conocimiento visible en el mundo
• La capacidad de descubrimiento (discoverability) sigue siendo un principio central de diseño
• La pérdida de discoverability en las interfaces modernas es, de hecho, una regresión hacia la era de las primeras computadoras

Referencias

• Engelbart, D.C. (1962) y otras referencias clave
• Citas de libros y artículos relacionados como Apple Macintosh, The Psychology of Everyday Things y The Invisible Computer

Información del autor

• Philip Kortum: profesor del Departamento de Ciencias Psicológicas de Rice University; investiga el desarrollo de sistemas centrados en la usabilidad en campos como la evaluación de confianza, la salud global y los sistemas móviles

[GN⁺]

Opiniones de Hacker News

• Se comparte la experiencia de usuario de quienes últimamente sienten incomodidad con diseños que ocultan la barra de desplazamiento; también se menciona que algunos ejemplos del artículo sobre perillas físicas intuitivas tienen límites de costo y practicidad, y que resultó confuso encontrarse con etiquetas en interruptores tipo toggle que indicaban el estado al que cambiarían y no el estado actual.
  • También hay una postura de rechazo a los interruptores toggle reales por su ambigüedad; las casillas de verificación o los botones presionados son mucho más claros, pero da pena que hayan sido sacrificados por la tendencia a modernizar.
  • Se recuerda una experiencia confusa con un interruptor toggle de validación inmediata en una máquina expendedora de boletos de tren en Austria; además, las barras de desplazamiento son tan delgadas que parece que hasta hiciera falta habilidad de FPS, y a veces una barra de desplazamiento horizontal resulta más conveniente; también se lanza una crítica a Firefox y al estándar CSS.
  • En macOS se indica que es posible mostrar siempre las barras de desplazamiento desde la configuración del sistema o con un comando de terminal.
  • Si el toggle representa una acción, debería usar necesariamente un verbo ("TURN ON") para que quede claro; si muestra un estado, se propone una forma explícita como "IS ON". Salvo unos pocos casos muy ambiguos por contexto, se considera que usar verbos casi siempre aclara todo.
  • También piden soporte para PgUp y PgDn.
• Hay quien conduce un Toyota viejo y destaca que todos los controles están siempre visibles, claramente etiquetados y se distinguen al tacto; lo ve como algo fácil de replicar y de ingeniería mínima, pero considera que la mayoría de las automotrices actuales ni siquiera logran eso y evalúa que les falta capacidad.
  • Hay acuerdo en parte, pero se sostiene que afirmar que "todos los controles deben verse" subestima a los diseñadores; en la práctica, solo se exponen los controles imprescindibles al conducir y el resto se hace pequeño, complejo u oculto. Palancas como la de ajuste de altura del asiento o la de apertura del cofre están ocultas, pero siguen siendo accesibles; se argumenta que el proceso de diseño considerando tantos detalles no es simple ni trivial, y que tratarlo como si lo fuera es más bien una de las razones del deterioro actual del UX.
  • Otra visión es que no se trata de capacidad, sino de costos: hoy una pantalla táctil es más barata y más fácil de fabricar que producir y ensamblar muchos botones y perillas por separado.
  • Se comparte la experiencia de haber recibido muchas ofertas de contratación como desarrollador de sistemas por parte de fabricantes de autos en EE. UU., pero que en la comunidad de Hacker News abundaban opiniones como “si quieres conservar tu salud mental, aléjate”.
  • También se explica que, si se fabrican perillas u otras piezas mecánicas distintas, aumentan los costos de manufactura por moldes personalizados y similares; meterlo todo en pantalla es mucho más eficiente en costos.
• Se entiende ocultar elementos de UI para aprovechar mejor el espacio, pero no se acepta esconderlos y dejar ese espacio vacío; en IntelliJ, por ejemplo, hay íconos sobre el árbol del proyecto que solo aparecen al pasar el mouse, y se cuestiona si realmente era necesario hacerlo así.
  • En una época en la que las pantallas de móviles, escritorios y laptops son más grandes que nunca, se cuestiona la justificación para ocultar elementos de pantalla; se recuerda que incluso la pequeña pantalla monocromática del Macintosh de 1984 sacrificaba proporción de pantalla para colocar botones en favor de la claridad y la visibilidad.
  • Algunas personas se quejan de que el “ruido” visual afecta la concentración, mientras que otras quieren tener siempre visibles todos los controles e indicadores como en un tablero; la configuración predeterminada de un IDE es un compromiso para equilibrar esos gustos extremos y, en los hechos, una negociación. Algunas herramientas ofrecen modos como "no distractions mode" con ajustes más detallados.
  • En la versión de Windows de IntelliJ, el menú también queda escondido dentro de un ícono de hamburguesa y sobra mucho espacio vacío; por suerte puede restaurarse desde la configuración, pero el valor predeterminado resulta incomprensible.
  • Incluso sabiendo que un botón existe y recordando cómo aparece, a veces igual se olvida dónde estaba y uno se queda mirando la pantalla en blanco.
  • Algunas apps más bien no ocultan botones adicionales, y hasta dan ganas de que existiera una opción para esconderlos; se menciona Google Maps.
• Se critica que, al usar una llave inteligente de auto, la llave real quede escondida e incluso haya que desmontar la manija de la puerta para encontrar la cerradura; ocultar controles importantes así se considera una ingeniería muy poco amable con el usuario.
  • Otra persona cuenta una experiencia parecida con un auto rentado: falló el control remoto y todo su equipaje quedó atrapado dentro del coche. Sabía que existía una llave física, pero pudo ubicar enseguida el agujero de la cerradura porque alrededor de la manija estaban las marcas de rayones dejadas por usuarios anteriores que habían intentado abrirla.
  • También se argumenta que este tipo de situaciones son cosas que el usuario debería conocer por defecto y que esa información puede encontrarse en Google y otros lugares; se da como ejemplo haber verificado de inmediato las opciones de respaldo y cómo funcionan al recibir un auto nuevo, enfatizando la importancia de conocer lo básico de los productos que uno posee.
• Se comenta que una de las razones para pasar de iPhone a Android fue que, al desaparecer el botón de inicio, se volvió más difícil explicar y usar el dispositivo para familiares mayores; al comprar un Pixel nuevo, primero activan la navegación de 3 botones, pero critican que muchas apps actuales solo asumen la barra de navegación inferior y terminan tapando contenido cuando se usa el esquema de 3 botones.
  • Se insiste en que los elementos centrales de la UI deben estar necesariamente visibles. Se considera que Apple a veces también viola ese principio, aunque en general suele resistirse más; la eliminación del botón de inicio se interpreta menos como ocultar un elemento de UI y más como una transformación de la interacción. Puede discutirse si fue intuitivo o excelente, pero una vez que uno se adapta, casi no genera fricción al usarlo. También se menciona la función de accesibilidad de iOS que permite tener en pantalla un pequeño acceso directo circular arrastrable con etiqueta de texto.
  • Algo similar ocurre con elementos de menú que desaparecen silenciosamente en software común; por ejemplo, en MS Word desapareció por completo el ícono para guardar un archivo de solo lectura. Se propone que sería mejor dejarlo desactivado y, al intentar guardar, explicar la causa y cómo resolverla.
  • Un usuario de Android de muchos años comenta que, cada vez que le toca pedir prestado un iPhone, termina frustrado por interacciones poco intuitivas o inexistentes; además, como la calidad de cámara de Pixel y Samsung ya es muy buena, no ve razones para pasarse al ecosistema de Apple.
• Se opina que el artículo no abordó bien que la desaparición de la UI no es accidental ni un error, sino un fenómeno pensado para generar lock-in del usuario. Se interpreta que, en software que ya llegó a un punto de saturación, se cambia la UI de forma poco intuitiva para evitar que los usuarios actuales se vayan; así el dispositivo deja de ser algo que uno “usa” y pasa a ser algo “interiorizado”, creando una barrera de salida. Se explica que el proceso de aprender esa UI induce miedo a cambiar de producto y que por eso la mayoría de las grandes empresas de software adopta esta estrategia.
  • Se responde que esa hipótesis puede parecer cierta si se mira de forma fragmentaria, pero que en la práctica también hay mucho rechazo a las “interfaces complejas y abarrotadas”; además, la tendencia al minimalismo y comunidades como /r/unixporn muestran que muchos usuarios también tienden por cuenta propia a ocultar controles. GNOME y otros reflejan igualmente que la interfaz mínima está de moda, y se interpreta que muchos usuarios saben encontrar funciones solo cuando las necesitan.
  • También se señala que este enfoque es un arma de doble filo porque dificulta atraer usuarios nuevos; alguien comparte que Android le resulta más natural precisamente porque no le gusta que todas las interfaces de Apple se concentren en un solo botón, además de otras razones separadas para su rechazo a Apple.
  • Se percibe que incluso en OSS sin fines de lucro se siguen estas tendencias sin mucho cuestionamiento; se menciona en ese contexto los cambios de diseño frecuentes en Firefox y también GNOME.
• Se plantea que cuando diseñadores de tipo “artista” toman las decisiones de UI, se obsesionan con la limpieza visual e ignoran la usabilidad intuitiva (affordance) y las oportunidades de aprendizaje; como contraste representativo se menciona la cabina de un avión, que para un no experto abruma, pero para un experto tiene todo etiquetado.
  • Como contraargumento, se dice que ni siquiera un grifo doméstico común necesita etiquetas de dirección; y que una cabina de avión resulta más bien excesivamente abrumadora para principiantes. Se defiende que los diseñadores de interfaces sí saben bien qué resulta intuitivo y tienen la capacidad de condensar funciones complejas en formas simples; pensar que alguien sin formación en diseño obtendría mejores resultados no sería más que arrogancia y desprecio. Se subraya que el hecho de que muchas personas usen con soltura smartphones modernos sin entrenamiento es, de hecho, un gran logro.
• Rant relacionado de Hacker News sobre software de escritorio y pregunta sobre la situación actual
• Uno de los principios de diseño de UI de su empresa es que los atajos de teclado y los menús contextuales siempre deben poder alcanzarse también desde un botón o menú claramente visible; puede parecer algo anticuado, pero se enfatiza su importancia. También se destaca que las cuatro esquinas de la pantalla son zonas clave de la UI porque el mouse puede llegar rápido, y se menciona el traslado del menú Inicio al centro en Windows 11 como ejemplo de algo incómodo para el usuario; quizá responda a una política prioritaria de toque antes que de escritorio.
• Se enfatiza que la accesibilidad y la pérdida de intuitividad en la UI afectan mucho a personas con discapacidad y adultos mayores. Aunque el toque y los gestos se volvieron la norma, se señala que la UI móvil inicial era incluso más accesible; la tendencia excesivamente minimalista y plana se considera la causa esencial. Se recuerdan positivamente sistemas de UI de palm, compaq pilot, iPod y los primeros iPhone, y se evalúa que desde entonces más bien ha habido una regresión.
  • En contraste, también hay quien piensa que, como al ver comentarios de HN desde el teléfono, resulta más bello y cómodo que varios controles de UI estén ocultos para poder concentrarse en el contenido real. Se señala que en la era de palm pilot los botones y controles ocupaban la mitad de la pantalla y reducían demasiado el área de contenido. Se valora que los controles ocultos no son necesariamente malos y que, una vez aprendidos, pueden ser herramientas muy poderosas para usuarios expertos. Se considera además que exigir cierto aprendizaje de la UI es hasta cierto punto inevitable y que en herramientas potentes como su editor de código o git siempre existe una compensación entre simplicidad y potencia. Aun así, se critica que últimamente cada app personalice demasiado sus propios controles y se pierda la transferibilidad del aprendizaje de UI; se considera ideal una estructura como la de palm pilot, donde una vez aprendido el sistema, todas las apps se usan igual.