Não esconda meus controles: como controles de interface ocultos afetam a usabilidade

• Controles ocultos reduzem a usabilidade da interface do usuário
• No passado, menus visíveis na tela representaram um ponto de virada que melhorou muito a usabilidade
• Recentemente, em celulares e vários outros dispositivos, há um movimento de retorno para interações que exigem memorização
• A complexidade do design de interface e fatores estéticos são as principais causas do aumento de controles ocultos
• Designers agora precisam repensar a estrutura para expor todas as funções principais, permitindo que os usuários possam explorá-las

---

Introdução: onde está o conhecimento e a interface

• Na década de 1960, Douglas Engelbart apresentou o conceito de “o conhecimento está no mundo ou na cabeça?”
• “Knowledge in the world” significa que os controles de operação estão visíveis na interface, para que o usuário possa encontrá-los e usá-los diretamente sem depender da memória
  • Exemplo: uma interface gráfica com menus suspensos
• “Knowledge in the head” se refere a um ambiente em que o usuário precisa memorizar todos os controles e comandos
  • Exemplo: no prompt de comando do DOS, se você não souber os comandos (DIR etc.), não consegue fazer nada

Por que os controles ocultos estão aumentando e seus efeitos negativos

• À medida que a complexidade da interface aumenta, mais controles passam a ser escondidos visualmente
• À primeira vista isso pode parecer mais simples, mas, para usuários iniciantes, a operação se torna muito mais difícil
• No começo, o surgimento de menus suspensos e outros “controles visíveis” aumentou de forma revolucionária a popularização dos computadores e a produtividade
• Porém, em dispositivos móveis e eletrônicos mais novos, volta a crescer a exigência de interações baseadas em “mapas mentais” e memorização
  • Exemplo: acessar a lanterna do iPhone, ver notificações ou acionar o Apple Pay muitas vezes exige conhecer ações ocultas ou gestos específicos sem pistas adequadas

Exemplos de controles ocultos no cotidiano

• Chaves sem fio de carros e maçanetas de portas também contêm controles ocultos, de modo que, sem saber usá-los, até o acesso básico pode se tornar difícil
  • Ex.: localização da chave interna ou do buraco da fechadura escondido, sequências específicas de botões etc.
• Sistemas de navegação automotiva (como Apple Maps no CarPlay) também tendem a esconder controles essenciais para mostrar o mapa de forma mais ampla, exigindo saber tocar em áreas específicas para usar certas funções
• Controles baseados em tempo também funcionam como controles ocultos
  • Ex.: o botão de energia do computador só desliga corretamente ao ser pressionado por mais tempo; a trava de uma fechadura eletrônica exige uma tecla separada ou manter pressionado por um tempo como forma especial de operação

Problemas gerais causados por controles ocultos e impacto até em usuários avançados

• Mesmo com o volume em 0, aplicativos ainda podem emitir som por causa de “configurações ocultas”, sobrescrevendo comandos diretos do usuário
• Até usuários avançados sofrem forte dependência de “knowledge in the head” em interfaces baseadas em comandos (como R, prompt do DOS etc.)
• Há uma tendência gradual de retorno a interfaces mais primitivas

Por que os controles ocultos estão aumentando

• Há funções demais, o que torna impossível mostrar tudo na tela, reduzindo a visibilidade
• Interações entre modos do sistema, aumento da complexidade e a busca do designer por estética ou facilidade de implementação fazem com que a ocultação de controles se torne frequente
• Na prática, isso costuma acontecer porque objetivos de design (como acabamento estético) são priorizados acima da consideração com o usuário

Casos bem-sucedidos e a diferença dos sistemas de missão crítica

• Alguns sistemas, como a navegação da General Motors, deixam todos os controles necessários sempre bem visíveis na tela, facilitando a exploração mesmo para iniciantes
  • Ex.: função de zoom por meio de um dial físico no Buick LaCrosse
• Em sistemas de missão crítica (aviões, fábricas etc.), o design é feito quase sempre com base em controles permanentemente visíveis
  • Ninguém aceitaria o risco de um controle oculto atrapalhar uma operação rápida

