Hoje entrei no mesmo dilema que venho enfrentando há alguns anos nesta profissão de arquiteto de informação: qual é o processo ideal de apresentação da Arquitetura de Informação de um projeto para o cliente?
Conto como eu venho fazendo:
1 – Desenvolve-se o mapa do site e webcontent (documento que detalha e descreve o conteúdo do mapa).
2 – Após aprovados estes acima, inicia-se o desenvolvimento de wireframe de home e interna.
3 - Aprovados estes, inicio a produção dos demais wireframes.
Vocês podem me perguntar porque eu uso este processo. Eu digo que assim ganho produtividade, porque fecho o escopo com o mapa, dimensiono o tamanho do trabalho e só com o conteúdo aprovado desenvolvo os wireframes.
Mas isso não é assim tão simples. Hoje tive a prova disso.
Após apresentar o mapa, o cliente voltou com um ppt, que era uma tentativa frustrada de desenhar um wireframe. Detalhe ele deve ter passado a noite fazendo porque achou que assim seria mais fácil da agência entender o que ele queria. Depois da situação contrangedora de ver aquele “wireframe”, pensei se não seria o caso de mudar as regras do jogo e passar a apresentar junto ao mapa um estudo de home e interna e gastar um tempo a mais, mesmo que sejam, em alguns casos, trabalho jogado fora.
Sei que essa deve se uma discussão forte para todos os profissionais, pois no Summit IA 2008 essa questão foi levantando não só em uma, mas em mais de uma dúzia de palestras.
Bom vou daqui tentando e vocês daí comentando, quem sabe juntos chegamos numa conclusão mais acertada.
Olá Iris, já presenciei isso e sei como é. Teve um caso recente que além do sitegrama, levei o wireframe e o projeto gráfico. Para o cliente compreender o funcionamento dos wireframes. Portanto cada caso é um caso!
[]´s
Acredito que o processo que você falou seja o ideal para apresentação ao cliente, mas nem sempre dispomos de tempo necessário para fazer toda essa documentação.
Costumo fazer a documentação até mesmo para conseguir justificar o volume de trabalho e possível orçamento.
Em muitos momentos o próprio cliente tenta fazer a estrutura do conteúdo, mas devemos entrar com a nossa expertise e mostar o que será ideal para o projeto dele.
“Who knows”. O cliente geralmente não sabe o que quer, e muitas vezes nem nós mesmos sabemos o que oferecer para agradá-lo.
Concordo contigo no quesito “acordar o escopo primeiramente”. Mas para acordar o escopo cada cliente vai precisar de um tipo de subsídio. Alguns apenas exibindo um protótipo em web ou powerpoint ele já se decide. Outros precisam navegar, ler documentações, etc.
O que eu acho importante é previamente acordar o processo dando algumas possibilidades (3 no máximo). Essas 3 opções devem seguir uma metodologia pré-definida de passos e produtos (documentações, protótipos, etc). Fazer um quadro comparativo entre as 3 mostrando suas principais características. Algumas metodologias são adequadas para projetos mais simples outras para projetos mais complexos. Algumas não se adaptam bem para projetos com pouco tempo, independente da complexidade. Certos clientes entendem fácil outros vai ser necessário explicar porque existe a metodologia e demonstrar que ela está embada em experiências anteriores. É importante demonstrar as potencialidades e os riscos de cada uma das opções.
Meus 2 cents
obs: muito bom seu blog!
Paulo Colacino
http://www.idealabs.tv/magazine/
Em algumas empresas, a metodologia tem uma etapa onde é explicado para o cliente o que será entregue. Parece bobo, mas a ansiedade do cliente pode ser o problema no seu caso.
Isso ajuda muito quando o cliente nunca trampou com web na vida ou trampava em agencias que nao valorizavam algumas etapas importantes.
Como nem sempre é viável para o arquiteto participar desde o inicio do projeto, “treinar” o atendimento para “educar” o cliente é outra medida boba que pode ajudar.
Com clientes de verdade (aqueles que nao aparecem apenas para um projeto) tambem pode ser interessante criar uma apresentacao especifica. Como da pra conhecer melhor o cliente, é possível entender o que importa pra ele. Como todo mundo sabe, tem cliente que adora saber cada detalhe enquanto tem cliente que só se interessa pela “logica” da coisa. Para este ultimo, explicar (por exemplo) porque o menu é vertical e nao horizontal, pq só tem 1 cross-sell (e nao 2 como ele queria), quantos passos tera o carro de compra e porque o site ficou tao vertical pode ser mais pratico e importante do que passar pagina por pagina, elemento por elemento.
Nos (seja planejamento, programador, arquiteto, etc) temos a mania de querer explicar tudo pq sabemos o trabalho que deu e porque cada detalhe tem sua explicacao, mas muitas vezes isso nao é relevante pro cliente.
Vamos ver por outro lado.
As vezes o cliente pede uma coisa 10 vezes e o arquiteto nao envia como foi pedido. O cliente pede uma coisa e o arquiteto envia outra, e ainda teima que a dele ta certa. E nisso vai e volta 10 versoes de wire frame, e o arquiteto insistindo.
Chega uma hora, depois de pedir pra mudar o wireframe 10 vezes e o arquiteto nao enviar como foi pedido, ai o cliente apela mesmo, com toda a razao, e acaba fazendo um ppt com setinhas ridiculas, que até ele mesmo que ta fazendo sabe que é ridiculo, mas ele faz de toda forma, pra ver se poe na cabeça do arquiteto que ele é o cliente e quer a estrutura daquela forma e ponto final.
Resumindo o que eu queria dizer, tem arquiteto que não tem argumento pra defender a propria ideia. Ou até tem argumento, mas não é o suficiente para convencer. Ai o próprio cliente diz: Tá difícil ou quer que eu desenhe? E acaba desenhando em ppt mesmo que seja…
Acredito muito que isso depende do cliente. Alguns são mais “antenados” e conseguem ler um sitemap e wireframes. Alguns não sabem e para isso sempre previ tempo de atualização dos documentos.
Uma forma boa que conseguia bons resultados é fazer um sitemap bem macro, geralmente só com primeiro nível e fazer reuniões para entender exatamente do que estava tratando. Um levantamento de requisitos bem profundo, que não só arquitetura participava, mas análise técnica de desenvolvimento tb (como se fosse uma dupla de criação). Costumava dar certo, principalmente para desenvolvimentos de intranets, extranet…