Há pouco tempo eu me deparei com o estudo de caso de Kent Sullivan de 1996 sobre o design da interface do Windows 95, e ler aquilo foi como encontrar uma carta de uma era mais civilizada. Sullivan entrou pra equipe de UI do Windows 95 em 1992 e passou anos documentando como o time tocou o redesenho do sistema operacional mais usado do mundo.

O paper descreve prototipagem iterativa, testes de laboratório com usuários reais, bancos de dados formais para rastrear problemas, estudos de campo. Descreve umas doze pessoas (designers de produto, designers gráficos, especialistas em usabilidade, cientistas da computação) trabalhando juntas para tornar o Windows mais fácil de usar para as pessoas. Era esse o objetivo, e não tinha outro.

No paper todo não tem uma linha sobre métricas de engajamento. Também não tem dark pattern para empurrar telemetria, nem spam de notificações, nem conversão sorrateira de contas locais em contas dependentes da nuvem, nem botões de “IA” aparafusados em cada superfície. O que tem é gente observando outra gente usar um computador, anotando o que via e voltando pra consertar o que estava quebrado. Lendo hoje, a coisa toda chega a parecer ingênua de tão simples.

A área de trabalho do Windows 95. Cada coisa nessa tela foi testada, jogada fora, redesenhada e testada de novo ao longo de três anos.

O processo que criou o botão Iniciar

O que mais me impressiona nesse relato é o rigor. A equipe não chutava soluções; media os problemas primeiro. Levantaram as vinte tarefas que as pessoas mais faziam no Windows 3.1 e rodaram estudos de laboratório comparando como elas executavam essas mesmas tarefas no sistema antigo e no novo.

Os primeiros resultados foram ruins. Em vez de entrar em pânico, a equipe fez um offsite e releu tudo que tinha coletado até ali: estudos de linha de base, entrevistas, pesquisa de mercado, ligações de suporte. A conclusão apavoraria a maioria dos gerentes de produto de hoje. Talvez um sistema realmente utilizável não pudesse se parecer com o Windows 3.1 nem se comportar como ele.

O processo de design iterativo do Windows 95, extraído do paper de Kent Sullivan de 1996. Protótipos eram testados no laboratório, refinados em código e depois testados em campo, e os dados do campo alimentavam a próxima versão.

A barra de tarefas talvez seja o melhor exemplo desse processo em ação. A primeira tentativa de melhorar o gerenciamento de janelas foi tímida. Transformaram as janelas minimizadas de ícones pequenos em “tiles” maiores, na esperança de que alvos maiores fossem mais fáceis de encontrar. Não deu certo, e os usuários continuaram com os mesmos problemas de antes.

O problema de verdade, mostravam os dados, era que as janelas nem sempre estavam visíveis, e 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, com um botão por aplicativo em execução, sempre na tela e sempre acessível. Testaram, funcionou, e foi pro produto.

Um protótipo inicial do Windows 95 de janeiro de 1993. A bandeja na parte inferior tinha três botões (Sistema, Localizar e Ajuda) mais uma área de armazenamento de arquivos. Nada disso sobreviveu até o produto final.

E nenhum comitê de VPs discutiu se aquela barra também podia exibir anúncios ou sugerir buscas no Bing. Ela estava ali pra resolver um problema do usuário.

No fim do projeto, o time tinha registrado centenas de problemas de usabilidade num banco de dados formal, resolvido 81% deles, consertado parcialmente 8% e deixado 11% em aberto, quase sempre por limitação técnica e não por falta de vontade. Pra aquela equipe, não acertar de primeira valia tanto quanto acertar, e dá pra ver isso no resultado, porque literalmente nada do desenho original da interface chegou intacto ao produto final. Tudo foi iterado, testado e refeito.

A barra de tarefas, nascida da percepção de que o problema não era o tamanho dos tiles, mas que os usuários não conseguiam ver o que estava aberto.

Como as affordances foram removidas

A interface do Windows 95 estabeleceu uma linguagem visual que uma geração inteira internalizou sem perceber. Botões tinham relevo e sombra, então pareciam coisas que dava pra apertar, e controles desabilitados ficavam cinza. Itens de menu com reticências avisavam que vinha uma caixa de diálogo, e itens sem reticências executavam a ação imediatamente. A letra sublinhada em cada rótulo era o atalho de teclado. As affordances estavam por toda parte, consistentes e autodocumentadas.

