Documentação de Design

Indivíduos ou grupos utilizam a construção de esquemas para a captação e análise de informações. Questões complexas ou processos podem ser simplesmente representados se o tipo certo de diagrama é escolhido. Os métodos de visualização fornecem um foco para a discussão de questões e ajudam a estimular o pensamento criativo.

Briefing

Para escrever um bom briefing, é preciso certa experiência. 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.

Tutorial em vídeo

Definição do objeto

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 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.

Pesquisa

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 dos 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 designers, 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.

Objetivos

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.

Retorno do investimento

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:

  • corte nos custos
  • maior participação no mercado (market-share)
  • maior conscientização da marca (branding awareness)
  • aumento direto nas vendas
  • influência na decisão de compra
  • aumento de produtividade
  • aumento de audiência
  • atração de nova audiência
  • fidelização da audiência
  • aumento da credibilidade do negócio
  • aumento da satisfação subjetiva

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.


Design Centrado no Valor, Jess McMullin

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.

Casos de Uso

Trecho de “UML 2 – Guia Prático” (Gilleanes Guedes, Ed. Novatec):

Este é o diagrama mais geral e informal da UML, sendo utilizado principalmente para auxiliar no levantamento e análise dos requisitos, em que são determinadas as necessidades do usuário, e na compreensão do sistema como um todo, embora venha a ser consultado durante todo o processo de modelagem e sirva de base para todos os outros diagramas.
O Diagrama de Casos de Uso apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma idéia geral de como o sistema irá se comportar. Ele procura identificar os atores (usuários, outros softwares que interajam com o sistema ou até mesmo algum hardware especial), que utilizarão de alguma forma o software, bem como os serviços, ou seja, as opções que o sistema disponibilizará aos atores, conhecidas neste diagrama como Casos de Uso. A figura abaixo apresenta um exemplo desse diagrama.
Image

Image  

Diagrama Sequencial

Método criado por Grady Booch para definir a interação entre elementos de um sistema, depois incorporado pela UML como diagrama de sequência.

Diagrama de Venn

Usa círculos de tamanhos diferentes para indicar os papéis de diferentes organizações e suas relações.

Image 

Diagrama de descrição de página

O diagrama de descrição de página (page description diagram) foi inventado em 1998 por Dan Brown para resolver um dilema: os wireframes que ele entregava para os clientes apenas emergiam discussões sobre layout e não ajudavam a discutir a arquitetura da informação do site. Mais que isso, os wireframes também incomodavam os designers, pois eram documentos que decidiam questões visuais comuns de serem trabalhadas por estes profissionais.

Como solução, os diagrama de descrição de página apontam decisões de arquitetura, em texto ou com especificações pontuais para funcionalidades do site, como no exemplo abaixo, de Dan Brown, onde os elementos estão dispostos por alta prioridade (na esquerda) até baixa prioridade (na direita).

Diagrama de descrição de Página de Dan Brown

Outro exemplo interessante é relatado no post Apple, IKEA and Their Integrated Architecture de Davide Potente e Erika Salvini, com vários diagramas de descrição de página como o abaixo:

Exemplo de diagrama de descrição de página

Mais informações sobre o diagrama de descrição de página (page description diagram) podem ser encontradas do post de Dan Brown no Box and Arrows, Where the Wireframes Are: Special Deliverable #3, e outros documentos disponibilizados pelo autor, como este PDF com um exemplo da descrição dos elementos de um site e o poster de 2002 enviado ao IA Summit de Baltimore: “Where the Wireframes Are: The Use and Abuse of Page Layouts in the Practice of Information Architecture.

Diagrama do ecossistema

Mostra a relação lógica e física entre os componentes de hardware e software, bem como stakheolders de um novo produto ou serviço.

Exemplos

Diagrama do projeto Der Garten, dos alunos do Instituto Faber-Ludens.

diagrama_atores_sociais.jpg

Fluxograma de Interação/Navegação

Este documento costuma ser chamado de Fluxograma de Interação quando se trata de produtos ou dispositivos móveis e Fluxograma de Navegação quando se trata de websites. Ambos demonstram as etapas de execução de uma determinada tarefa. Cada etapa pode representar uma tela, uma página, uma opção de menu. É preciso deixar bem claro o que está sendo representado através de uma legenda.

O mais comum é as caixas representarem páginas de um website e as linhas são links ou botões. É possível escrever na linha para indicar o texto do link.

O fluxograma serve para definir e avaliar sequências interativas e seus possíveis desvios e desdobramentos. O objetivo do diagrama é visualizar se a sequência faz sentido para o usuário. Também serve como referência para requisitos de desenvolvimento, especificando que telas serão necessárias.

