A integração que optámos por não criar

Se abrires uma nova aplicação em 2026, há uma boa probabilidade de te deparares com um carrossel de dez diapositivos a explicar coisas que uma interface bem concebida não precisaria de explicar.

“Desliza para ver mais.” Sim, nós sabemos. “Toca aqui para começar.” Já estávamos a fazê-lo. “As notificações ajudam-te a manter-te envolvido.” Temos as nossas opiniões sobre essa frase.

O padrão que evitamos

O longo tutorial antes da instalação. O estado inicial que parte do princípio de que o utilizador nunca viu uma aplicação antes. O ecrã do tipo “veja como se usa um botão”. Isto não é integração — são táticas para atrasar o utilizador e impedir que ele faça o que veio fazer.

Se a sua IU necessita de dez ecrãs de explicação antes de poder ser utilizada, o problema é a IU. Não é o utilizador.

O carrossel é também um sintoma de outra coisa: é o local mais fácil para colocar explicações que uma equipa não conseguiu integrar no design. Cada diapositivo é uma pequena admissão de que um ecrã, por si só, não era suficientemente claro. Remover o carrossel obriga-nos, em vez disso, a corrigir esses ecrãs.

O que construímos em vez disso

Um primeiro ecrã que seja imediatamente útil — mesmo que esteja um pouco vazio — para que o utilizador possa começar a explorar e a aprender na prática. Dicas de ajuda apenas nos casos em que a funcionalidade não seja realmente óbvia (e apenas na primeira vez). Estados vazios que indiquem ao utilizador o que deve ser inserido nesse local (“A sua primeira nota aparecerá aqui”), em vez de mostrarem uma imagem animada.

Na prática, isso varia de aplicação para aplicação. Uma aplicação de treino de digitação deve permitir-lhe começar a digitar logo após a abrir, porque a digitação é a lição em si. Uma aplicação para acompanhar hábitos deve permitir-lhe adicionar o seu primeiro hábito logo no primeiro ecrã. Uma aplicação para planear casamentos precisa, de facto, de algumas informações antes de poder ajudar, pelo que pode pedir-lhe essas informações — mas apenas o que é necessário naquele momento — e deve mostrar-lhe algo útil assim que tiver respondido.

Pedimos permissões quando realmente precisamos delas, não no lançamento. Pedimos uma conta quando uma conta pode ajudar o utilizador, não porque queremos o e-mail.

O momento certo é o mais importante no que diz respeito às autorizações. Um pedido de localização faz sentido quando alguém consulta pela primeira vez uma previsão de pesca para as condições nas proximidades; no ecrã inicial, é apenas uma janela pop-up que bloqueia o acesso. Quando solicitado no contexto certo, o motivo é óbvio e as pessoas podem tomar uma decisão informada. Quando solicitado logo à partida, na maioria das vezes limitam-se a tocar no que for preciso para que a janela de diálogo desapareça.

As vantagens e desvantagens

Ignorar o tutorial tem um custo. Algumas funcionalidades não são, de facto, óbvias, e algumas pessoas nunca as irão descobrir sem uma ajuda. Aceitamos que algumas funcionalidades avançadas sejam descobertas mais tarde do que cedo, e esforçamo-nos por torná-las fáceis de encontrar no contexto — uma dica na primeira vez que for relevante, um rótulo claro, uma predefinição sensata — em vez de as apresentar todas logo no início numa apresentação de slides de que ninguém se lembra.

O que fizemos de errado

Já exagerámos na correção no passado. Um primeiro ecrã vazio, sem qualquer orientação, não é minimalista; é confuso. Um estado vazio que apenas diz “Sem itens” deixa as pessoas sem saber o que fazer a seguir. Agora, cada estado vazio responde a uma pergunta — o que devo fazer primeiro? — com uma única ação clara.

O caminho mais curto desde a instalação até ao primeiro momento em que o produto se torna útil — isso é a integração. Tudo o resto não passa de um cartão de felicitações.