A defesa das interfaces ocultas e seus limites

• Controles ocultos não são uma questão de reclamação entre gerações, mas sim um problema real de usabilidade
• Alguns defendem a exploração de “funções escondidas” como uma vantagem, mas, na prática, a perda de acessibilidade é evidente
• Do ponto de vista do usuário, um controle que não pode ser encontrado é como se não existisse

Computação ubíqua e a automatização/transparência dos controles

• Mark Weiser e Donald Norman previram um futuro em que a tecnologia operaria de forma “transparente”, recuando para o plano de fundo
  • Ex.: o controle do motor do carro é totalmente ajustado em segundo plano para que o usuário não precise operá-lo
• Em casos em que a automação oculta completamente os controles, a necessidade e o contexto são claros
  • Mas, quando a ação do usuário é necessária, controles explícitos são indispensáveis

Conclusão e direção para designers de interface

• Designers de interface devem evitar o uso de controles ocultos e migrar todas as funções para uma lógica baseada em “knowledge in the world”
• A descoberta de controles (discoverability) continua sendo um princípio central de design
• Nas interfaces modernas, a perda de discoverability representa, na verdade, um retrocesso aos primórdios da computação

Referências

• Engelbart, D.C. (1962) e outras obras fundamentais
• Citações de livros e artigos relacionados, como Apple Macintosh, The Psychology of Everyday Things e The Invisible Computer

Sobre o autor

• Philip Kortum: professor do departamento de ciências psicológicas da Rice University, pesquisa o desenvolvimento de sistemas centrados em usabilidade em diversas áreas, como avaliação de confiabilidade, saúde global e sistemas móveis

[GN⁺]

Comentários do Hacker News

• Compartilhamento de experiências de usuários que se sentem incomodados com designs que escondem a barra de rolagem; menção de que alguns exemplos de botões físicos intuitivos citados no artigo têm limitações de custo e praticidade; sensação de confusão ao encontrar chaves de alternância cujos rótulos indicavam o estado para o qual seriam mudadas, e não o estado atual
  • Também há quem não goste de chaves toggle reais por serem ambíguas; caixas de seleção ou botões pressionados são muito mais claros, e é uma pena que isso tenha sido sacrificado pela tendência de modernização
  • Lembrança de uma chave toggle de validação imediata em uma máquina de bilhetes de trem na Áustria que causou confusão; as barras de rolagem também estão finas demais, a ponto de parecer que é preciso até habilidade de jogo FPS; às vezes a barra de rolagem horizontal também é mais conveniente; crítica ao Firefox e ao padrão CSS
  • No macOS, há a observação de que é possível sempre mostrar as barras de rolagem pelas configurações do sistema ou por comando no terminal
  • Se o toggle representa uma ação, ele deve obrigatoriamente usar um verbo ("TURN ON") para ficar claro; para mostrar estado, também se sugere uma forma explícita como "IS ON"; tirando raríssimos casos ambíguos no contexto, usar verbos quase sempre resolve
  • Também pedem suporte a PgUp e PgDn
• Alguém dirige um Toyota antigo e diz que todos os controles estão sempre visíveis, claramente rotulados e distinguíveis ao toque; considera isso fácil de replicar e algo que exige engenharia mínima, mas acha que a maioria das montadoras atuais não consegue nem isso, avaliando que lhes falta competência
  • Há concordância parcial, mas defender que "todos os controles precisam estar visíveis" subestima os designers; na prática, só os controles realmente necessários durante a direção ficam expostos, enquanto os demais são pequenos, complexos ou escondidos; a alavanca de ajuste de altura do banco, a alavanca de abertura do capô etc. ficam ocultas, mas acessíveis; a posição é que projetar com tantos detalhes não é simples nem trivial, e tratar isso como algo simples é justamente parte do motivo de a UX atual piorar
  • Outra visão é que isso não é questão de competência, mas de custo: hoje uma touchscreen sai mais barata e é mais fácil de fabricar do que produzir e montar muitos botões e knobs separados
  • Compartilhamento da experiência de ter recebido muitas ofertas de trabalho como desenvolvedor de sistemas de montadoras americanas, mas de ter visto no Hacker News muitas opiniões do tipo “se quiser preservar sua saúde mental, evite”
  • Explicação pessoal de que fazer peças mecânicas como knobs em formatos diferentes aumenta o custo de fabricação, por exemplo com moldes customizados; colocar tudo na tela é muito mais eficiente em custo
