Vamos trazer de volta o design idiomático

 (essays.johnloeber.com)
1 pontos por GN⁺ 17 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Idiomas de design que os usuários entendem imediatamente reduzem a carga de aprendizado e possibilitam interações consistentes
  • Na era do software para desktop, interfaces como estrutura de menus e atalhos eram padronizadas graças ao sistema operacional e às diretrizes
  • Em contrapartida, na era do software baseado em navegador, a consistência das interfaces entrou em colapso com a disseminação de frameworks e implementações customizadas
  • Apple e Substack mostram casos de sucesso modernos de idiomas de design com personalização limitada e sistemas de design unificados
  • Designers de produto devem seguir idiomas existentes e priorizar clareza e consistência para avançar rumo a uma experiência de usuário padronizada em toda a web

Idiomas de design

  • A caixa de seleção é apresentada como um exemplo representativo de idioma de design que o usuário entende de imediato sem precisar aprender algo novo
    • Para perguntar se o usuário deseja permanecer conectado, várias formas de entrada seriam possíveis, mas na prática sempre se usa uma caixa de seleção
    • Isso funciona como um padrão de interação padronizado familiar tanto para usuários quanto para desenvolvedores

Interfaces homogêneas

  • A interface é o meio pelo qual o usuário interage com o sistema, e quanto menos for preciso pensar, melhor é a interface
    • Por exemplo, o atalho Command+C para copiar deveria funcionar da mesma forma em qualquer lugar
  • No ambiente atual de software web, porém, a consistência das interfaces desapareceu
    • Até funções básicas, como escolher uma data ou inserir o número do cartão, são implementadas de forma diferente em cada site
    • Como atalhos e formas de interação variam de app para app, o usuário precisa reaprender toda vez “onde clicar e o que pressionar”

A era do software para desktop

  • O software para desktop do período Windows 95~7 mantinha alta consistência de interface
    • A estrutura de menus “File, Edit, View” existia da mesma forma em todos os programas
    • Os sublinhados nos itens de menu indicavam atalhos de teclado, permitindo operar com ALT+F, N etc.
    • A barra de status (status bar) na parte inferior mostrava com clareza o estado atual (página, contagem de palavras, modo etc.)
    • Os menus eram centrados em texto, e ícones só eram usados quando tinham significado claro
  • Esses idiomas estavam padronizados não só no Microsoft Word, mas em todo o ecossistema Windows
    • Até na tela de logout do Windows XP, todos os botões eram apresentados visualmente de modo claro como botões, com atalhos exibidos
  • Essa consistência era possível graças às restrições do sistema operacional e das bibliotecas GUI, e a Microsoft distribuía centenas de páginas de diretrizes de design para induzir desenvolvedores a segui-las

A era do software no navegador

  • A era atual dos aplicativos web é descrita como uma era de interfaces heterogêneas
    • Até webapps excelentes como Figma e Linear não compartilham ícones ou atalhos em comum
    • Cada app é bem projetado por si só, mas tem padrões de interação diferentes
    • Mesmo dentro da mesma empresa, as experiências de Gmail, GSuite e Google Docs são diferentes entre si
    • Como resultado, o usuário passa tempo procurando onde operar em vez de permanecer em um fluxo produtivo (flow)

  • Impacto da transição para o mobile

    • Com o surgimento das telas sensíveis ao toque, padrões de design centrados em mouse e teclado foram reinventados
    • Na situação em que é preciso dar suporte simultâneo a mobile e desktop, proliferaram UIs imperfeitas em um formato intermediário
    • Ex.: casos em que o menu hambúrguer do mobile é usado da mesma forma também no desktop
    • A cultura de reutilização de componentes modulares replica padrões ruins e provoca queda de qualidade
    • Como resultado acumulado de mais de 10 anos, ocorreu uma erosão geracional da qualidade de UI/UX

  • Falta de idiomas além do HTML

    • Na web inicial, havia idiomas claros, como os links azuis sublinhados, mas hoje cada site tem seu próprio estilo
    • Os padrões HTML/CSS são rígidos, mas, na prática, a maioria usa sistemas de build baseados em React e TypeScript
    • Como resultado, proliferam implementações customizadas no lugar de elementos HTML padrão, causando até problemas de acessibilidade
    • Ex.: usar <span> com onclick em vez de <a> quebra recursos de leitores de tela
    • Também existem apps como o Figma, baseados em WebAssembly, que se afastam completamente do HTML
    • Funções básicas do navegador, como o botão de voltar e os atalhos, são ignoradas, e um novo paradigma de interação humano-computador é reconstruído
    • Como o desenvolvimento frontend evoluiu com foco em velocidade e possibilidades, ficou difícil consolidar idiomas consistentes
    • Há inúmeros frameworks e formatos de interação, criando um ambiente em que é estruturalmente difícil estabelecer um padrão único

