O Problema da Página de Configurações

A página de configurações é a tela mais honesta do seu produto. Ela mostra, em uma única rolagem, exatamente quais decisões o time se recusou a tomar. Todo toggle é uma discussão fossilizada. Toda aba aninhada é um "a gente resolve depois" que ninguém resolveu.

A maioria das páginas de configurações é um aterro sanitário. Três anos de toggles despejados por engenheiros que não sabiam dizer não, por marketers que precisavam de um opt-out e por PMs que trataram "deixa configurável" como substituto de "decida". O resultado é uma tela que o time tem vergonha de demonstrar e que o usuário tem medo de tocar.

Este é o argumento para tratar configurações como uma superfície de produto de primeira classe. Cinco arquétipos, seis regras, exemplos reais de produtos que você já usa e uma auditoria para rodar antes de publicar.

Configurações é a tela que expõe o time

Excesso de configurações é um indicador antecipado (leading) de disfunção organizacional. Quando um time não consegue chegar a um acordo sobre um padrão, o toggle é lançado. Quando um cliente reclama e ninguém quer bater de frente, o toggle é lançado. Quando o PM não consegue decidir entre dois fluxos, os dois são lançados atrás de uma configuração.

Seis meses depois, ninguém lembra por que metade dos toggles existe. Remover uma configuração exige a mesma decisão que o time evitou na primeira vez, então elas se acumulam. Olhe qualquer produto com mais de três anos no ar e você consegue contar as decisões não tomadas na árvore de configurações.

Os cinco arquétipos de páginas de configurações ruins

Páginas de configurações ruins não são aleatórias. Elas se encaixam em cinco padrões, cada um o ponto final de um tipo específico de preguiça organizacional.

1. O Lixão

Acúmulo cronológico. As configurações aparecem na ordem em que foram adicionadas, nunca agrupadas. O feature flag mais novo fica ao lado de uma preferência de notificação de 2019, ao lado de um toggle beta que deveria ter sido promovido dois anos atrás. O Cursor está escorregando para isso. Cada release adiciona três toggles na aba Geral, e a aba Geral agora é uma rolagem de 40 linhas de decisões sem relação. O Lixão é o estado padrão de qualquer página de configurações que ninguém está desenhando ativamente.

2. A Planilha

Preferências em ordem alfabética. O time desistiu de hierarquia e deixou o sistema ordenar. Todo toggle tem o mesmo peso, toda linha é idêntica. As preferências de notificação do Slack moram aqui. Som, badge, mobile, canal, palavra-chave, não perturbe, agenda, personalizado, tudo achatado em uma parede sem nenhuma história sobre quais importam.

3. O Beco Sem Saída

Configurações que não mudam nada visível. O usuário ativa "Modo compacto" e a tela fica idêntica. Ativa "Habilitar recursos avançados" e nada aparece. O redesign das Configurações do Sistema da Apple no macOS lançou uma geração delas: configurações silenciosamente sobrescritas por outras, configurações que exigem reinício que a tela nunca menciona. O Beco Sem Saída ensina os usuários que configurações não funcionam, e eles param de confiar no resto do produto.

4. O Labirinto

Dez níveis de abas aninhadas. Configurações enterradas sob uma categoria, uma subcategoria, um "Avançado" expansível, um modal. O usuário sabe que o toggle existe, já o ativou antes, e ainda assim não consegue achar. O Jira antigo construiu uma carreira nisso: projeto, board, workflow, esquema, esquema de permissões, esquema de notificações, todas árvores separadas.

5. O Museu

Configurações que ninguém toca há três anos. Elas existem porque removê-las parece arriscado. Referenciam recursos descontinuados em 2023. Todo produto SaaS legado tem uma ala do Museu, e o custo é a promessa do time de manter caminhos de código que deveriam ter sido eliminados duas refatorações atrás.

Configurações é uma superfície de produto, não um armário

A maioria dos times trata configurações como o lugar onde o resto do produto é limpo. Esse enquadramento é o bug. Configurações é uma das superfícies de maior alavancagem do produto, e os times mais fortes a desenham assim.

