Há pouco tempo me deparei com o estudo de caso de Kent Sullivan de 1996 sobre o design da interface do Windows 95, e lê-lo foi como encontrar uma carta de uma era mais civilizada. Sullivan entrou para a equipe de UI do Windows 95 em 1992 e passou anos documentando como o time conduziu o redesign do sistema operacional mais usado do mundo. O paper descreve prototipagem iterativa, testes em laboratório com usuários reais, bancos de dados formais para rastrear problemas, estudos de campo. Descreve uma equipe de cerca de doze pessoas — designers de produto, designers gráficos, especialistas em usabilidade, cientistas da computação — trabalhando juntas com um único objetivo: tornar o Windows mais fácil de usar para as pessoas.
Só isso. Era esse o objetivo.
Nenhuma menção a otimizar métricas de engajamento. Sem dark patterns para enganar usuários a ativar telemetria. Sem spam de notificações. Sem a conversão sorrateira de contas locais em dependentes da nuvem. Sem botões de “IA” aparafusados em cada superfície. Apenas pessoas observando outras pessoas usando um computador, anotando o que viam e voltando para consertar o que estava quebrado.
O paper é quase ingênuo de tão simples.
O processo que criou o botão Iniciar
O que mais me impressiona é o rigor. A equipe do Windows 95 não chutava soluções — primeiro ela media os problemas. Identificou as vinte tarefas mais frequentes que os usuários realizavam no Windows 3.1 e então conduziu estudos de laboratório comparando como as pessoas executavam essas mesmas tarefas no sistema antigo e no novo. Quando os primeiros resultados foram ruins (e foram), a equipe não entrou em pânico. Realizou um offsite, revisou todos os dados coletados até então — estudos de linha de base, entrevistas, pesquisa de mercado, ligações de suporte — e chegou a uma conclusão que apavoraria a maioria dos gerentes de produto modernos: um sistema verdadeiramente utilizável talvez não se parecesse nem se comportasse como o Windows 3.1.
A barra de tarefas talvez seja o melhor exemplo desse processo em ação. A primeira tentativa da equipe de melhorar o gerenciamento de janelas foi modesta: transformar janelas minimizadas de pequenos ícones em “tiles” maiores, na esperança de que alvos maiores fossem mais fáceis de encontrar. Não funcionou. Os usuários continuavam com os mesmos problemas de antes. O problema de verdade, mostravam os dados, era que as janelas nem sempre estavam visíveis — as pessoas não conseguiam saber o que estava aberto nem alternar rapidamente entre tarefas. Então a equipe criou a barra de tarefas persistente: cada aplicativo em execução ganhava um botão que ficava sempre na tela, sempre acessível. Testaram. Funcionou. Entregaram.
Nenhum comitê de VPs debateu se a barra de tarefas deveria exibir anúncios. Ninguém perguntou se ela poderia recomendar pesquisas no Bing. Ela simplesmente resolveu um problema do usuário, de forma limpa e eficiente.
Ao final do projeto, a equipe havia rastreado centenas de problemas de usabilidade em um banco de dados formal. 81% foram resolvidos, 8% parcialmente corrigidos e apenas 11% deixados em aberto — geralmente por limitações técnicas, não por falta de interesse. Talvez o detalhe mais revelador: literalmente nada do design original da interface sobreviveu inalterado até o produto final. Tudo foi iterado, testado, refeito. A equipe entendia que não acertar de primeira era tão valioso quanto acertar.
A geração que devorou seus próprios affordances
A interface do Windows 95 estabeleceu uma linguagem visual que uma geração inteira internalizou sem perceber. Botões tinham relevos e sombras, para parecerem objetos que se podia apertar. Controles desabilitados ficavam acinzentados. Itens de menu com reticências indicavam que uma caixa de diálogo estava por vir; itens sem reticências executavam a ação imediatamente. Letras sublinhadas em cada rótulo indicavam o atalho de teclado. Os affordances estavam por toda parte, consistentes e autodocumentados.
Essa geração cresceu e virou designers. E porque foram criados em um ambiente onde a interatividade era óbvia, assumiram que ela era intrínseca. Claro que você sabe que aquilo é um botão — é um botão. Por que ele precisa parecer um?
Widget por widget, relevo por relevo, os affordances foram removidos. Gradientes substituíram contornos. Textos explicativos desapareceram. Manuais viraram folhetos, depois um papelzinho com uma URL. O design flat chegou e decretou que todos os indícios visuais eram poluição. O que os substituiu foi a elegância — o tipo de elegância que deixa um screenshot lindo numa apresentação de keynote, mas que faz humanos de verdade taparem uma superfície de vidro na esperança de que algo aconteça.
O Force Touch da Apple talvez seja o exemplo máximo disso. Uma funcionalidade em que pressionar mais forte a tela faz algo diferente de pressionar suavemente. Como alguém descobriria isso? O clique direito no Windows 95 tinha um problema semelhante de descoberta em teoria, mas na prática ter um segundo botão físico no mouse — bem ali, ao lado do primeiro — tornava muito mais fácil de encontrar por acidente. O Force Touch era uma interação fantasma.
O iOS escondeu a barra de rolagem. Depois escondeu a barra de abas na parte inferior do Safari — é preciso rolar para cima para ela reaparecer. Pessoas relatam rolar até o topo de uma página só para acessar a navegação, sem saber que existe uma barra oculta embaixo. Esses não são casos extremos. São interações centrais tornadas invisíveis em nome da limpeza visual.
Otimizado para a empresa, não para o usuário
O paper do Windows 95 descreve uma equipe otimizando para o usuário. Hoje, a maioria das decisões de UI é otimizada para o resultado financeiro da empresa. A distinção é sutil na conversa e enorme na prática.
O Windows moderno insiste em te convencer a não mudar de navegador. Infiltra anúncios no menu Iniciar. Te pressiona a criar uma conta Microsoft e depois torna quase impossível usar uma conta local. Tente configurar uma instalação nova do Windows 11 sem conexão com a internet — o sistema operacional resiste a cada passo. As configurações estão espalhadas por duas interfaces diferentes (o antigo Painel de Controle e o novo aplicativo Configurações), como se a equipe tivesse chegado na metade de uma migração e então sido realocada para outros projetos.
Isso não é incompetência. É uma função de otimização diferente. Quando a equipe de Kent Sullivan descobriu que a configuração de impressoras era confusa, construiu um assistente para guiar o usuário passo a passo. Quando o Windows moderno descobre que os usuários preferem o Chrome, adiciona caixas de confirmação extras para desencorajá-los de abandonar o Edge. O mesmo nível de esforço, a intenção oposta.
A mesma deriva aconteceu em toda a indústria. Todos os grandes sistemas operacionais têm agora alguma versão de dark patterns — coleta de dados opt-out, configurações de privacidade deliberadamente confusas, notificações projetadas para gerar ansiedade em vez de informar. Como um comentarista colocou: as interfaces do final dos anos 90 foram as últimas projetadas por pessoas que realmente se importavam, por pessoas que encaravam o processo tendo o usuário final em mente. Eram otimizadas para o usuário. Agora são otimizadas para a empresa.
A morte da interface consistente
Uma coisa que sinto falta da era do Windows 95 e que raramente é discutida: a personalização global do sistema. Era possível mudar a cor de cada elemento de UI — barras de título, botões, texto, planos de fundo — e qualquer aplicativo bem escrito respeitava suas escolhas. Queria modo escuro em 1995? Tinha. Podia configurar até as cores individuais de cada widget.
Hoje, depois de anos de desenvolvedores de aplicativos abandonando controles nativos para desenhar suas próprias UIs personalizadas, ganhamos o “modo escuro” anunciado com pompa, como se fosse um recurso revolucionário. E metade dos aplicativos nem sequer o respeita. O Spotify parece Spotify independentemente do tema do sistema. O Discord faz do seu jeito. Todo aplicativo Electron é uma ilha, ignorando as convenções do sistema operacional, os recursos de acessibilidade e os atalhos de teclado. O resultado não é uma experiência computacional coerente — é uma dúzia de linguagens de design diferentes comprimidas em uma tela, cada uma ligeiramente quebrada à sua própria maneira.
Quando os aplicativos usavam o toolkit de UI nativo do sistema operacional, uma mudança de tema se propagava por tudo. Se um aplicativo não respeitasse suas cores, era um bug. Hoje, o conceito simplesmente não existe. Você fica com o que o arquivo Figma do designer decidiu três sprints atrás.
Há uma perda real aqui que vai além da estética. Controles nativos significavam atalhos de teclado consistentes, ordem de tabulação consistente, comportamento consistente de campos de texto e áreas de rolagem. Leitores de tela e ferramentas de acessibilidade podiam se conectar à hierarquia de controles do sistema operacional. Quando cada aplicativo desenha sua própria UI do zero em um canvas web, tudo isso se quebra.
Também ganhamos hardware mais rápido e interfaces mais lentas
Talvez a regressão mais absurda: a responsividade. O Windows 95 rodava em máquinas com 8 MB de RAM e respondia a cliques quase instantaneamente, porque o código de UI era escrito em um nível muito baixo, fortemente acoplado ao próprio sistema operacional. Hoje, o diálogo “Novo” do Photoshop leva segundos para aparecer. O Slack pode consumir gigabytes de RAM para exibir o que é, funcionalmente, uma janela de chat. Alguns aplicativos levam mais tempo para responder a um clique de botão do que a luz leva para dar a volta ao planeta inteiro.
Ganhamos máquinas milhares de vezes mais poderosas e usamos essa folga não para tornar as coisas mais rápidas, mas para tornar o desenvolvimento mais conveniente. O Electron envolve uma instância completa do Chrome em torno do que poderia ser um aplicativo nativo leve. O React re-renderiza árvores inteiras de componentes para atualizar uma única linha de texto. O custo é pago pelo usuário em latência, consumo de bateria e aquela frustração de baixa intensidade e constante de interfaces que parecem lentas sem motivo visível.
Há um argumento razoável de que parte disso é uma troca aceitável — as tecnologias web reduziram a barreira para construir aplicativos multiplataforma, e muitas ferramentas úteis existem hoje que não teriam sido construídas de outra forma. Tudo bem. Mas vale reconhecer que a troca existe, e que é o usuário quem paga por ela.
O que realmente vale levar de 1995
Não acho que a nostalgia seja a resposta certa aqui. O Windows 95 tinha muitos problemas — estabilidade precária, multitarefa terrível sob carga, um processo de instalação que podia arruinar sua tarde. O ponto não é que tudo era melhor. O ponto é que o processo era melhor.
A equipe do Windows 95 praticava o que hoje chamamos de continuous discovery. Observavam pessoas reais realizando tarefas reais, identificavam os pontos de dor com dados, prototipavam soluções e as testavam novamente. Quando algo não funcionava, não debatiam sobre qual intuição estava certa — rodavam outro estudo. Mantinham um banco de dados de rastreamento de problemas de usabilidade da mesma forma que mantemos bug trackers para código.
Como alguém que trabalha em design de produto, acho isso ao mesmo tempo inspirador e um pouco deprimente. Temos mais ferramentas para pesquisa de usuário do que nunca — analytics, gravações de sessão, plataformas de A/B testing, ferramentas de usabilidade remota. E mesmo assim a tendência dominante de design da última década foi priorizar o minimalismo visual e as métricas de engajamento em detrimento do trabalho minucioso e centrado no usuário que o paper de Sullivan descreve.
As melhores equipes de design com as quais trabalhei ainda praticam algo próximo disso. Mas estão nadando contra uma correnteza que recompensa entregar rápido, medir cliques e dar o assunto por encerrado. O estudo de caso do Windows 95 é um lembrete de que existe outro caminho — mais lento, mais disciplinado e, em última análise, mais respeitoso com as pessoas que realmente usam o que construímos.
Talvez devêssemos lê-lo com mais frequência.