Casos de sucesso do design idiomático

  • A Apple é apontada como um exemplo representativo de quem mantém fortes idiomas de design na atualidade
    • Fontes, botões, cores e todo o sistema de design são unificados, oferecendo uma experiência de interação consistente em todo o iOS
    • Essa consistência cria a confiança de que “it just works”
  • A Substack também oferece uma experiência de usuário estável por meio de personalização limitada e padrões estéticos predefinidos
    • Os princípios de design de Apple e Substack se espalham como padrões da indústria por meio de seu sucesso e acabam se estabelecendo como novos idiomas

Princípios que designers de produto devem seguir

  • Para desenvolvedores de produto, seguir idiomas de design existentes sempre que possível é apresentado como o caminho para aumentar usabilidade e compatibilidade
    • Respeitar os idiomas básicos de HTML/CSS: links devem ser implementados com sublinhado, cor, cursor de ponteiro e a tag <a>
    • Não reimplementar elementos HTML básicos com JavaScript; por exemplo, usar <button> em vez de um React Button
    • Respeitar os idiomas do navegador: o botão voltar deve funcionar, copiar a URL deve dar acesso à mesma interface, CTRL+clique deve abrir em nova aba
    • Ao se afastar de idiomas comuns, manter regras consistentes ao menos dentro da organização
    • Texto primeiro, ícones ao mínimo; ícones devem ser usados apenas quando forem universalmente compreensíveis
    • Em elementos visuais, a clareza deve vir antes da beleza estética
    • Quando for difícil decidir, consultar bons exemplos de sites e livros antigos sobre design de interface
  • Em última instância, propõe-se buscar um futuro em que seletores de data e formulários de cartão funcionem da mesma maneira em toda a web, com o objetivo de uma web que, após décadas de repetição e aprimoramento, converja para os idiomas mais adequados

Leituras relacionadas