É possível num mesmo fluxograma demonstrar mais de uma tarefa, porém, o limite é curto. Um fluxograma com setas indo pra cá e para lá pode deixar o leitor do diagrama perdido facilmente. Quando o projeto atende a muitas tarefas, é melhor fazer um fluxograma para cada tarefa. Uma boa estratégia de leitura é colocar as primeiras etapas no topo superior esquerdo e descer até o canto inferior direito. 

Exemplo de fluxograma de tarefa:

Para evitar a ambiguidade na intepretação destes diagramas, Jesse James Garret criou o Vocabulário Visual, considerado um padrão de mercado. Veja um tutorial completo. Abaixo uma paródia feita por Fernando Aquino utilizando a notação estritamente.

Existem representações mais elaboradas de trabalhar com fluxogramas de interação como o Diagrama Sequencial e Swimlanes.

Programas para fazer fluxogramas:

MoLic

Notação para fluxos de diálogos entre usuários e designers através de interfaces computacionais. Baseado nos fundamentos de Engenharia Semiótica.

Image 

Tutorial de como usar o MoLic (PowerPoint) 

Donwload do Mollic Designer (Windows) 

Vocabulário Visual

Notação para fluxogramas de interação e páginas criado por Jesse James Garret.

Veja um tutorial.

Image 

História em Quadrinhos

Conceito

Histórias em quadrinhos (HQ), são narrativas que tem em sua composição linguagem imagética (Não-verbal) e textual (verbal). Essas duas linguagens se interrelacionam, de modo a completar o sentido uma da outra, criando a dinâmica única de uma HQ.

Essa ferramenta é marcada pela interatividade e alto nível de envolvimento, uma vez que o leitor precisa completar, e até mesmo supor ações, que por vezes não estão descristas nos quadros. 

Método para criação de HQs

Para criação de um quadrinho profissional é necessário se ter em mente o que vai ser tratado dentro da História, a moral ou o conteúdo que se quer passar, a isto é chamado Tema. Depois de escolhido o tema, é necessário pensar de que forma ele será tratado, como virá dentro da história, a isto é chamado Trama ou Plot.

Depois de definidos estes conceitos se parte para criação de fato, o primeiro passo é o roteiro. Assim como um filme, HQs também são construídas a partir de um script. Existem duas maneiras conhecidas de fazê-lo: O full-script, ou roteiro completo, onde são descritos todos os detalhes da história, quadro a quadro, balão a balão; Outra forma é o Marvel Way, (chamado no Brasil de Argumento), criado pelo famoso roteirista de quadrinhos e fundador da editora Marvel, Stan Lee. Nesse método a história é desenvolvida a partir de um texto descritivo corrido, sem falas, onde se resume a História.

Após confeccionado o roteiro, se parte para a fase de Storyboard. Essa ferramenta consiste na criação de um rascunho da HQ por inteiro, onde se passa o que foi descrito no roteiro para os quadros, com um desenho simplificado. Sua função é perceber se o número de quadros por página é adequado, se os quadros estão devidamente posicionados na página, se não há muita informação na mesma, etc. Dessa forma, evita-se efetuar mudanças no momento em que se está finalizando os desenhos da HQ de fato.

Por último, e não menos importante, o processo de desenho e arte-finalização. Aqui é a etapa final de todo o processo, onde a HQ é produzida de fato. Cada quadro é desenhado detalhadamente, vetorizado e finalizado em softwares de edição e colorização, e/ou finalizados a mão (no caso de colorização em aquarela). Recomenda-se nessa etapa desenhar as páginas em A3 para uma maior superfície de desenho e detalhes.

História que descreve o contexto de uso e atividades de um produto, sem necessariamente mostrar o seu funcionamento. 

Exemplos

Projeto Joãozinho e Anita, pelos alunos do Instituto Faber-Ludens.

hq_ipad_anita-e-joaozinho-rumo-aos-descobrimentos-das-novas-tecnologias.jpg

Inventário de Conteúdo

Listagem diversa de todos conteúdos que o produto possua. A coleta de informação consiste no contato com as fontes de conteúdo para obter amostras de conteúdo (content chunks) que ainda serão produzidos ou suas versões finais. O resultado é um índice com todo o conteúdo do produto.

No caso de um site já existente as amostras de conteúdo podem ser obtidas navegando por todos os links do site e anotando os conteúdos encontrados.

Exemplo de inventário criado por Sonia Trois:

Jornada do Usuário (Customer Journey)

Customer Journey é um método para estudar a maneira como um serviço é prestado ao usuário. Explora o modelo mental do usuário e seus padrões comportamentais, processos e caminhos vividos, traduzindo essa bagagem em experiência. Também visualiza o estado emocional do usuário numa determinada interação com o serviço.  

Animação introdutória

Tutorial em vídeo

Documentando uma jornada

Para fazer uma customer journey, é preciso observar a experiência do usuário. Se você não tiver como observar, veja outro método correlato, o service blueprint que visa projetar a jornada ao invés de entender como ela acontece hoje.

Os dados de observação devem ser agrupados em interações e etapas com o serviço e ordenados de acordo com a ordem cronológica. Pode ser utilizada uma sequência genérica, do tipo: 1) Conhecer, 2) Começar, 3) Usar, 4) Desenvolver e 5) Sair. Fotos e desenhos podem ser grandes recursos para visualizar cada etapa.  

Feita a linha do tempo, acrescentam-se as linhas de análise logo abaixo, com vários tipos de aspectos da experiência, dependendo do que foi coletado:

  • Os pontos de contato atuais
  • As motivações dos usuários naquela etapa
  • Estado emocional do usuário (geralmente em escala quantitativa)
  • Dores e ganhos 
  • Nível de satisfação do usuário
  • Pensamentos do usuário
  • Fatores críticos

A linha do tempo pode ser mostrada como um círculo caso seja utilizada apenas dois tipos de informação ou uma reta para vários tipos de informação, cada qual numa linha diferente.

Passo a passo

  1. Escrever em post-its ou papéis pequenos tudo o que o usuário faz com o produto/serviço atual, quais são os meios que ele utiliza e como ele se sente. Utilizar um post-it para cada ideia.
  2. Dividir uma folha de papel em colunas que representam a escala temporal da experiência e linhas que representam diferentes aspectos da experiência
  3. Colar os post-its nos espaços correspondentes, criando uma classificação dos passos. Acrescentar novos post-its onde for apropriado. Mover os post-it de um lado para o outro caso mude de ideia.
  4. Observar a sequência como um todo e preencher a linha de análise crítica. Utilize essa jornada para pensar que mudanças seriam interessantes nesta jornada.

Exemplos

legowheel.png

img_itau01_1240.jpg

start-colocando-em-prtica-a-gamificao-mjv-tecnologia-inovao-20-638.jpg

Pré-visualizarAnexoTamanho
moma_customer-exp-map.jpg6.58 MB

Mapa Mental

Mostra tendências e ligações sobre a percepção das pessoas. Usado em brainstorming coletivo para desenvolver perspectivas comuns. Caracterizado pela hierarquização das idéias.

Um tema central vai sendo destrinchado à temas segundarios e terciários e assim sucessivamente, se for necessário. Podendo ter descrisções ou apenas os titulos principais.

Biblioteca de exemplos de Mapas Mentais

Mapa conceitual

No início do projeto de um artefato interativo é difícil explicar e discutir com outras pessoas como vai se dar a interação, pois a interação acontece no espaço-tempo. As relações entre as formas do artefato (espaço) e as sequências de transformações (tempo) podem estar claras na mente, mas na hora de apresentar ou assimilar uma idéia, a tradução da idéia se torna extremamente complexa.

O modelo conceitual pode ajudar a mostrar que alguns dos pré-conceitos, seja do designer ou do cliente, não são adequados à realidade. Nessa etapa ainda é possível considerar alternativas, desde que haja um bom raciocínio para sustentar sua validade. Por conseguinte, visualizações do modelo conceitual do artefato são excelentes para negociar mudanças, definir melhor conceitos abstratos e consensualizar uma visão compartilhada do artefato entre os membros da equipe de projeto.

Processo

  • Define-se uma ideia central
  • Criam-se as ideias que reforçam a ideia central
  • Conectam-se as ideias
  • Define-se a natureza da relação entre as ideias através de um verbo atribuído à conexão
  • Os verbos transformam as ideias e o diagrama é revisado

juliana_1.jpg

Depoimentos

Exemplos

Diagrama do arquivador de links Delicious, feito por Frederick van Amstel.

Diagrama do Tecnofood, restaurante projetado pelos alunos do Instituto Faber-Ludens.

_visual_thinking.png

Relação entre Entidades

Mostra a relação conceitual entre pessoas e elementos do sistema.

Exemplos

Diagrama do agregador de links Delicious, feito por Frederick van Amstel.

Diagrama do projeto Lugares Musicais.