Configurações expressam a visão de mundo do produto sobre o usuário. Elas comunicam quatro coisas ao mesmo tempo. Quanto o time confia no usuário. Quanto controle o time está disposto a compartilhar. O que o time acha que são os padrões certos. E se o time respeita o tempo do usuário o bastante para desenhar para os 5% que mudam os padrões sem punir os 95% que não mudam.

O Linear desenhou configurações como uma única superfície de busca, guiada por command-K, quase sem abas aninhadas. A mensagem implícita: o usuário é competente, a busca é rápida, o time fez o trabalho de hierarquia para que o usuário não precise fazer. O Notion foi na direção oposta e venceu do mesmo jeito. As configurações ficam ao lado da coisa que afetam. Configurações de página na página. Configurações de banco de dados no banco de dados. Configurações contextuais desaparecem dentro do trabalho.

A Vercel usa hierarquia por escopo: projeto, time e conta, cada um claramente rotulado, cada um restrito ao recurso que governa. O Stripe Dashboard vai para o lado orientado a ação, onde toda tela é "faça isto", não "configure esta preferência". As configurações de repositório do GitHub acertam o escopo com uma separação limpa entre propriedade de repo, org e conta.

As seis regras que decidem toda página de configurações

Essas regras se acumulam. Acerte cinco de seis e a página se lê como superfície de produto. Acerte três e ela escorrega para um dos arquétipos em até um ano.

Regra 1: Busca primeiro

Hierarquia é plano B, não principal. O usuário sabe o nome da configuração antes de saber em qual aba ela mora. O command-K do Linear cobre configurações como um tipo de resultado de primeira classe. O Figma adicionou busca de configurações e o tempo até o toggle caiu imediatamente. Se a sua página de configurações não tem barra de busca, você está apostando que os usuários vão memorizar sua arquitetura de informação. Eles não vão.

Regra 2: Posicionamento contextual em vez de registro central

Configurações ficam ao lado da coisa que afetam. Configurações de notificação no painel de notificações. Configurações de página na página. Uma página central de configurações serve para questões de nível de conta, como perfil, cobrança e sessões, e quase mais nada. O Notion é o padrão-ouro. A barra lateral direita do Figma faz o mesmo trabalho para propriedades de camada, frame e componente.

Regra 3: Padrões sensatos que ganham confiança

Todo padrão é uma decisão de produto. Ele expressa o que o time acredita ser a resposta certa para 80% dos usuários. Se o padrão está errado, o toggle é um curativo. Os padrões de notificação do Slack assumem que você quer estar alcançável, não em silêncio. A aposta está certa para o usuário mediano. A maioria dos times desenha o toggle primeiro e deixa o padrão sair por consequência. Essa ordem está errada.

Regra 4: Divulgação progressiva em vez de sprawl plano

O usuário deve ver as cinco configurações que 90% dos usuários importam. As outras 50 pertencem a um clique de profundidade, atrás de um "Avançado" claro. As configurações de projeto da Vercel acertam isso. A primeira tela mostra domínio, variáveis de ambiente e proteção de deploy. Overrides de build, configs de função e rewrites ficam em Avançado.

Regra 5: Sem órfãs

Toda configuração pertence a um grupo. Todo grupo tem um nome. O teste da órfã: leia qualquer rótulo em voz alta sem nenhum outro contexto. Se um designer do seu time não consegue dizer o que o toggle faz, ele é órfão. Órfãs são as sementes do Museu.

Regra 6: Toda configuração ganha o seu lugar

Uma configuração é um contrato. O time se compromete a mantê-la, documentá-la, testá-la e raciocinar sobre suas interações com todas as outras configurações para sempre. A maioria das configurações não consegue pagar esse aluguel. A disposição padrão para qualquer nova configuração deve ser "não". Bons times matam mais configurações do que lançam.

Antipadrões que sinalizam algo mais profundo errado

Três padrões matam mais páginas de configurações do que todo o resto junto. Cada um é um sintoma de que o problema não é a tela, é o time por trás dela.

Configurações como substituto de decisões de produto. O time não conseguiu concordar entre opt-in e opt-out, então lançou como toggle. O usuário herda a discussão não resolvida. Se você ouvir "vamos deixar configurável" na daily, está vendo esse antipadrão se formar. A leitura mais profunda está em projetando fricção de propósito.

