Para escrever um bom briefing, é preciso certa experiência. O texto que segue foi escrito há três anos atrás, quando trabalhava numa agência de propaganda como webdesigner. É uma tentativa de compartilhar minha experiência com os leitores deste blog, que vivem me mandando mensagens perguntando como fazer um briefing. Sempre tento explicar que briefar não é somente preencher um formulário com os dados do cliente e da peça a ser produzida para servir de contrato entre designer e cliente, mas sim uma atividade de projeto.
Para decidir o que entra no briefing, é preciso pesquisar, refletir e negociar. O briefing vai guiar todo o projeto, ele não pode ser considerado uma ferramenta trivial. Mesmo que o briefing não seja oficializado, escrito ou assinado, ainda assim as decisões de design que ele costuma encerrar estarão nas mentes, nas conversas e nos papéis das pessoas que participam do projeto.
Esta é a parte mais delicada do briefing. Se fechar demais a definição do objeto, poderá ficar preso a elas até o final do projeto, mesmo que se constate depois que não são ideais; se for muito genérico na definição, pode deixar o projeto sem rumo, divagando em possibilidades infinitas sem sair do lugar.
A melhor estratégia que encontrei até agora foi definir o tipo de objeto (website, hotsite, CD-Rom, animação e etc) e agregar apenas as características que a pesquisa inicial indicar como interessantíssimas. O segredo é saber escolher as características que vão transmitir a sensação ao leitor do briefing de que ele sabe do que se trata e que isso é uma boa coisa.
Fazer pequenas pesquisas não leva muito tempo. Navegar pelos websites da concorrência e anotar o que estão fazendo de bom ou de ruim é o primeiro passo para definir o diferencial do projeto. Conhecer melhor a empresa já é uma obrigação mesmo, então não custa anotar o seu diferencial competitivo. O público-alvo às vezes parece óbvio, mas nunca se sabe com certeza que grupo de pessoas vai se interessar pelo serviço que será disponibilizado. Por isso, o designer tem que estar a par dos costumes das principais perfis de usuários da Internet da região. Tem gente que acessa para jogar, xeretar a vida alheia (blogs e afins), consumir pornografia, obter informações, procurar emprego, pesquisar e uma infinidade de outras atividades.
Conhecendo bem a tribo a que o usuário-alvo faz parte, fica bem mais fácil projetar. Se isso for possível, uma visita a um local onde hajam potenciais usuários do website já é suficiente para ambientar o designer. Imagine ir a um baile da terceira idade antes de projetar um website de um retiro? Emocionante não? Claro que não para o designer, mas sim para os velhinhos! Se o designer se coloca no lugar dos usuários, percebe que o que é feio para ele, é bonito para outros. Texto em fonte Verdana 18px é horrível para a maioria dos designer que conheço, mas para os idosos é ótimo!
Caso o artefato interativo seja usado numa situação específica, dados sobre esta serão de grande valia para o designer. Saber que o artefato será usado principalmente em ambiente coorporativo de escritório já deixa o designer com um pé atrás para usar sons. Se o ambiente for uma fábrica barulhenta, som será completamente inútil. Porém, no aconchego do lar, ele pode ser muito agradável caso seja associado ao entretenimento. Cyber-cafés e Lans-house equipadas com fones de ouvido também são propícias ao bom som, é claro. No entanto, esses lugares podem não ser muito bem iluminados, o que torna os contrastes mais fortes no monitor. Existem muitos fatores ergonômicos que podem influenciar o uso de um software ou website específico e, caso sejam recorrentes na situação de uso almejada, o projeto deve se adaptar a eles.
No caso de design de aplicações, a visita pode ser menos recreativa. Análises de tarefas e de workflow podem ser um tanto cansativas, mas são muito, muito valiosas quando a aplicação apresentar complexidade. Esse tipo de análise pode acontecer numa fase posterior ao briefing, mas antes de sair a campo é possível esboçar um fluxo de interação geral entre as pessoas que vão usar o sistema com base nas conversas iniciais com os clientes.
O tempo todo em que o designer estiver no local da situação, deve aproveitar para observar como as pessoas se comunicam. Não é necessário incorporar todo o vocabulário utilizado, mas certas palavras podem tornar a interface familiar. Também é interessante notar como outras mídias se comunicam com essas pessoas. Folderes, cartazes, outdoors, propagandas televisivas e jornais de áreas específicas devem ser analisados com carinho pelo designer. Que imagens são frequentes? Que ideologias estão por trás delas? Que valores são priorizados?
Comparar os websites que esse pessoal acessa com frequência, é mais interessante ainda. É possível identificar padrões, os clichês que funcionam e os batidos demais e aplicar ou não diretamente no design. Não que ele deva reproduzir somente o lugar-comum, mas deve ter elementos familiares aos usuários. Reproduzir o lugar-comum é fácil para o designer, mas buscar uma identidade única sem estraçalhar com os padrões estabelecidos é uma tarefa muito mais instigante. É como estar no limiar, tentando inovar mas sem colocar o carro na frente dos bois. Ser 100% correto não é possível na prática, mas o Zen nos ensina que devemos ser pelo menos 99%. O que vale é a intenção, ou melhor, o que vale é o retorno que o design vai dar.
O que se pretende comunicar? Vender um skate e acessórios? Apresentar dados demográficos da população brasileira? Mostrar que o filme "X" vale à pena assistir? Essa informação não precisa nem ser oficializada, desde que o cliente deixe bem claro o que quer para o designer. Entretanto, ela vai martelando na mente do designer até o final do projeto. Será seu norte, a base mais elementar para qualquer decisão do design. Assim como na programação orientada a objetos, todos os objetivos secundários do projeto herdarão a constituição do objetivo principal.
O objetivo deve ser claro e conciso, mas não pode lhe faltar especificidade, do contrário não tem utilidade. De que adianta ter como objetivo de um website "fornecer informações a quem se interessar por elas"? Qualquer website pode fazer isso, no entanto, cada website faz isso de forma diferente, pois existe uma intenção por trás do fornecimento de informações. O cliente pode dizer que o objetivo do website é "transmitir informações sobre os carros que sua empresa vende", mas isso não é o que a empresa realmente quer obter. O que a empresa quer é vender carros, mesmo que o website sirva apenas para influenciar um ato posterior de compra. "Vender carros" é o verdadeiro objetivo do website. As informações que serão transmitidas serão meros argumentos para convencer o consumidor.
Para atingir esse objetivo, a mensagem principal que deve ser transmitida é "os carros da nossa marca são os melhores para você". Não importa que informações serão utilizadas como argumento, a mensagem é a mesma. Como as possibilidades de argumentação são grandes, é interessante deixar documentada essa mensagem, de preferência no briefing do projeto ou em outros documentos primários, para que a imaginação não divague demais.
Aplicações também transmitem mensagens principais, embora não sejam tão explícitas. O anti-virús precisa transmitir a sensação de segurança; o Mozilla Firefox precisa mostrar que é melhor que o Internet Explorer sem ser muito diferente; e o Google precisa conquistar a confiança de que pode encontrar qualquer coisa.
Você sabe o quanto vale o seu trabalho? Vale mais ou menos a metade daquilo que seu cliente vai ganhar com ele a curto prazo. Se o lucro almejado pelo cliente é grande, então o orçamento pro design deve ser grande, oras. No Brasil, é comum fazer das tripas coração no desenvolvimento de websites com os orçamentos apertados e os prazos curtos, mas é difícil alguém saber o quanto o cliente está lucrando com isso. Por isso, é interessante tanto para a equipe que desenvolve o projeto quanto para o cliente, calcular o Retorno do Investimento (ROI - Return On Investment).
O Retorno do Investimento é uma estimativa objetiva dos lucros que o projeto trará. Alguns tipos de retornos comums são:
Para definir o Retorno, basta reunir-se com os representantes da empresa e discutir o que se almeja e o que é viável obter com o orçamento destinado. Esse processo deve ser muito bem documentado já que, se o Retorno for alcançado, ele servirá como excelente argumento de venda dos seus serviços de design.
Entretanto, não adianta calcular antes e não verificar qual foi o Retorno concreto depois da execução do projeto. O cliente fornecerá os dados facilmente se ele estiver empolgado com o resultado. Do contrário, pode ficar a cargo da equipe do design checar isso. Vale à pena não só pelo valor comercial que esses dados tem, mas também pela gratificação ao designer responsável; faz bem para sua auto-estima.
Até aqui maravilhoso, mas é preciso cair na real e dizer como tudo isso vai acontecer. Descrever a metodologia dá grande credibilidade ao projeto, mas é preciso segui-la depois. Se comprometer com as ferramentas tecnológicas a serem empregadas no projeto também é complicado, mas pode ser necessário.
Nesse ponto não posso dar muitas mais recomendações, pois a forma de proceder estará determinada pelos elementos acima citados.
Esses eram os pontos que eu costumava pensar até alguns meses atrás em projetos tradicionais. Recentemente, estou tentando reduzir os pré-conceitos antes de ter contato com a realidade na própria situação de uso. Para entrar de cabeça no design participativo que acredito ser crucial para a Web 2.0, é preciso estar preparado para trabalhar sem briefing, do contrário fecha-se ou induz a participação das pessoas dentro daquilo que se quer obter delas. Se é pra participar, que seja participação pra valer!
Fred van Amstel (fred@usabilidoido.com.br), 23.03.2007
Veja os coment?rios neste endere?o:
http://www.usabilidoido.com.br/como_fazer_um_bom_briefing_de_website.html