modelo_lugares_1.png

Mapa de experiências (experience map)

É uma ferramenta para montar as estórias do usuário, criando uma significação maior para elas e ajudando a mapear e organizar a experiência do usuário com produto.

Um diagrama que combina uma persona com uma história sobre a jornada do cliente nos contextos que envolvem o produto.

Auxilia a perceber a cultura que gira ao redor do produto encontrando os pontos que possuem carência de atenção, onde podem ser criadas novas interações ou melhoradas as já existentes.

Exemplo de Experience Map de um "Social Gamer"

Organograma

Mostra quem é responsável pelo que. Usado para compreender como as organizações trabalham.

Personas

Em resumo, os dados coletados sobre as pessoas na etapa de pesquisa são utilizados para construir modelos de usuários que servirão como critérios para a adequação do projeto. Ao invés de tentar projetar para uma grande quantidade de pessoas e nivelar por baixo para ter segurança, com personas, projeta-se para um número bem pequeno de usuários fictícios, porém representativos.

As vantagens dessa técnica são:

  • engaja e conscientiza a equipe de projeto
  • chega-se a um consenso dos interesses do usuário
  • mantém o foco no usuário durante todo o projeto
  • agiliza a tomada de decisões porque não é preciso consultar usuários reais a cada etapa do projeto

A persona é como uma ficha de personagem de RPG do usuário-modelo criado a partir de dados reais. Contém seu nome, seus gostos, seus hábitos, suas habilidades e etc. Essas informações podem ser obtidas através de entrevistas com usuários potenciais ou através de conversas com quem lida frequentemente com esse público. Um vendedor de telefones celulares sabe bem como é o comportamento dos consumidores desse produto, então é uma fonte muito rica para coletar dados para a persona. Basta perguntar a ele quais são as dificuldades que os consumidores mais tem, do que eles gostam, como tratam o vendedor e etc.

Nas entrevistas com usuários, entretanto, as perguntas não devem ser tão diretas. Além das perguntas objetivas sobre dados socio-econômicos, o entrevistador precisa descobrir quais são as expectativas do usuário em relação ao artefato que está sendo projetado.

  • Será que ele vai ter tempo para aprender como usá-la melhor?
  • Será que ele se importa com a aparência?
  • Que cores odeia?
  • O que tem medo que aconteça enquanto usa um artefato como esse?

Essas perguntas devem ser respondidas pelos usuários, mas não necessariamente devem ser feitas nessas palavras, diretamente. É melhor começar por uma pergunta aberta, do tipo: "qual é a primeira coisa que você faz quando se conecta à Internet?" Lembre-se de que a entrevista não é um inquérito; é uma conversa e quanto mais histórias forem contadas, melhor. Afinal, uma persona é exatamente isso: uma história particular. Por esse motivo é mais importante que as entrevistas sejam qualitativas do que quantitativas. É melhor ouvir bem meia dúzia de pessoas, do que ser superficial com duas dúzias.

Depois das perguntas mais abertas, é possível ir entrando nos detalhes, tão valiosos. "Quer dizer que você abre primeiro o email? E quantas vezes por dia você faz isso? Você recebe muito spam?" e por aí vai. Quando o usuário contar um causo peculiar que aconteceu com ele usando um artefato similar, ou relacionado à atividade em questão, anote bem anotado. Histórias permanecem muito mais tempo na memória do que dados estatísticos .

Baseado no livro de Alan Cooper que primeiro apresentou esta técnica, seguem as dicas mais quentes para criar personas úteis:

  • identifique o fluxo de trabalho (workflow) e os padrões de comportamento em detalhes
  • especifique a habilidade com informática
  • inclua detalhes sobre a vida da pessoa para torná-la mais fácil de memorizar. Escolha alguns detalhes bem pessoais, só para torná-la mais interessante
  • não use uma pessoa conhecida como uma persona. Além de expor a pessoa, acorrenta as características da persona à pessoa real. Crie um arquétipo baseado em pesquisas e dados, mas seja realista
  • mantenha o número de personas pequeno, entre 3 e 7, dependendo da variedade do público. Quanto mais personas, mais risco de interesses conflitantes, confusão, etc
  • não recicle as personas para novos projetos. Cada persona é feita especificamente para o seu projeto
  • não viaje na maionese ou então a persona perde credibilidade

Comunicação interna

Personas são um meio muito eficaz de comunicação interna da equipe. Na Microsoft por exemplo, esse método é muito utilizado nos projetos de software. Eles criam cartazes atraentes comparando as características das personas, imprimem camisetas, bonés e até mesmo canecas com os seus rostos, tudo para lembrar constantemente a equipe do foco do projeto.