• Entende-se esconder elementos de UI para eficiência do espaço de tela, mas esconder deixando o espaço vazio é algo sem justificativa; no IntelliJ, há ícones acima da árvore do projeto que ficam escondidos e só aparecem ao passar o mouse, e fica a dúvida se havia mesmo necessidade disso
  • Questionamento sobre a justificativa de esconder elementos de tela justamente numa época em que telas de celular, desktop e notebook estão maiores do que nunca; lembrança de que até o Macintosh de 1984, com tela pequena em preto e branco, colocava botões mesmo sacrificando proporção da tela em nome de clareza e visibilidade
  • Algumas pessoas reclamam que o “ruído” visual atrapalha a concentração, enquanto outras querem todos os controles e indicadores sempre visíveis como em um painel; as configurações padrão de IDEs acabam sendo um meio-termo para tentar atender esses gostos extremos; na prática é um compromisso, e algumas ferramentas oferecem modos como "no distractions mode" com ajustes detalhados
  • No IntelliJ para Windows, o menu também fica escondido dentro do ícone de hambúrguer, criando muito espaço vazio; felizmente dá para restaurar nas configurações, mas o padrão é difícil de entender
  • Mesmo sabendo que o botão existe e lembrando como fazê-lo aparecer, às vezes a pessoa esquece onde ele estava e fica olhando para a tela em branco
  • Em alguns apps acontece o contrário: em vez de esconder botões extras, a pessoa gostaria de ter uma opção para escondê-los; menção ao Google Maps
• Crítica à engenharia pouco amigável ao usuário em carros com smart key, em que a chave física fica escondida e às vezes é preciso até desmontar a maçaneta para encontrar o buraco da chave; esconder controles importantes seria extremamente hostil ao usuário
  • Outra pessoa relata ter passado por algo parecido em um carro alugado: a chave remota quebrou e toda a bagagem ficou presa no carro; sabia que existia uma chave física, mas só conseguiu descobrir onde ficava o miolo pela área ao redor da maçaneta, cheia de arranhões deixados por usuários anteriores tentando abrir
  • Há quem diga que esse tipo de informação é algo que o usuário deveria saber por padrão e pode procurar no Google; exemplo de ter recebido um carro novo e imediatamente verificado as opções de backup e como funcionavam, enfatizando a importância de conhecer o básico do que se possui
• Um dos motivos para ter saído do iPhone depois do desaparecimento do botão Home e ido para Android foi que ficou mais difícil explicar e usar com familiares idosos; ao comprar um novo Pixel, a pessoa ativa primeiro a navegação de 3 botões, mas critica que muitos apps atuais pressupõem só a barra de navegação inferior e acabam tendo conteúdo coberto pelos 3 botões
  • Defesa de que elementos centrais da UI precisam estar visíveis; considera que a Apple às vezes viola esse princípio, mas na maior parte do tempo resiste; a remoção do botão Home é interpretada não tanto como ocultação de elemento de UI, mas como transformação da interação; pode haver debate sobre o quanto isso é intuitivo ou excelente, mas, depois da adaptação, quase não há atrito no uso; menção ao recurso de acessibilidade do iOS com um pequeno atalho circular arrastável na tela, com rótulos de texto
  • O desaparecimento silencioso de itens de menu em softwares em geral é visto como fenômeno parecido; exemplo do MS Word, em que o ícone para salvar um arquivo somente leitura simplesmente sumiu; a sugestão é que seria melhor deixá-lo desativado e, ao salvar, informar o motivo e orientar como resolver
  • Um usuário de longa data de Android diz que, sempre que pega um iPhone emprestado, sente frustração com interações pouco intuitivas ou inexistentes; como a qualidade de câmera de Pixel e Samsung também melhorou, não vê motivo para migrar para o ecossistema Apple
