O modelo conceitual de um produto digital ajuda a conhecê-lo e descrevê-lo antes da realização, estabelecendo consenso na equipe de projeto para avaliar sua aderência aos objetivos e às linhas gerais de desenvolvimento.

Atividades relacionadas à elaboração de modelo conceitual para projeto de mídias digitais incluem:

Entender o produto em seu contexto de uso, com o levantamento de requisitos do 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 necessários para alcançar os objetivos. É importante avaliar as informações coletadas sobre objetivosdefinição do escopo do projeto.

Entre requisitos de caráter amplo estão:

Perfil dos usuários, contexto cultural, necessidades, comportamentos, atividades

Requisitos 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?)

 A cultura interna (histórias, crenças, visão) da equipe que desenvolve o produto, o ambiente de negócios (crenças e julgamentos em oposição a conceitos novos a ser desenvolvidos e amadurecidos)

Recursos para a realização, financeiros, de tempo e de pessoas

Produtos do projeto (tecnologia, 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 neste 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?”. Respostas a perguntas como estas permitem a verificação de padrões de comportamento sobre o uso de produtos ou de outros produtos relacionados.

 Realizar um processo de ideação, com a proposição do maior número possível de soluções potenciais, de 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 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 bolar 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 ajuda a validar os pressupostos iniciais, transformando-os em requisitos de projeto e neutralizando possíveis influências políticas que possam interferir sobre o desenvolvimento do produto.

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

Paper prototyping: Getting user data before you code (Alerbox, acesso em 28.12.2008)

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.

Bringing user centered design to the agile environment, Anthony Colfelt (Boxesandarrow, 31.1.2010, acesso em 19.3.2010)

Sketchboards: Discover better + faster UX solutions (Adaptive Path, acesso em 12.1.2009, não mais disponível no endereço acessado)