Um guia de criação de produto digital para o fluxo da SEAD/LDI
Escrevi este guia para a equipe de Produtos Digitais do Laboratório de Design Instrucional da SEAD. Conheci o laboratório como estagiária na graduação e voltei como prestadora de serviços de tecnologia. O fluxo reflete o contexto de lá, mas vale para qualquer time que cria produto digital: sites, landings, SaaS, aplicativos e afins.
Este não é um manifesto, e sim um manual com etapas, perguntas, templates e exemplos fictícios para alguém abrir e usar no próximo projeto.
O que é o guia
O guia cobre o ciclo completo, da pesquisa ao pós-lançamento, organizado em cinco etapas:
- Descobrir: stakeholders, dados, entrevistas
- Definir: problema, síntese, matriz CSD
- Idear: soluções, fluxos, stories
- Prototipar: rascunhos, wireframes, alta fidelidade
- Avaliar: testes, analytics, decisão de seguir ou parar
Além das etapas, há fundamentos sobre como adaptar o processo ao prazo, um índice de entregáveis por fase, glossário, modelos prontos para copiar e quatro casos didáticos no contexto SEAD/LDI. Depois do primeiro ciclo, entra a descoberta contínua: um ritmo de sinais, com resumo atualizado e suposições testadas antes de abrir feature nova.
O porquê
Este documento foi estruturado para apoiar o crescimento da equipe de Produtos Digitais do Laboratório de Design Instrucional, consolidando conhecimentos teóricos e práticos necessários para que todos os membros alcancem excelência técnica e alinhamento estratégico nos projetos do laboratório.
Na SEAD/LDI o time muda com frequência: entram estagiários, saem pessoas que carregavam contexto na cabeça, e os projetos se empilham com prazos diferentes. Sem um lugar comum para “como a gente faz produto aqui”, cada projeto acaba reinventando o processo ou copiando o atalho do anterior. Eu quis um material que o laboratório pudesse usar para formar gente e manter o mesmo padrão de decisão, do primeiro briefing ao pós-lançamento.
Na prática, isso significa um caminho repetível. Seja estagiário no primeiro projeto, prazo de uma semana ou produto já em produção, cada cenário pede profundidade diferente, mas as mesmas perguntas. O guia traduz teoria de descoberta e design em passos, checklists e artefatos que o time preenche de verdade.
Também quis endereçar duas falhas comuns. A primeira é construir a coisa errada, quando alguém pede feature sem problema medido e opinião ocupa o lugar da evidência; para isso existem Descobrir e Definir. A segunda é construir do jeito errado, com solução única, zero protótipo barato e problemas que só aparecem em produção; aí entram Idear, Prototipar e Avaliar.
No fluxo da SEAD/LDI isso pesa mais porque o custo de pular etapa aparece meses depois, quando a equipe já mudou e o orçamento sumiu. Portal sem uso, sistema que ninguém atualiza: eu vi isso acontecer. Por isso o guia pede que omissões sejam registradas. Se você encurta o ciclo, anota o que pulou, o substituto mínimo e o risco aceito, porque adaptação sem registro vira atalho invisível.
Para estagiários e quem chega sem ter visto um ciclo completo, montei templates em cada etapa. A ideia não é burocracia, e sim dar noção do que é um entregável: o que entra, o que sai, o que “pronto” significa. Em vez de receber só a teoria, a pessoa abre um modelo com seções, exemplos de preenchimento e critérios mínimos, e o aprendizado fica preso ao artefato, não só à conversa do dia.
A base
Não inventei um método do zero; organizei referências que já funcionam e traduzi para o dia a dia da equipe.
Design Thinking deu a espinha (empatia, definição, ideação, protótipo, teste), que no guia vira as cinco etapas com passos e entregáveis. As três lentes de decisão também vêm daí, com um ajuste institucional: desejabilidade (as pessoas precisam?), viabilidade técnica (dá para construir com a pilha que temos?) e sustentabilidade institucional (a universidade consegue manter?). No contexto universitário, sustentabilidade é manutenção, política e continuidade do serviço, não lucro.
Double Diamond organiza o ritmo de divergir e convergir: abrir em Descobrir, fechar em Definir, abrir de novo em Idear, fechar em Prototipar e Avaliar.
Continuous Discovery (Teresa Torres) cobre o depois do lançamento, quando entrevista e teste não acabam na entrega. O guia descreve um ritmo por sinais, com dossiê e resumo de discovery vivos enquanto o produto está em manutenção.
Eu queria princípios que o time pudesse aplicar numa landing de curso em uma semana ou num portal institucional em um mês, sem reescrever a teoria a cada projeto.
O guia
O material começa com fundamentos que alinham critérios, mostram como adaptar o processo a cada situação e trazem descoberta técnica para legado e integração. Depois vêm as cinco etapas, cada uma com uma pergunta central e entregáveis claros; o índice de entregáveis marca quando a fase pode ser considerada concluída. Abaixo, o que cada etapa cobre.
Descobrir
Pergunta central: o que as pessoas precisam?
Objetivo: abrir o leque e coletar evidência sobre problemas, usuários e contexto antes de definir qualquer solução, entendendo o que as pessoas precisam, o que a instituição quer e o que os dados mostram.
O que se faz:
- Alinhar stakeholders (gestão, coordenação, TI, comunicação) antes de investir em pesquisa profunda com usuários;
- Levantar dados primários: analytics, tickets, inventário de conteúdo quando for site.
- Fazer pesquisa secundária: referências, concorrentes, relatos públicos.
- Conduzir entrevistas com usuários sobre comportamento passado, com mínimo de quatro por segmento no ciclo completo.
- Cruzar qualitativo e quantitativo antes de sintetizar.
Entregáveis: um relatório de descoberta com pesquisa de necessidades, entrevistas com stakeholders, caderno de entrevistas, insights quantitativos com fonte documentada, dados internos e secundários revisados, e inventário de conteúdo ou equivalente quando couber. A etapa fecha quando as perguntas centrais têm resposta, padrões emergem nas entrevistas (saturação) ou o mínimo foi atingido com evidência triangulada, e os stakeholders estão alinhados no problema, não na solução.
Definir
Pergunta central: qual problema vamos resolver?
Objetivo: convergir, saindo de “muitos problemas” para “este problema, nesta ordem, com evidência”, transformando dados brutos em declaração de problema, perfis úteis e base para idear.
O que se faz:
- Montar o caderno de entrevistas: índice e subseção narrativa por participante, com história, citações verbatim e oportunidades (nunca soluções).
- Escrever perfil de segmento ou proto-persona a partir do caderno.
- Mapear jornada quando o fluxo atravessa quatro ou mais estágios.
- Preencher a matriz CSD em ordem: temas priorizados, certezas/suposições/dúvidas, declaração de problema sem solução embutida.
- Fechar proposta de valor.
- Um sintetizador escreve de forma assíncrona; o time valida em revisão curta.
Entregáveis: um relatório de definição com perfil de segmento ou proto-persona com citações, mapa de jornada (quando aplicável), matriz CSD e declaração de problema, e proposta de valor.
Idear
Pergunta central: quais soluções existem?
Objetivo: divergir de novo, explorando alternativas antes de prototipar, até sair de “este é o problema” para “estas são as formas de resolvê-lo, e esta é a que vamos testar primeiro”.
O que se faz:
- Partir da declaração de problema e das oportunidades priorizadas no Definir.
- Para cada oportunidade, documentar pelo menos duas ou três soluções distintas antes de escolher uma, registrando o que descartou e por quê.
- Selecionar por critério (resolve a dor, viabilidade, escopo mínimo), não por votação.
- Quando o problema é “não encontro X”, considerar arquitetura de informação e taxonomia, não só nova funcionalidade.
- Documentar fluxo de usuário (happy path e erros) e comparar jornada atual com jornada futura.
- Definir corte incremental ou escopo de MVP.
Entregáveis: documento de soluções, jornada do usuário, arquitetura de informação ou taxonomia quando relevante, fluxo principal com caminhos de erro, e corte incremental ou MVP.
Prototipar
Pergunta central: como testamos rápido?
Objetivo: materializar a solução em algo que usuários possam tocar, clicar ou simular, testando ideias antes do código de produção, com fidelidade que sobe conforme o risco da suposição e não conforme a vontade de impressionar gestor ou coordenação.
O que se faz:
- Seguir a ordem: rascunhos (papel ou blocos cinza no Figma), wireframes, alta fidelidade só no que o teste precisa.
- Testar cedo no rascunho quando o fluxo é complexo. Validar hierarquia, labels e estados vazios ou de erro no wireframe.
- Revisar com o time técnico antes de mostrar ao stakeholder final.
- Documentar repasse para desenvolvimento quando for alta fidelidade: componentes, tokens, breakpoints, comportamento de interações.
Entregáveis: fluxo principal esboçado ou wireframeado, protótipo clicável no nível de fidelidade certo para o teste, estados vazio e erro considerados, e repasse documentado quando couber.
Avaliar
Pergunta central: funcionou? O que ajustar?
Objetivo: testar com usuários reais, medir satisfação e analytics, validar ou invalidar hipóteses com evidência, e decidir se o time segue, pivota ou para; se a hipótese cai, voltar a Prototipar, Idear, Definir ou Descobrir conforme a causa.
O que se faz:
- Escrever tarefas e critérios de sucesso antes de recrutar (objetivo do usuário, sem indicar onde clicar).
- Recrutar três a cinco usuários do segmento.
- Moderar com neutralidade, registrar resultados, calcular taxa de sucesso por tarefa, classificar severidade dos problemas.
- Medir satisfação (CSAT, CES ou NPS conforme o contexto).
- Complementar com analytics em produção ou protótipo instrumentado. Sintetizar achados e fechar o ciclo com decisão documentada.
Entregáveis: tarefas e critérios documentados antes do recrutamento, resultados de teste ligados às oportunidades do relatório, problemas classificados por severidade, baseline e métrica de satisfação escolhida quando aplicável, eventos de analytics alinhados à métrica, e resumo de discovery com adaptações e decisão final.
Depois do primeiro ciclo
Descoberta contínua cobre produto já em produção. O ritmo padrão cruza sinais (tickets, analytics, gravações) em revisão periódica: analytics mostra o que aconteceu, e entrevista ou teste entra só quando o sinal exige explicar o por quê. Quando surge feature grande, suposição de alto risco ou sinais conflitantes entre fontes, o time intensifica o qualitativo ou reabre Descobrir e Definir, mantendo o resumo de discovery vivo.
O ciclo é modular porque um projeto novo de três a quatro semanas percorre as cinco etapas com profundidade, enquanto prazo curto enxuga atividades com substituto mínimo documentado, e produto já em produção mantém evidência fresca e reabre etapas quando surge problema novo ou escopo grande.
Considerações
Documentar este guia foi, para mim, uma forma de deixar explícito o que o time já fazia em parte e o que ainda faltava padronizar no laboratório. Percebi cedo que método sem artefato some na pressa da entrega, assim como artefato sem pergunta vira formulário que ninguém preenche de verdade. O que tentei construir fica entre os dois: perguntas que forçam evidência, templates que mostram ao estagiário o que “pronto” significa, e espaço para adaptar o ciclo quando o prazo não comporta tudo, desde que a omissão fique registrada.
O guia dá ao laboratório uma referência comum para formar quem chega e manter decisões alinhadas entre projetos. É material que imagino sendo revisado conforme o time aprende o que funciona no contexto de EaD universitária.