1 comentários

 
GN⁺ 17 일 전
Comentários no Hacker News

  • Em alguns apps, Enter envia a mensagem e Ctrl+Enter insere uma quebra de linha (ex.: Slack), enquanto em outros é o contrário (ex.: GitHub)
    Essa falta de consistência é bem confusa do ponto de vista do usuário. Fala-se em “trazer de volta o design idiomático”, mas o problema é justamente a falta de convenções realmente compartilhadas

    • Antigamente, Return e Enter eram teclas diferentes. Return era para quebra de linha, e Enter para envio da entrada.
      Hoje elas foram unificadas, então, em geral, em campos de entrada multilinha o Enter insere quebra de linha e Ctrl+Enter envia.
      Já os apps de chat costumam inverter isso porque recebem muitas mensagens curtas. Apps bons deixam isso configurável
    • O Teams tem dois modos. O padrão é Enter para enviar e Shift+Enter para quebra de linha, mas, ao abrir as ferramentas de formatação, isso se inverte.
      Ele até mostra qual combinação faz a quebra de linha, mas ainda assim continua confuso
    • O Slack é ainda mais complicado. Com Markdown ativado, Shift+Enter faz quebra de linha, mas dentro de blocos de código (```) o Enter faz quebra de linha e Shift+Enter envia.
      Dá para entender a intenção, mas a usabilidade é péssima
    • A solução ideal talvez fosse Ctrl+Enter sempre enviar, Shift+Enter sempre inserir quebra de linha, e Enter seguir o padrão conforme o contexto
    • Eu também achava que Shift+Enter significava quebra de linha, e isso mostra como a UX fragmentada é o problema

  • Hoje em dia, software já não é mais feito como antes por projetistas cuidadosos.
    Em vez disso, quem conduz tudo são PMs ou responsáveis de produto promovidos às pressas, e a realidade chega a incentivar até dark patterns em nome da receita

    • Como engenheiro mobile, quando digo a stakeholders que “não dá para simplesmente construir como veio na ideia”, muitas vezes recebo olhares vazios.
      É preciso enfatizar a importância da consistência de UX e da arquitetura da informação (IA). Não podemos esquecer que designers também resolvem problemas
    • Essa crítica é simplista demais. Na prática, até criar um formulário online já é um inferno.
      Por exemplo, ao montar um formulário de cartão de crédito, há inúmeras variáveis: permitir ou não copiar/colar, compatibilidade com navegadores antigos, equilíbrio entre acessibilidade e segurança etc.
      Aliás, o texto do Steve Yegge sobre plataformas também explica bem essa complexidade
    • Nos anos 2010, muitos UX designers experientes saíram, e entrou em massa designer não especialista vindo de impressão ou design gráfico, o que reduziu a qualidade
    • Claro que há incentivos ruins e cronogramas apertados, mas é difícil explicar tudo apenas como incompetência ou má-fé. O próprio sistema mudou
    • Quando vejo PMs tentando desenhar por conta própria até a arquitetura geral e o roadmap de releases, sinto que essa observação não está errada

  • Os frameworks de sistema eram a base que produzia uma UI idiomática.
    Win32, AppKit e UIKit lidavam até com os menores detalhes, fazendo o desenvolvedor seguir naturalmente uma UX consistente.
    Já na web isso não existe, então tudo precisa ser implementado manualmente, e o resultado é uma abundância de UIs pela metade

    • Mas o autor do texto interpretou mal a inconsistência da web. A “era do desktop” foi, na prática, a era do Windows, e como o Win32 era o padrão, todos simplesmente o seguiam.
      A web nasceu centrada em documentos, sem uma abordagem padronizada, e só mais tarde surgiram padrões temporários com coisas como Bootstrap
    • Havia HTML e CSS, mas hoje muita gente contorna isso com WebAssembly e afins.
      Na verdade, seletor de data e entrada de cartão deveriam usar os controles padrão do HTML.
      Assim, o navegador pode fornecer segurança e conveniência no nível do sistema operacional (ex.: o Safari integra com Apple Wallet, e o Android com Google Pay)
    • Desenvolvedores acostumados à consistência de comportamento do sistema operacional naturalmente tentam imitar esse ambiente.
      Mas web e mobile são ambientes em caixas totalmente diferentes, então essa consistência se perdeu.
      Por exemplo, houve a chance de padronizar o clique direito do desktop como toque longo no mobile, mas isso nunca foi levado adiante de forma consistente
    • O problema fundamental da web é que ela ainda permanece num paradigma centrado em documentos.
      Para criar uma UI de app, é preciso empilhar isso por cima da UI de documentos, o que gera conflitos.
      Os navegadores amenizaram isso, mas não é uma melhoria estrutural
    • Só como observação, no AppKit também é possível alterar a altura dos botões. Só não é algo óbvio

  • O seletor de data é realmente um pesadelo de UX.
    Muitas vezes o usuário é impedido de digitar a data manualmente e forçado a clicar em tudo.
    Bastaria bloquear entradas inválidas, mas insistem em tornar a experiência incômoda

    • Quando você precisa voltar décadas no calendário para inserir a data de nascimento, bate até uma sensação da transitoriedade da vida
    • No mobile, os seletores de horário também são todos diferentes. Às vezes um scroll vai de 12:00 para 11:50, às vezes não.
      Um seletor em formato de relógio analógico parece mais intuitivo; seria bom se isso virasse padrão
    • O formato da data também é um problema. 03/04/2026 pode ser 4 de março ou 3 de abril.
      Para usuários internacionais, o formato YYYY-MM-DD é mais seguro
    • Sites que usam para data de nascimento o mesmo seletor de data pensado para agendar eventos futuros são os piores.
      Fazem você rolar 50 anos para trás e ainda sentir o peso da idade
    • Ter que perceber a própria idade no scroll toda vez que vai preencher a data de nascimento parece uma forma de tortura

  • A queda na qualidade de UX hoje é séria, especialmente em sites de bancos.
    Esconder barra de rolagem, desperdiçar espaço em branco, usar botões flat e ícones confusos tornou tudo muito mais desconfortável do que as antigas UIs de desktop

    • Esconder a barra de rolagem é algo que realmente não dá para entender. Parece uma decisão puramente estética para “ficar bonito”
    • Tenho a impressão de que o Material UI teve um impacto negativo em vários setores.
      GCP e ferramentas do Google ficaram desnecessariamente complexos, e campos de entrada sem caixas e outros elementos destruíram a UX.
      Felizmente, hoje esse estilo já começa a ser visto como ultrapassado

  • Um dos conceitos vindos dos Macs antigos era que, se o texto de um botão terminasse com reticências (…), isso significava que seria necessária uma entrada adicional.
    Já um botão sem reticências concluía a ação imediatamente ao ser clicado

  • Concordo com a ideia de “preferir palavras a ícones”.
    Para a maioria das pessoas, a velocidade de reconhecimento de palavras é maior do que a de ícones

    • Claro que ícones que representam objetos reais funcionam bem, mas hoje há muitos ícones abstratos e minimalistas demais.
      Sem um texto explicativo, você acaba clicando para descobrir o significado quase como numa roleta-russa
    • Há também casos confusos como “unvote/undown” no HN, em que o prefixo igual gera ambiguidade. Dá vontade de conferir toda vez antes de clicar
    • Se o ícone for pequeno ou mudar de posição com frequência, palavras são melhores; mas em ambientes fixos, ícones podem ser mais rápidos

  • Recentemente descobri uma nova tecnologia chamada CSS, que permite definir layout de forma declarativa e aplicar estilos hierárquicos baseados no DOM.
    Ela pode reduzir a carga no cliente e no servidor, além de facilitar o compartilhamento de folhas de estilo e temas personalizados.
    Quero chamar isso de paradigma de UI “no-framework”
    Imagem de exemplo

    • Já usei e foi um pesadelo completo. Não dá para saber qual estilo está sendo aplicado onde, e, se a estrutura do DOM muda, os estilos viram bagunça.
      Além disso, “minimizar a carga no cliente” não passa de mito. Na prática, fica mais lento
    • Talvez valha sugerir essa ideia à equipe do framework vanilla-js

  • Funcionalidades comuns que perdemos:
    Undo/Redo, ajuda (F1), dicas ao passar o mouse, personalização de atalhos, menu principal, arquivo/diretório, fechar com ESC, drag-and-drop etc.
    Recursos que um dia foram inovadores agora praticamente desapareceram no mobile e na web

  • Muitos problemas são resultado de designers visuais terem migrado para o design de produto.
    A confusão entre os papéis dentro da área de design ainda não foi resolvida, e a realidade é que até projetos que nem precisariam de “designer” recebem gente demais nessa função