Outro ponto forte das personas é sua capacidade de concisão para apresentar resultados de pesquisa. No ritmo agitado da produção tecnológica, poucos são os que tem tempo (e interesse) em ler relatórios de dezenas de páginas sobre os estudos de usabilidade, as etnografia e as pesquisas de mercado do marketing.

As personas se aproveitam do poder das narrativas para aumentar a atenção, a memorização e a organização dos dados coletados sobre os usuários. E quando uma descoberta importante é feita sobre, é muito mais fácil comunicar a equipe toda, por exemplo: "o Adalberto não está conseguindo usar a ferramenta de busca na nossa página" é muito melhor do que "uma quantidade representativa dos participantes de testes de usabilidade tiveram problemas com a ferramenta de busca".

É possível que o criador das personas se sinta tentado a usar caricaturas para torná-las ainda mais atrativas. Em geral, as pessoas acham mais fácil encontrar o meio termo quando lhe são apresentadas os extremos porque podem julgar pelo senso-comum. Entretanto, essa abordagem corre o risco de levar as decisões para longe da realidade, desviar do sentido original das personas que é orientar o design centrado em usuários reais. Outro problema é que isso pode levar a discriminaçõs de ordem social, como por exemplo tirar sarro de deficientes físicos e outros perfis diferentes. Não é porque a persona é fictícia que deixamos de tratá-la como um ser humano de verdade, com todos os seus direitos.

Crítica

As personas podem, por outro lado, ter efeito funesto ao projeto se forem manipuladas a esmo ou não levadas a sério. A tentação de criar e alterar a persona de acordo com o que for mais cômodo para a equipe ou para um profissional em particular pode ser desastrosa. Por isso, vale ressaltar que cada detalhe da persona deve estar muito bem embasado em dados reais, não em meras presunções.

Personas que não se baseiam em pesquisas rigorosas podem ser manipuladas para defender pontos de vista. A Persona mais usada para esse intuito é "minha mãe" ou "minha avó". Já ouviram frases do tipo? "Isso aí nem minha mãe conseguiria usar!" Trata-se de um mero artifício retórico para parecer que se está preocupando com o usuário. Na maioria das vezes, a "mãe" ou a "avó" nem faz parte do público-alvo da interface em questão e mesmo quando faz sua capacidade de representar a totalidade do público é exarcebada. Isso é muito usado porque é uma figura familiar, fácil de compreender. Se você fala da sua mãe, eu consigo imaginar melhor como ela vai reagir do que uma figura abstrata como "mulheres entre 45 e 60 anos".

O Alan Cooper, criador do método Personas, dá uma ênfase muito grande para técnicas de observação de comportamento do usuário porque o objetivo dele é usar Personas para design de interação. No Marketing, o método Personas foi apropriado para fazer segmentação de serviços/produtos por dados sócio-demográficos, então eles usam muito questionários, porque são mais eficientes para esse objetivo. Porém, no design de interação esses dados são pouco úteis.

De que adianta saber se o usuário tem entre 30 e 45 anos na hora que você vai definir o fluxo da tarefa? É muito mais interessante saber como essas pessoas agem em situações parecidas. Por isso o Cooper recomenda entrevistas, observações, testes de usabilidade, card-sorting, análise da tarefa, leituras e estudos etnográficos e etc. As Personas entram depois, para resumir tudo aquilo que a gente costuma colocar em extensos relatórios.

Personas não é uma técnica de coleta de dados, mas sim uma técnica de agrupar e apresentar resultados de pesquisas. Quando são tratadas como fim e não meio, acontece toda essa distorção, pois toda a pesquisa passa a ser enviesada para sustentar os perfis, muitas vezes definidos antes mesmo da própria pesquisa!

Relatório de Usabilidade

Um relatório de usabilidade deve explicar quais são os principais pontos encontrados numa avaliação.

Service Blueprint

Ferramenta com abordagem focada no cliente para a inovação e melhoria do serviço. Descreve o processo de serviço, os pontos de contato com o cliente e os elementos do serviço em detalhe suficiente para verificar,implementar e manter.

O service blueprint permite uma descrição dos elementos críticos de um serviço como o tempo, sequências lógicas de ações e processos. Especifica os eventos que acontecem no espaço-tempo da interação  e as ações que  estão fora da linha de visibilidade para os usuários, mas que são fundamentais para o bom desempenho do serviço.