Configurações que compensam design ruim. Um toggle de "modo compacto" porque a densidade padrão é folgada demais. Um toggle de "alto contraste" porque as cores da marca falham em acessibilidade. Um toggle de "visual clássico" porque o redesign foi rejeitado. Cada um é uma correção real vestida de opção. A correção é desenhar densidade, contraste e visualizações corretamente da primeira vez.

Configurações que ninguém explica em uma frase. Se um designer não consegue descrever o que a configuração faz, o que muda quando ela é ativada e para quem ela serve, a configuração não deve ser lançada. Rode esse teste antes de qualquer novo toggle entrar no código.

A auditoria da página de configurações

Passe toda página de configurações por estas sete perguntas. Menos que um sim confiante em seis e a página não está pronta.

1. O usuário consegue encontrar qualquer configuração em menos de cinco segundos? Se não, falta busca à página ou a hierarquia está quebrada.
2. Toda configuração tem uma descrição de uma frase que um não engenheiro entende? Se o rótulo precisa de um engenheiro para ser explicado, ele não pertence à superfície do produto.
3. Ativar o toggle produz um efeito visível e imediato? Mudanças de estado ocultas matam a confiança.
4. As configurações são agrupadas por tarefa do usuário, não por time de feature? Uma página organizada por qual time é dono da feature é um artefato interno vazando para o produto. Agrupe por objetivo do usuário.
5. Os padrões são defendidos por escrito em algum lugar? O time deve conseguir apontar para um documento, uma decisão de hierarquia visual ou um princípio de marca. Se o padrão é "o que o engenheiro definiu durante a sprint", a página não está pronta.
6. Você poderia remover metade das configurações sem o usuário notar? Se sim, faça. O Museu é mais pesado do que o time pensa.
7. A página parece e se comporta como o resto do produto? Leia-a ao lado dos seus princípios de design de landing page. Se a marca desmorona, a página de configurações está fora da marca.

Um time que roda essa auditoria duas vezes por ano lança uma superfície de configurações da qual os usuários não recuam. O time que nunca roda lança o tipo de página de configurações que vira ferramenta de recrutamento para a concorrência.

Escolha o princípio, depois pode a página

Configurações são a visão de mundo do time, congelada em toggles. Bons times tratam a página como um fluxo de primeira classe, com o mesmo cuidado que dedicam ao onboarding, ao dashboard e ao site de marketing.

A forma mais rápida de consertar uma página de configurações não é redesenhá-la. É apagar metade dela. Remova toda configuração que falha no teste da órfã, no teste da uma frase e no teste de merecer o lugar. O que sobra é a espinha de uma superfície de configurações de verdade.

A conexão com estados vazios não é acidental. Ambas as telas revelam no que o time acredita quando não há mais nada na tela para distrair. A mesma disciplina aparece nos princípios de web design.

Perguntas frequentes

Quantas configurações um produto deve ter?

O mínimo possível. Toda configuração é um contrato que o time mantém para sempre. A disposição padrão para qualquer nova configuração deve ser "não". Se o time não consegue defender a configuração em uma frase, nomear o usuário que ela atende e descrever o que muda visivelmente quando ela é ativada, a configuração não deve ser lançada.

Onde as configurações devem ficar no produto?

Ao lado da coisa que afetam, não em uma ala central de configurações. Configurações de página na página. Configurações de workspace no workspace. Configurações de notificação no painel de notificações. Uma página central de configurações serve para questões de nível de conta, como cobrança, perfil e sessões, e quase mais nada.

Como limpo uma página de configurações com anos de toggles acumulados?

Rode a auditoria e depois delete. Agrupe cada configuração por tarefa do usuário. Identifique órfãs, becos sem saída e peças de museu. Remova os 30% de baixo na primeira passada e observe os tickets de suporte. Se ninguém reclamar, remova outros 20%.

Desenhe a página de configurações como a homepage

A página de configurações não é um porão. É uma sala onde seus power users vivem e pela qual seus novos usuários te julgam. Trate-a como a homepage, o onboarding, o dashboard. Aplique o mesmo cuidado. Lance com a mesma convicção.

Se você quer um time que desenha a página de configurações como o resto do produto em vez de herdá-la do backlog, contrate a Brainy. Desenhamos configurações como um fluxo de primeira classe, com a disciplina que mantém a página pequena e os toggles pagando o próprio aluguel.