Relevo queria dizer clicável, cinza queria dizer indisponível, reticências avisavam que vinha uma caixa de diálogo, e o sublinhado mostrava o atalho de teclado.

Essa geração cresceu e virou designer. E como foi criada num ambiente em que a interatividade era óbvia, passou a achar que ela era intrínseca.

Claro que você sabe que aquilo é um botão. É um botão, então por que ele precisa parecer um?

Aí as affordances foram sendo removidas, widget por widget, relevo por relevo. Gradientes entraram no lugar de contornos, textos explicativos sumiram, e manuais viraram folhetos e depois um papelzinho com uma URL. O design flat chegou e decretou que todos os indícios visuais eram poluição, e o que entrou no lugar foi a elegância, o tipo de elegância que rende um screenshot lindo num keynote, mas faz gente de verdade tatear uma superfície de vidro na esperança de que alguma coisa aconteça.

O Force Touch da Apple talvez seja o exemplo máximo disso, uma funcionalidade em que apertar a tela com mais força faz algo diferente de apertar de leve. Como é que alguém descobriria isso sozinho? O clique direito do Windows 95 tinha um problema de descoberta parecido em teoria, mas na prática ter um segundo botão físico no mouse, bem ali do lado do primeiro, tornava muito mais fácil encontrá-lo por acidente. Já o Force Touch era uma interação fantasma.

O iOS escondeu a barra de rolagem. Depois escondeu a barra de abas na parte de baixo do Safari, e é preciso rolar pra cima pra ela reaparecer. Tem relato de gente que rola a página inteira até o topo só pra chegar na navegação, sem saber que existe uma barra escondida embaixo. Rolagem e navegação são das interações mais básicas que existem, e acabaram invisíveis em nome da limpeza visual.

Otimizado para a empresa, não para o usuário

O paper descreve um time que otimizava para o usuário. Hoje, a maior parte das decisões de interface é otimizada para o resultado financeiro da empresa. Dito assim parece uma diferença pequena, mas na prática ela é enorme.

O Windows percebe que você quer trocar de navegador e coloca mais um obstáculo no caminho.

O Windows de hoje insiste em te convencer a não trocar de navegador, enfia anúncios no menu Iniciar, te empurra pra 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, e o sistema operacional vai resistir a cada passo.

As configurações estão espalhadas por duas interfaces diferentes, o velho Painel de Controle e o novo aplicativo Configurações, como se o time tivesse chegado na metade de uma migração e sido realocado pra outros projetos.

O fluxo de configuração do Windows 11. Criar uma conta local exige manobras que o sistema operacional ativamente desencoraja. Muito longe do 'tornar o Windows mais fácil de usar.'

Chamar isso de incompetência seria fácil demais. O esforço continua ali, só que apontado pra outro lugar.

Quando o time do Kent Sullivan descobriu que configurar impressoras era confuso, construiu um assistente pra guiar o usuário passo a passo. Quando o Windows de hoje descobre que os usuários preferem o Chrome, adiciona mais uma caixa de confirmação pra desanimar quem tenta sair do Edge.

O mesmo movimento aconteceu na indústria inteira, e hoje todo sistema operacional grande tem alguma versão de dark pattern: coleta de dados opt-out, configurações de privacidade deliberadamente confusas, notificações desenhadas para gerar ansiedade em vez de informar. Li um comentário em algum lugar que ficou na minha cabeça, mais ou menos assim: as interfaces do fim dos anos 90 foram as últimas projetadas por gente que se importava de verdade, gente que encarava o processo pensando em quem ia usar aquilo no fim. Não sei se dá pra levar isso como regra, mas bate com o que eu vejo. Aquelas eram otimizadas para o usuário. Estas são otimizadas para a empresa.

A morte da interface consistente

Uma coisa da era Windows 95 de que sinto falta e que quase ninguém comenta é a personalização global do sistema. Você mudava a cor de cada elemento de UI (barras de título, botões, texto, planos de fundo) e qualquer aplicativo bem escrito respeitava a sua escolha.

Queria modo escuro em 1995? Tinha, e dava pra descer no detalhe e escolher a cor de cada widget.