• Opinião de que o artigo não tratou adequadamente do fato de que o desaparecimento da UI não é acidente nem erro, mas um fenômeno de lock-in do usuário; interpretação de que softwares que chegaram ao ponto de saturação mudam a UI de forma menos intuitiva para evitar que usuários antigos saiam; o dispositivo deixa de ser algo que se “usa” e passa a ser algo “internalizado”, criando barreiras de saída; o processo de aprender a UI induziria medo de mudar para outro produto, e isso explicaria por que a maioria das grandes empresas de software segue esse caminho
  • Essa hipótese pode fazer sentido em recortes isolados, mas há também muita reação contra “interfaces complexas e lotadas”; a tendência do minimalismo e comunidades como /r/unixporn mostram que muitos usuários também escolhem esconder controles por conta própria; GNOME e outros seguem a onda de interfaces minimalistas; muitos usuários conseguem achar e usar funções só quando precisam, então isso também pode ser visto como uma escolha
  • É uma faca de dois gumes, porque dificulta a entrada de usuários novos; relato de alguém que prefere Android justamente por não gostar da concentração de todas as interações da Apple em um único botão; há ainda outras razões separadas para a antipatia com a Apple
  • Mesmo em OSS sem fins lucrativos, parece haver adoção acrítica dessas tendências; as mudanças frequentes de design do Firefox e o GNOME entram no mesmo contexto
• Quando designers do tipo “artista” ficam com o poder de decidir a UI, acabam obcecados por limpeza visual e ignoram affordance e oportunidades de aprendizado; o cockpit de avião, esmagador para não especialistas mas com tudo rotulado para especialistas, é citado como contraste representativo
  • Há a réplica de que até uma torneira doméstica comum não precisa de rótulo para indicar direção; o cockpit de avião, para iniciantes, é justamente um exemplo de excesso esmagador; designers de interface entendem bem o que é intuitivo e têm a habilidade de condensar funções complexas em form factors simples; achar que alguém sem formação em design produziria resultados melhores seria apenas arrogância e desdém; destaca-se que muitos usuários usam smartphones modernos com habilidade mesmo sem treinamento, o que seria um grande sucesso
• Desabafo relacionado do Hacker News sobre software desktop e pergunta sobre a situação atual
• Um dos princípios de design de UI na empresa de alguém é que atalhos de teclado e menus de contexto sempre precisam ser acessíveis por um botão ou menu claramente visível; é um jeito talvez meio old-fashioned, mas considerado importante; os quatro cantos da tela são áreas centrais da UI porque o mouse chega rápido até eles, e mover o menu Iniciar para o centro no Windows 11 é citado como exemplo de incômodo para o usuário; talvez isso venha de uma política orientada a toque, não a desktop
• Ênfase em como a perda de acessibilidade e de intuitividade da UI afeta fortemente pessoas com deficiência e idosos; embora toque e gestos tenham virado padrão, argumenta-se que as UIs móveis iniciais eram mais acessíveis; a tendência excessivamente minimalista e flat seria a causa principal; há uma lembrança positiva de palm, compaq pilot, iPod e da UI dos primeiros iPhones, e a avaliação é de que depois disso houve retrocesso
  • Em contraste, também há a visão de que, como ao ler comentários do HN no celular, esconder vários controles de UI permite focar mais no conteúdo e deixa a experiência mais bonita e agradável; na época do Palm Pilot, botões e controles ocupavam metade da tela e reduziam demais a área de conteúdo; controles ocultos não são necessariamente ruins e, uma vez aprendidos, podem ser ferramentas poderosas para usuários avançados; exigir algum aprendizado de UI do usuário é inevitável até certo ponto, e em ferramentas poderosas como editor de código ou git existe um trade-off entre simplicidade e poder; por outro lado, é problemático que hoje tantos apps usem controles customizados próprios, reduzindo a transferência de aprendizado entre UIs; um modelo como o da plataforma Palm Pilot, em que se aprende uma vez e isso vale para todos os apps, seria o ideal