No blueprint as funções são catalogadas no processo acima e abaixo da linha de visibilidade para o cliente. Os pontos de intersecção (contato) e os processos de back-stage são documentados e alinhados com a experiência do usuário planejada.

Formato

O service blueprint consiste em colunas que representam etapas cronológicas no uso do serviço e linhas que representam diferentes camadas de resposta.

  1. A primeira linha são as ações do usuário
  2. A segunda linha são os pontos de contato com o usuário (helpdesk, telefone, carta, email, balcão, etc)
  3. A terceira linha são as ações visíveis dos prestadores de serviço, também chamada de linha de frente (responder, perguntar, ajudar, etc)
  4. A quarta linha são as ações invisíveis dos prestadores de serviço ou de sistemas automatizados, também chamada de bastidores (calcular, analisar crédito, contatar terceiros, etc)

Exemplos

service_blueprint1.jpgservice-blueprint.jpg

Pré-visualizarAnexoTamanho
example-self-service-technology-blueprints.pdf59.7 KB

Service stream

O service stream documenta os fornecedores de um serviço bem como os próximos serviços que o cliente pode vir a utilizar em seguida ao primeiro. Esse documento ajuda a visualizar as possibilidades de integração entre diferentes serviços e de continuidade da experiência do usuário.

Os fornecedores ficam na afluência e os integrados ficam na efluência. O service stream estende a metáfora de córrego ou rio para delimitar esses pontos.

servicos_integrados.png

Pré-visualizarAnexoTamanho
servicos_integrados.png107.49 KB

Sitegrama

O Sitegrama é um diagrama das páginas de um website, mostrando como se dá a navegação entre elas. Por esse fim, é também chamado de Diagrama de Navegação ou Sitemap. 

No Sitegrama, cada entidade é uma página ou opção de um menu e as ligação representam links. A vantagem de fazer um diagrama como esse ao invés de usar um documento de texto é a visualização do todo em relação às partes. É possível verificar a coerência do esquema de navegação com rapidez, simulando a navegação com movimentos rápidos do olhar. 

Em geral, a representação é hierárquica:

Diagrama de navegação para o portal UFPR

Mas podem haver outras relações de fusão e agrupamento, demonstrando a atuação de filtros, links fora dos menus, seções relacionadas e etc. O sitegrama abaixo demonstra um sistema de navegação facetada, em que é possível navegar por assunto ou por tipo de conteúdo. Veja mais detalhes sobre como foi feito.

Sitegrama proposto ao site Flashmasters.net

Quando o website tem pequena quantidade de conteúdo ou deseja-se demonstrar a possibilidade de navegação fluida, é possível fazer sitegramas em formato de rede de nodos, tal como explicado nesse tutorial. Também é conhecido como Spider Diagram.

É importante mencionar que o sitegrama não deve tentar mostrar todas as ligações possíveis entre as páginas, pois isso faria o diagrama ilegível, tal como no exemplo criado por Michael Zuschlag.

Ferramentas utilizadas para fazer Sitegramas:

Storyboard

É uma sequência de cenas que ilustram a interação de um produto com o contexto de uso, auxiliando no planejamento. Ilustra as principais etapas do projeto e suas interações, guiando o desenvolvimento deste.

Storyboards demonstram o contexto e a sequência de uso de um determinado produto através de desenhos em quadrinhos sequenciais. Em geral, o produto não é mostrado em detalhes no Storyboard. 

O Storyboard foi criado originalmente para planejar filmes e animações, aproveitando a experiência desenvolvida com os quadrinhos.

Tutorial em vídeo

Exemplos

Storyboard para uma tablet de estudos.

storyboard_studium.jpg

Storyboards para o projeto Can We dos alunos da Unisul.

roteiro1.jpg

Ferramentas para fazer storyboard

Qualquer ferramenta para fazer quadrinhos serve.

Pré-visualizarAnexoTamanho
storyboard.pdf13.99 KB

Swimlanes

UX Swimlanes são ótimas ferramentas para os clientes conhecerem melhor sobre os usuários, necessidades de negócios e tecnologia. Através do fluxo da experiência sintetizada em um documento auxilia o entendimento das possíveis disparidades no modelo mental de cada stakeholder, criando uma visão compartilhada dos cenários-chave do usuário.

Se foca no que você está construindo e por que você está construindo, descrevendo requisitos para os stakeholders e a equipe de trabalho. Ao mesmno tempo que a equipe criativa e de UX tem acesso ao fluxo através das etapas de um processo, a equipe de negócios tem acesso ao processo de entrega e a lógica de negócios, e a equipe de Arquitetura e Tecnologia aos sistema de dados e technologia no back-end.

