O modelo conceitual de um produto digital ajuda a descrevê-lo e conhecê-lo para seu projeto, estabelecendo consenso na equipe para avaliar sua aderência aos objetivos e às linhas gerais de desenvolvimento.
Atividades relacionadas à elaboração de modelo conceitual para projetos de mídias digitais:
■ Entender o produto em seu contexto de uso, com o levantamento de requisitos de projeto, a articulação dos primeiros pressupostos e o entendimento das demandas do público e do cliente, incluindo a articulação dos requisitos comerciais e funcionais para alcançar os objetivos. É importante avaliar as informações coletadas sobre os objetivos e a definição do escopo do projeto.
Entre os requisitos de caráter amplo estão:
■ Perfil dos usuários, seu contexto cultural prioritário, suas necessidades, comportamentos, atividades
■ Aspectos ambientais, expectativas
■ Expectativas de retorno comercial, fatia do mercado a curto e médio prazo, modelo de negócios, como se insere no mercado (horizontal, verticalmente?)
■ Cultura interna (histórias, crenças, visão) da equipe de projeto, o ambiente de negócios (crenças e julgamentos em oposição a conceitos novos a desenvolver e amadurecer)
■ Recursos para a realização, financeiros, de tempo e de pessoas
■ Produtos do projeto (tecnologias, processos de produção e lançamento, distribuição, divulgação)
■ Imagem da marca, seus requisitos (1)
■ Perfil mais ou menos inovador do produto
As técnicas aplicadas nesse processo podem fornecer diferentes tipos de dados, quantitativos ou qualitativos. Dados quantitativos são traduzidos numericamente e geram estatísticas descritivas, como a idade média dos usuários, por exemplo. Dados qualitativos podem ser obtidos por meio de entrevistas, com perguntas como “que motivos o/a levaram a trocar seu smartphone?”, que permitem a verificação de padrões de comportamento sobre o uso de produtos similares ou relacionados.
■ Realizar um processo de ideação, com a proposição do maior número possível de soluções potenciais, com diversas abordagens, para solucionar o problema a resolver.
Frederik G. Pferdt, Chief Innovation Evangelistdo Google, diz que tudo começa com um “E se…” “Nós nos fazemos perguntas. E isso se aplica ao YouTube, ao Chrome, ao Android. Ajudamos a ter ideias e a dar soluções. Não nos aferramos à primeira ideia que surge. Muitas vezes, se você já sabe que algo vai dar errado, não faz. Sinto que é preciso modificar os circuitos, reprogramar o cérebro de algum modo. Os otimistas são os que querem mudar as coisas”, conclui o pesquisador, com tom de discurso, já que esse nem sempre é um processo fácil.
Na Amazon, por outro lado, o processo consiste na desconstrução, em examinar como seria a reportagem sobre uma ideia e, a partir daí, num processo inverso, criar a forma para tornar isso possível. (2)
■ Selecionar as melhores soluções, processo que, em si, já produz um amadurecimento sobre o produto.
■ Criar e testar um protótipo de trabalho, como um protótipo de papel, em que os requisitos e soluções propostas possam ser vistas de modo simplificado, ser criticadas e aperfeiçoadas.
O protótipo pode ser inicialmente um modelo conceitual, esboço feito manualmente, com lápis e caneta sobre papel ou sobre um quadro branco, com as principais áreas de conteúdo e as funcionalidades do produto em projeto. Informalmente, permite que o pensamento e as ideias fluam com facilidade para a configuração inicial do produto. Os elementos estruturais da interface são previstos um a um e dispostos de diversas maneiras. Os modelos rápidos e sem acabamento ajudam a integrar os elementos comerciais e de marketing, do layout e da arquitetura de informações de maneira intuitiva e afinada com as necessidades dos clientes.
O teste inicial permite validar os primeiros pressupostos, transformando-os em requisitos de projeto e neutralizando possíveis influências políticas que possam interferir sobre o desenvolvimento.
■ Explicitar e registrar os requisitos conceituais em briefing ou sumário executivo, que pode ter o formato do modelo abaixo, com recomendações a partir das informações coletadas em pesquisas, nas conversas e entrevistas por diretores, gerentes, representantes do público-alvo; estabelecer métricas para a avaliação das soluções.
■ Aperfeiçoar a visão estratégica explicitada. Desse modo os patrocinadores (sponsors) e stakeholders do projeto anteveem o produto e afinam qualitativa e quantitativamente os objetivos de negócio. O sumário dos requisitos contém as recomendações para a realização da visão, as áreas de negócio envolvidas, o retorno esperado (ROI). E as percepções sobre o que implementar depois do lançamento.
Metas comerciais ou de imagem (exemplo)
| Modelo conceitual de projeto de produto digital | |||||||||||||||||||||||||||||||||||||
| Público-alvo – resumo (quem visita, consulta, compra/consome) | Exemplo: Profissionais liberais que precisam de informações atualizadas sobre um assunto. O grande público não acessa o site, a não ser em casos especiais | ||||||||||||||||||||||||||||||||||||
| Perfil sócio-cultural dos usuários | |||||||||||||||||||||||||||||||||||||
| Enfoque da edição e da comunicação | Linguagem coloquial? Uso de gírias? Linguagem técnica especializada, sem necessidade de explicar os termos específicos? Notícias? Conteúdo hierarquizado (títulos, subtítulos, olhos)? | ||||||||||||||||||||||||||||||||||||
| Funcionalidades e serviços | Inserção de comentários, venda de artigos, acessibilidade, formulários, envio de malas diretas, sistema de gerenciamento de conteúdo, animações, publicação de banners, blog, compartilhamento de informações, envio de arquivos pelos clientes, outras plataformas participativas, APIs | ||||||||||||||||||||||||||||||||||||
| Características técnicas da interface | Exemplo: Resoluções de tela para melhor visualização; tamanho dos monitores, sem rolagem horizontal; sistemas operacionais; browsers; formato dos arquivos para download. Principais páginas registradas em arquivo sitemap.xml, com grau de relevância de cada página na estrutura. Arquivo robots.txt. Uso de microformatos específicos e RDFa para marcar (com tags) as telas. “Title” e “alt” tags configuráveis pelos usuários. Validação em sites avaliadores de acessibilidade e compatibilidade com padrões web. | ||||||||||||||||||||||||||||||||||||
| Outros requisitos do cliente | Aspectos não necessariamente técnicos ou comerciais que o cliente considera importante, de ordem subjetiva e muitas vezes não explicitados claramente, mas apreendidos em conversa ou comentários. | ||||||||||||||||||||||||||||||||||||
| Recomendações para o layout | Cores e tipologias da identidade visual, associação a um grupo de pessoas (jovens universitários antenados com tendências artísticas internacionais, grupos de culturas regionais, empresa que quer se destacar em ações de proteção da natureza). Malha gráfica mais ou menos flexível à fragmentação, estrutura de informação mais “côncava” (fechada) ou “convexa” (aberta), que exija maiores ou menores barras de navegação aparentes, etc. Sinalização de links, legibilidade de textos, modelos de anúncios, informação de contato. | ||||||||||||||||||||||||||||||||||||
| Metas de usabilidade | Tamanho de imagens, tempo de carregação de abertura das telas, tempo para realizar tarefas, número de cliques para realizar uma tarefa, por exemplo. | ||||||||||||||||||||||||||||||||||||
| Metas de acessibilidade | O sistema deve validar em sites especializados os links das barras de navegação devem ser numerados para facilitar o uso por programas ledores de tela, por exemplo. | ||||||||||||||||||||||||||||||||||||
| Metas de compatibilidade | |||||||||||||||||||||||||||||||||||||
| Principais palavras-chave associadas | |||||||||||||||||||||||||||||||||||||
| Indicadores para medir o desempenho do produto | |||||||||||||||||||||||||||||||||||||
| Concorrência | |||||||||||||||||||||||||||||||||||||
| Perfil comercial ou de atividades | |||||||||||||||||||||||||||||||||||||
| Perfil tecnológico dos usuários (condições de uso, conexão, dispositivos, programas) | |||||||||||||||||||||||||||||||||||||
| Personas (pessoas representativas do público que vão visitar/ usar o produto) | Descrição das principais características | ||||||||||||||||||||||||||||||||||||
| Persona 1 | Características | Cenário | |||||||||||||||||||||||||||||||||||
| Persona 2 | Características | Cenário | |||||||||||||||||||||||||||||||||||
| Persona3 | Características | Cenário | |||||||||||||||||||||||||||||||||||
| Persona 1 | Características | Cenário | |||||||||||||||||||||||||||||||||||
| Concorrência direta e indireta |
| Critério (exemplos) | Nome da org. | Nome da org. | Itens nav. principal | Itens nav. secund. | Conteúdo da Principal | Serviços oferecidos | Funcionalidades especiais | ||||||||||||||||||||||||||||
| Critério (exemplos) | Nome da org. | Nome da org. | |||||||||||||||||||||||||||||||||||
| Itens nav. principal | |||||||||||||||||||||||||||||||||||||
| Itens nav. secund. | |||||||||||||||||||||||||||||||||||||
| Conteúdo da Principal | |||||||||||||||||||||||||||||||||||||
| Serviços oferecidos | |||||||||||||||||||||||||||||||||||||
| Funcionalidades especiais | |||||||||||||||||||||||||||||||||||||
| Condicionantes | |||||||||||||||||||||||||||||||||||||
| Observações sobre a gestão do projeto | |||||||||||||||||||||||||||||||||||||
| Recursos financeiros | |||||||||||||||||||||||||||||||||||||
| Tempo |
É importante relatar os riscos da solução proposta em relação aos objetivos do projeto e em relação às condições técnicas, com a proposição de alternativas para evitá-los ou atenuar os efeitos negativos.
■ Apresentar os requisitos aos stakeholders – Envolvê-los em relação às soluções, para que se posicionem em relação a elas de maneira construtiva.
A planilha deve ser postada em local (físico ou online) que os integrantes da equipe de projeto possam consultá-la sempre que preciso.
É preciso manter em perspectiva que o plano de projeto é um documento “vivo”, que muda na medida em que o projeto evolui e gera mais informações sobre o produto, os usuários e os fatores condicionantes do desenvolvimento.
(Atualizado em 11.12.2017)
Referências
2) Um dia na garagem do Google, Rosa Jiménez Cano (El País Brasil, acesso em 11.12.2017)
→ Preventing the executive swoop and poop with design sprints, Jared Spool (User Interface Engeneering, acesso em 10.1.2016)
1) Gamification in concept design: applying market mechanisms to enhance innovation and predict concept performance, Søren Ingomar Petersen e Hokyoung Blake Ryu (Ingenta Connect, acesso em 8.4.2015)
→ The UX research plan that stakeholders love, Tomer Sharon (Smashing Magazine, acesso em 22.2.2012)
→ Livro: Subject to change – creating great products and services for un uncertain world, de Peter Merholz, Brandon Schauer, David Verba e Todd Wilkens. Sebastopol, CA: OáReilly, 2008.