As configurações de Aparência do Windows 95, onde você mexia em cada elemento separadamente.

Hoje, depois de anos vendo desenvolvedores abandonarem os controles nativos pra desenhar as próprias interfaces, ganhamos o “modo escuro” anunciado com pompa, como se fosse um recurso revolucionário. E metade dos aplicativos nem respeita. O Spotify tem cara de Spotify independentemente do tema do sistema. O Discord faz do jeito dele, e por aí vai. Todo aplicativo Electron é uma ilha que ignora as convenções do sistema operacional, os recursos de acessibilidade e os atalhos de teclado. Em vez de uma experiência computacional coerente, o que se tem é uma dúzia de linguagens de design espremidas numa tela só, cada uma quebrada do seu jeito.

Quando os aplicativos usavam o toolkit nativo do sistema, uma mudança de tema se propagava por tudo, e se um aplicativo não respeitasse suas cores isso era um bug. Hoje o conceito nem existe mais, e você fica com o que o arquivo do Figma do designer decidiu três sprints atrás.

E a perda vai além da estética. Controles nativos significavam que atalhos de teclado, ordem de tabulação e comportamento de campos de texto e áreas de rolagem eram consistentes em toda parte. Leitores de tela e ferramentas de acessibilidade conseguiam se conectar à hierarquia de controles do sistema operacional. Quando cada aplicativo desenha a própria UI do zero num canvas web, tudo isso quebra.

Também ganhamos hardware mais rápido e interfaces mais lentas

A regressão mais absurda talvez seja 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 num nível muito baixo, fortemente acoplado ao próprio sistema operacional. Hoje o diálogo “Novo” do Photoshop leva segundos pra aparecer, o Slack pode consumir gigabytes de RAM para exibir o que é, funcionalmente, uma janela de chat, e tem aplicativo que demora mais pra responder a um clique do que a luz leva pra dar a volta no planeta inteiro.

Ganhamos máquinas milhares de vezes mais potentes e gastamos essa folga em comodidade para quem desenvolve, não em velocidade. O Electron embrulha uma instância inteira do Chrome em volta do que poderia ser um aplicativo nativo leve, e o React re-renderiza árvores inteiras de componentes para atualizar uma única linha de texto. A conta cai no usuário, em latência, em consumo de bateria e naquela frustração baixinha e constante de mexer numa interface lenta sem motivo aparente.

Dá pra argumentar, com razão, que parte disso é uma troca aceitável, já que as tecnologias web derrubaram a barreira para construir aplicativos multiplataforma e muita ferramenta útil que existe hoje não teria saído do papel de outro jeito. Tudo bem. Só acho que vale reconhecer que a troca existe, e que quem paga por ela é o usuário.

O que realmente vale levar de 1995

Não acho que nostalgia seja a resposta aqui. Não me leve a mal, o Windows 95 tinha muitos problemas: estabilidade precária, multitarefa terrível sob carga, um processo de instalação capaz de arruinar a sua tarde. O que era melhor lá atrás era o processo.

O time do Windows 95 praticava o que hoje chamamos de continuous discovery. Eles observavam pessoas reais realizando tarefas reais, identificavam os pontos de dor com dados na mão, prototipavam soluções e testavam de novo. Quando alguma coisa não funcionava, ninguém ficava discutindo quem tinha a melhor intuição; eles rodavam outro estudo. E mantinham um banco de dados de problemas de usabilidade do mesmo jeito que mantemos bug trackers para código.

Como alguém que trabalha com design de produto, acho isso inspirador e um pouco deprimente. Temos analytics, gravações de sessão, plataformas de teste A/B, ferramentas de usabilidade remota. Nunca tivemos tanta ferramenta de pesquisa à disposição, e mesmo assim a tendência dominante da última década foi priorizar o minimalismo visual e as métricas de engajamento no lugar do trabalho minucioso e centrado no usuário que o paper de Sullivan descreve.

As melhores equipes de design com as quais trabalhei ainda fazem alguma versão disso, mas nadam contra uma correnteza que premia entregar rápido e medir cliques. O estudo de caso do Windows 95 é um lembrete de que existia outro jeito de trabalhar – mais lento, mais disciplinado, bem mais respeitoso com quem está do outro lado da tela. Acho que a gente devia reler isso mais vezes.