Características

  • estórias do usuário sofisticadas (geralmente um storyboard - estilo comics ou fotos)
  • um fluxo de processo da experiência do usuário
  • processos relevantes do negócio
  • ferramentas e sistemas envolvidos na solução das necessidades do usuários
  • funcionalidades e referências de casos de uso que casam com a documentação técnica

Quando usar

Bem no início do projeto, na fase de descoberta e estratégias

Como fazer

Para fazer as swimlanes você simplesmente adiciona um retângulo para cada linha que deseja desenhar. Sendo que cada linha representa um ator diferente (pessoa, grupo, equipe, sistema, etc.).  

A seguir vai colocando as ações correspondentes e fazendo as ligações que ocorrem no decorrer do fluxo.

O storyboard deve ser feito por último.

Prós

  1. Síntese
    Condensa a User experience, o negócio, os sistemas de backend, e a estória em apenas um documento.
  2. Simplicidade
  3. Melhoramento
    São aperfeiçoadas em facilidade de uso, a partir das tradicionais swimlanes de processo de negócios.
  4. Comunicação
    Todos os cenários combinados exibem a estória completa do produto. A linha que mostra o storyboard ajuda a comunicar sobre "o quê" e "por quê" para a gerência e stakeholders do negócio.
  5. Visão
    Auxilia a visualizar os próximos passo que devem ser aplicados no processo.

Contras

  1. Os Storyboards podem levar muito tempo
    Podem ser simplificados usando fotos produzidas, ou fotos de exemplo retiradas de sites como Flickr, ou até mesmo usando desenhos mais simplificados já que o contexto é mais interessante que a ilustração.
  2. Os workshops múltiplos para a linha de UX do documento
    Os workshops são os maiores consumidores de tempo e requerem um esforço grande para serem organizados. A coesão e a qualidade deste documento é essencialmente construído nesses workshops participativos. Sem essa base, o documento de Swimlanes é simplesmente um conjunto de imagens bonitas e um exercício que termina em si mesmo.

Fonte: Nform

Taxonomia

Taxonomia é a hierarquia das categorias que representam a navegação, o conjunto das categorias em que será classificado uma série de conteúdos.

Ela serve de base tanto para especificar metadados num gerenciador de conteúdo, quanto para gerar a hierarquia de páginas e o menu de navegação no caso de aplicativos e websites.

Diferente da taxonomia da Biologia, na Arquitetura da Informação, os filhos podem ter mais de um pai.

Exemplos

Taxonomia de aplicativos da Apple Store.

apple_store.png

Timeline

Lista de eventos ao longo do tempo. Para a compreensão das tendências históricas.

Aplicativo online para fazer timeline:

http://www.tiki-toki.com/

User stories

É uma forma rápida de obter informações com o usuário final sem precisar se preocupar com a criação de questionários muito elaborados.

É bastante utilizada no desenvolvimento ágil e consiste em um dos membros da equipe fazer pequenas perguntas sobre quais funcionalidades o usuário gostaria que tivesse no produto, mas mantendo o máximo de imparcialidade possível. Os usuários anotam suas ideias em pequenos cartões para que a descrição não seja muito longa.

Depois essas anotações são analisadas e transformadas em requerimentos do produto.

Vídeo conceito

Apresenta a idéia de um produto através de uma narrativa com imagens, texto e animações. Pode incluir também um protótipo em vídeo.

Exemplos

Infomercial

Apresentação de um novo produto através do formato comercial 011-14-06 ou Polishop.

Como o formato já é amplamente conhecido, facilita a criação do vídeo. Não é preciso pensar num script com cuidado e pode-se improvisar utilizando-se os chavões típicos do formato.

Exemplos

Wireframe

Wireframe é um esboço estrutural de uma interface, demonstrando os elementos que serão apresentados visualmente na tela e seu peso relativo.

Seu nome vem da metáfora da  armação usada por escultores para dar forma e suporte a uma obra ("wire", de arame, fio; e "frame", de esqueleto ou estrutura). O wireframe também é conhecido como page schematics (esquema de página), blueprints ou protótipos. 

Tutorial em vídeo

O uso do wireframe

O wireframe é uma maneira de manifestar decisões realizadas em torno de um projeto, e pode ser utilizado com diferentes propósitos. Em uma etapa inicial, pode funcionar como uma ferramenta criativa para explorar e desenvolver conceitos. Neste momento, espera-se que ele tenha muitas transformações para testar possibilidades de organização visual de elementos e para materializar o que até então se mantinha apenas na imaginação de cada um dos envolvidos na arquitetura de informação.

