Escreveu-nos confuso sobre algo que parecia um bug: gerou um site de restaurante para o novo espaço, não gostou, regenerou-o e obteve algo suspeitosamente parecido com o mesmo site com o letreiro trocado. Paredes em terracota, cartões creme, um logótipo serifado que poderia pertencer a qualquer bistrô de Lisboa a Praga. Perguntou, com razão, se a ferramenta estava apenas a reciclar um template por baixo.
Não está, e quero mesmo responder à pergunta em vez de o tranquilizar sem explicar.
Aquilo com que se deparou é real, e não é específico do seu build — é um modo de falha conhecido de qualquer sistema que gera a partir de uma grande distribuição de treino sem que lhe digam para fazer diferente. Peça a um modelo para conceber um site de restaurante sem mais indicações e ele vai buscar o meio estatístico de todos os sites de restaurantes que já viu, e esse meio é terracota e creme, porque é isso que domina a distribuição. A mesma história repete-se em landing pages de SaaS (hero central com gradiente, três ícones de funcionalidades arredondados) ou em dashboards de criptomoedas (aquele gradiente índigo-para-violeta em que todos os modelos parecem concordar). Não é que o modelo não consiga fazer algo diferente — peça-lhe para conceber ao estilo de um folheto de estância de esqui dos anos 70 ou de um mapa de metro soviético e normalmente consegue, e bem. É que nada o obrigou a decidir, por isso recorreu à média.
O que realmente mudou por baixo
A razão pela qual a sua segunda tentativa deveria ter sido diferente — e, se não foi, é essa a parte que vale a pena corrigirmos diretamente em vez de o utilizador contornar o problema — é uma etapa a que chamamos o diretor de design. Corre antes de o construtor escrever qualquer markup, e a sua única função é tomar decisões das quais o construtor não pode depois escapar: uma paleta com um ponto de vista, tipografia específica, um mood definido com clareza suficiente para poder ser verificado. Concretamente, isto traduz-se em:
- Cinco a sete cores nomeadas com funções associadas — não "primária/secundária", mas "a cor reservada para estados de erro", "a cor que só aparece no hover"
- Duas tipografias, cada uma com uma razão para estar lá
- Duas ou três frases de linguagem de mood, do tipo que um verdadeiro diretor artístico afixaria num painel
O teste que aplicamos a um brief é se pode ser desrespeitado. "Quente e acolhedor" não pode — não há forma de o violar, o que significa que também não há forma de o fazer cumprir, e o construtor deriva de imediato de volta para terracota-e-creme, seja qual for o brief. "Paleta de outono quente e desenhada à mão, contornos a tinta sobre papel creme, nada brilhante, sem sombras projetadas" é um compromisso real, e um cartão com gradiente vítreo apresentado contra esse brief está visivelmente errado — e é exatamente isso que o torna útil.
Se o seu build resultou genérico, a possibilidade honesta é que o seu brief no prompt estava suficientemente subespecificado para que o diretor não tivesse nada de firme a que se comprometer. Nomear uma referência — um lugar, uma época, um material, ou até simplesmente "sem bege" — dá-lhe algo contra o qual reagir.
Porque confio nisto e não apenas nas capturas de ecrã
Vou dizer-lhe o que me convenceu, porque não foi comparar visualmente três exemplos bonitos lado a lado — é assim que nos convencemos de uma vitória que não existe. Corremos algumas centenas de builds por categoria, antes e depois da existência do diretor, e medimos a distância de cor entre pares de builds da mesma categoria usando delta-E no espaço Lab em vez de RGB bruto, porque o RGB insiste que dois azuis com saturação semelhante estão distantes quando na verdade parecem idênticos no ecrã. Os sites de restaurante eram os piores infratores antes do diretor — a esmagadora maioria agrupava-se dentro de uma faixa de delta-E muito estreita, todos a recorrer àquele mesmo terracota.
Também não vou exagerar. A distância de cor mede "parece distinto", não "parece bom", e ainda não diz nada sobre variedade de layout ou tipografia, que não instrumentámos com o mesmo cuidado. Uma paleta pode ser maximamente distinta dos seus vizinhos e continuar feia. Achamos que distinto-e-ocasionalmente-estranho vence seguro-e-uniforme para o que está a construir, mas isso é um juízo de valor, não uma prova.
Uma coisa a que deve estar atento
Há um modo de falha que corre no sentido inverso, e vale a pena assinalá-lo antes de o encontrar: por vezes "limpo e moderno" não é subespecificação, é o pedido real. Quem está a construir um dashboard SaaS empresarial muitas vezes quer o padrão "aborrecido" de propósito, porque os seus utilizadores esperam isso e desviar-se disso gera tickets de suporte, não encantamento. Um diretor demasiado ansioso por diferenciar irá ocasionalmente devolver algo mais art-direcionado do que o pedido. Damos mais peso às suas restrições explícitas do que ao instinto de diferenciação do diretor, por isso "aborrecido e empresarial" deve resultar em algo aborrecido com bom gosto em vez de uma rebelião contra o seu próprio brief — mas se já tiver cores de marca, um logótipo, fotografias de referência do espaço, coloque-os no prompt ou anexe-os diretamente. Inputs fixados vencem sempre o diretor a inventar a sua própria direção, e ele tratá-los-á como restrições, não sugestões.
Para que conste, isto importa ainda mais se algum dia construir um dos nossos jogos em vez de um site — um jogo tem muito mais superfície para um diretor deixar por definir do que uma landing page, já que o brief aí tem de fixar num só passo o estilo dos sprites, a sensação de animação, a interface e a paleta sonora (mais sobre a parte do áudio especificamente em Sound that isn't beeps), porque a inconsistência dentro de um único build lê-se como inacabado de uma forma que a inconsistência entre dois builds não relacionados nunca lê.
