Há algumas semanas um potencial cliente enviou-me um briefing que dizia: “preciso de um site para o meu negócio, algo moderno, diz-me o preço.” Era a mensagem completa.
Recebo versões disto regularmente, e entendo porquê. A maioria das pessoas nunca escreveu um briefing antes e não sabe o que um developer realmente precisa para dar um orçamento útil. O problema é que um briefing vago leva a um orçamento vago, e um orçamento vago normalmente significa surpresas mais tarde para ambos os lados.
Aqui está o que realmente ajuda.
O que o projeto precisa de fazer
Não “um site moderno.” O que precisa de alcançar? É gerar leads, vender produtos, dar informação, marcar consultas? O propósito molda tudo o resto, desde a estrutura até à funcionalidade e até ao que “concluído” significa.
Quem vai usar
Um site para outras empresas lê-se de forma diferente de um para o público em geral. Conhecer o teu público muda o tom, as decisões de layout, e por vezes a abordagem inteira.
Que páginas ou secções já sabes que precisas
Não precisas de um mapa do site finalizado. Mesmo uma lista rascunho (início, sobre, serviços, contacto, talvez um blog) dá ao developer algo concreto para estimar, em vez de adivinhar o âmbito.
Exemplos de sites que gostas
Não para copiar, mas para comunicar gosto. “Gosto do layout deste” ou “as cores aqui parecem certas” diz mais em cinco segundos do que parágrafos de descrição.
O teu prazo e quaisquer datas-limite fixas
Se tens um evento, uma data de lançamento, ou um prazo ligado a algo externo, diz isso desde o início. Isto afeta se um projeto é mesmo viável e como é planeado.
O teu intervalo de orçamento, mesmo que aproximado
Esta é a parte com que as pessoas mais hesitam, mas é uma das informações mais úteis que podes dar. Um intervalo diz ao developer o que é realista propor. Sem isso, vais receber ou um orçamento baseado em adivinhação ou um “depende” genérico que não faz avançar nada.
Porque é que isto realmente poupa tempo
Nada disto precisa de ser um documento formal. Alguns parágrafos a cobrir estes pontos já são suficientes para um developer entender o teu projeto e dar-te uma resposta real em vez de “depende” ou um número tirado do ar.
O outro benefício é que escrever isto obriga-te a pensar bem no que realmente queres, o que muitas vezes traz à superfície perguntas que ainda não tinhas considerado. Melhor encontrar essas perguntas antes de um orçamento do que depois do trabalho começar.
Se estás a preparar um briefing e queres uma segunda opinião antes de o enviares, podes mostrar-mo. E se já tens um projeto em mente, envia o que tiveres, mesmo que seja em rascunho. Entra em contacto e vemos o resto juntos.