A medida que as revisões aumentam e as alterações começam a diminuir, o wireframe serve como uma espécie de "acordo" entre os envolvidos com o projeto, sobre como o site deverá ser, a medida em que, por exemplo, funcionalidades vão sendo definidas. O wireframe começa a se afirmar um documento de referência. Como documento de etapa de especificação, o wireframe é uma das ferramentas para se registrar diversas decisões sobre o projeto.

Para Jesse James Garrett, um dos mais importantes autores na área de Experiência do Usuário (UX), o valor do wireframe está na sua maneira de integrar elementos de Design de Interface, Design de Navegação e Design de Informação. A partir do contato destas três campos em um mesmo documento, o wireframe define o esqueleto que dá o primeiro passo para a processo de formalização do design visual de um website.

Quando está quase concluído, o wireframe resulta em um documento que detalha o projeto e que pode ser utilizado tanto para validar o processo de implementação como para validar a própria arquitetura de informação, por permitir que seja realizado um protótipo funcional passível de testes (como uma avaliação de usabilidade) com usuários. O wireframe é mais útil como uma ferramenta para ajudar na criação de mockups de alta fidelidade e protótipos funcionais, do que como representação perfeita do que será  projetado.

Simplicidade 

Do ponto de vista do design gráfico, o documento que o arquiteto da informação gera para especificar os elementos que vão compor uma página (wireframe) deve ser o mais simples possível. Cores, imagens, tipografia e exatidão dos tamanhos e medidas não devem ser preocupações de quem cria um wireframe. Esse documento deve servir como mera referência para o designer gráfico da página, que pode até encontrar uma disposição melhor para os elementos dentro de sua criação. Se o wireframe é repassado com o grid de alinhamento definido, tamanhos de fontes e até tipografia, o designer pode se sentir engessado demais.

O wireframe também serve para os desenvolvedores saibam exatamente que elementos de interface terão que implementar. 

A vantagem de fazer o wireframe antes do design gráfico ou desenvolvimento das páginas é que o planejamento é mais bem pensado e as alterações podem ser feitas com o mínimo de esforço, evitando retrabalho. 

Por outro lado, o wireframe normalmente é entregue ao cliente para aprovação antes de ficar pronto o design gráfico, ou seja, um monte de rabiscos numa folha de papel causa uma impressão pouco profissional. É por esse motivo que muitos arquitetos da informação capricham demais na apresentação do wireframe. O exagero começa quando o arquiteto se preocupa se alguém vai achar feio seu wireframe. Wireframe não é pra ser bonito, é pra ser entendido.

Pode-se encontrar um meio termo, um wireframe de baixo custo mas com apresentação profissional, através da utilização de softwares específicos para isto. O software fornece os elementos gráficos já prontos (janelas, listas, caixas de texto, botões etc.) e o arquiteto monta os wireframes praticamente apenas clicando e arrastando.

Exemplos

Rabiscoframe

Rabiscoframe é um esboço de interface gráfica que focaliza nos componentes de interação, tais como botões, menus e ícones. O esboço serve para visualizar rapidamente o conceito da interface e gerar alternativas. Os elementos são desenhados sem qualquer detalhe, visando apenas marcar sua posição na tela.

Além de representar a estrutura básica da interface, o rabiscoframe costuma incluir diversas anotações fora da tela, esclarecendo os comportamentos esperados pelos elementos de interação.

Os rabiscoframes costumam ser feitos em cadernos de anotação, quadros branco de parede e quadros brancos portáteis.

rabiscoframe.jpg

Wireflow

Sequência de wireframes simples encadeadas em um fluxograma afim de visualizar um processo em etapas.

O uso do wireflow facilita a visualização dos pontos chave de interação, pois cada interação em uma tela leva a próxima tela do seu resultado.

Pode ser feito usando telas completas ou apenas as áreas interativas de cada tela que levam a outras áreas.

Referência: http://wireframes.linowski.ca

Wireframe com narrativa guiada

Wireframe com narrativa guiada (guided wireframe narrative), são wireframes simplificados, com comentários e informações sobre funcionalidades descritas em forma de narrativas. São histórias descritas durante o wireframe, diferente dos wireframes que demonstram de uma vez só todos os comentários sobre a interface

Útil para comunicar interações complexas  e para casos em que não é possível produzir um protótipo.

Mais informações no post de Andres Zapata, "The Guided Wireframe Narrative for Rich Internet Applications". Abaixo, um exemplo de aplicação deste autor:

Guided Wireframe Narrative