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 guia cobre o ciclo completo, da pesquisa ao pós-lançamento, organizado em cinco etapas:
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.
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.
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 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.
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:
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.
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:
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.
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:
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.
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:
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.
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:
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.
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.
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.
No cenário científico atual, a busca por informação e a conexão entre pesquisadores são mais cruciais do que nunca. A explosão de dados, artigos e projetos em andamento, embora benéfica, muitas vezes cria um desafio: como organizar, acessar e contextualizar todo esse conhecimento de forma eficiente? Pesquisadores e estudantes se veem frequentemente navegando por um mar de informações, buscando as peças que se encaixam em seus próprios quebra-cabeças. Foi nesse contexto que surgiu a ideia do Sci-in: uma plataforma inovadora pensada para otimizar o fluxo de trabalho científico, promovendo a descoberta e a colaboração.
A inspiração para o Sci-in nasceu da observação das dificuldades enfrentadas por muitos na comunidade científica. A falta de uma ferramenta centralizada que pudesse não apenas armazenar, mas também interligar e apresentar o conhecimento de forma intuitiva, tornou-se evidente. Percebemos que era preciso ir além das bibliotecas digitais tradicionais, criando um ecossistema onde a ciência pudesse ser não apenas consumida, mas verdadeiramente vivida e compartilhada. O Sci-in surge, então, como a resposta a essa necessidade, um farol para a comunidade científica em busca de maior eficiência e conexão.
Equipe:
O desenvolvimento do Sci-In não foi baseado apenas em suposições, mas em um processo investigativo que buscou unir o rigor acadêmico à praticidade do design de experiência. Nossa pesquisa seguiu dois eixos: a fundamentação estratégica da ideia e a validação prática com quem realmente faz ciência.
Desde o rascunho inicial, o Sci-In foi pensado para ser um motor de impacto social. Norteamos o projeto pelos Objetivos de Desenvolvimento Sustentável (ODS) da ONU, especificamente os objetivos 9 e 10.
A ideia foi criar uma infraestrutura tecnológica que não apenas estimulasse a inovação, mas que quebrasse barreiras geográficas e financeiras.
O foco principal é a democratização do conhecimento: permitir que pesquisadores de instituições com menos fomento possam colaborar em pé de igualdade com grandes centros de investimento, equilibrando a balança da produção científica global.
Para sustentar a proposta, estudamos a literatura acadêmica sobre redes de cooperação. A teoria confirmou nossa hipótese: colaborar não é apenas “trabalhar junto”, é uma estratégia de eficiência. Identificamos que a união entre pesquisadores é o que permite:
Reduzir margens de erro através da revisão mútua;
Escalar a produtividade e o alcance das publicações;
Viabilizar estudos multidisciplinares que seriam impossíveis de forma isolada.
Para testar a aderência da plataforma, fomos a campo ouvir estudantes e pesquisadores. O diagnóstico foi revelador: existe um “vazio” entre as redes sociais profissionais e o ambiente acadêmico. Enquanto redes como o LinkedIn são vistas como espaços puramente mercadológicos, o Sci-In foi percebido como o elo que faltava para quem busca foco total na pesquisa.
“Faltava um espaço que não fosse apenas sobre o mercado de trabalho, mas sobre a construção do conhecimento em grupo”, relatou um dos participantes.
Por fim, analisamos o que já funciona no mercado. O estudo de plataformas consolidadas serviu para entender padrões de usabilidade que o público já domina. O objetivo não foi copiar, mas aprender com as convenções de UX (User Experience) para garantir que o Sci-In seja intuitivo desde o primeiro clique, permitindo que o pesquisador foque no que importa: a ciência, e não em aprender a mexer em uma ferramenta complexa.
Para que o Sci-In fosse mais do que um simples repositório de dados, dedicamos uma etapa fundamental à construção de sua Arquitetura de Informação (IA). Baseada nos princípios de organização lógica de conteúdo, a IA foi desenhada para garantir que a complexidade de uma rede científica se traduzisse em uma interface clara, minimizando o esforço cognitivo do pesquisador.
O percurso do usuário foi estruturado em camadas concêntricas, permitindo uma transição fluida entre o ambiente pessoal e o coletivo:
Acesse a publicação oficial no acervo da Universidade de Aveiro.
O projeto Sci-In foi desenvolvido sob os mais altos padrões de design estratégico e inovação social, o que culminou no seu reconhecimento como finalista do UNESCO Design Awards de 2025 (Future Designer International Innovation Design Awards). Esta premiação é um pilar da iniciativa global Science Decade, que visa transformar os sistemas nacionais de inovação para que estes respondam de forma mais eficaz às necessidades científicas e sociais da atualidade.
Alcançar a etapa final deste prêmio internacional destaca o Sci-In em diversos âmbitos:
Este marco não apenas coroa o esforço técnico e acadêmico da equipe da Universidade Federal do Espírito Santo, mas também posiciona o Sci-In como uma resposta concreta e contemporânea para os desafios da rede de pesquisa global.
A imersão de UX Strategy realizada na capital de São Paulo em outubro de 2025, fruto da parceria entre a Mergo e o Nubank, foi uma experiência verdadeiramente transformadora. O que mais me marcou foi entender, logo de cara, que o objetivo não era apenas absorver teorias, mas mergulhar na vivência prática e no trabalho colaborativo. Fomos instigados a usar a Inteligência Coletiva, onde cada membro do grupo contribuiu com suas habilidades para resolver desafios complexos de design e estratégia.
Esta jornada aconteceu a partir do projeto Conecta Fapes (uma parceria entre os laboratórios Forma e Leds), e tive o privilégio de trabalhar ao lado de um time incrível composto por mim, Dara Morati, Jaqueline Ferreira, Ana Clara Antunes e Jennifer Amaral.
Toda a nossa jornada foi estruturada em cima de frameworks e dinâmicas específicas que detalho a seguir:
Antes de qualquer desenho de interface, a imersão focou na visão holística do serviço. O objetivo aqui foi quebrar modelos hierárquicos e alinhar todos os colaboradores em torno da experiência do cliente.
O Business Model Canvas (BMC) é a ferramenta-chave para descrever como a organização cria, entrega e gera valor. No Nubank, isso significa olhar para a funcionalidade não apenas como um botão no app, mas como parte de um modelo de negócio.
Segmentos de Clientes: Identificamos os grupos específicos que a funcionalidade visa alcançar.
Propostas de Valor: Definimos os pacotes de produtos/serviços que criam valor, seja por inovação ou melhoria de algo existente.
Canais: Mapeamos como a proposta de valor chega ao cliente (comunicação, vendas e distribuição).
Fontes de Receita: Analisamos como o cliente paga por esse valor (subscrição, taxas, etc.) e se o preço é condizente com o que ele está disposto a investir.
Nesta fase, o foco mudou das metas de negócio para a felicidade do cliente. A principal ferramenta foi o Mapa de Empatia, desenvolvido pela XPLANE, para documentar uma hipótese de perfil de utilizador e humanizar os dados.
O mapa foi preenchido explorando seis dimensões críticas:
O que ele Vê? O contexto social, os amigos, o ambiente de trabalho e as ofertas que o mercado apresenta diariamente.
O que ele Ouve? A influência do que os amigos e o chefe dizem, além das mensagens que recebe de influenciadores.
O que ele Pensa e Sente? O que realmente importa para ele, as suas aspirações e preocupações que nem sempre são ditas publicamente.
O que ele Fala e Faz? O comportamento público, a aparência e como ele age em relação aos outros.
Dores: Os medos, frustrações e obstáculos práticos que ele enfrenta ao tentar usar o serviço.
Ganhos: O que ele considera sucesso, as suas necessidades reais e o que ele espera alcançar.
Após entender o utilizador, o grupo partiu para a fase de Inovação de Valor, que busca criar algo que pouco se pareça com os padrões anteriores.
A imersão reforçou que “todo planeamento é uma suposição”. Por isso, o processo seguiu a lógica de:
Este processo garante que a UX não seja apenas uma interface bonita, mas uma mentalidade estratégica para abordar desafios complexos de produtos e serviços.
No âmbito geral da área de Tecnologia da Informação, é comum que profissionais de desenvolvimento ainda tenham um conhecimento limitado sobre os princípios e a importância do design, especialmente nas áreas de experiência do usuário (UX) e design de interface (UI). Essa lacuna se dá, em parte, pela diferença de foco entre as áreas de desenvolvimento (voltada para aspectos técnicos e funcionais) e design (que prioriza a interação, usabilidade e acessibilidade para os usuários finais). Isso pode levar a uma subestimação do papel do design no sucesso dos projetos digitais.
Entender o valor das decisões de design é fundamental para que equipes técnicas e de design trabalhem de forma integrada e eficiente, promovendo produtos que sejam não apenas funcionalmente robustos, mas também intuitivos e agradáveis para quem os utiliza. O design vai muito além da estética, envolvendo princípios científicos que garantem uma experiência satisfatória, acessível e eficaz.
No caso específico do Laboratório LEDS (IFES), essa apresentação foi elaborada com o propósito de esclarecer e aproximar essa compreensão entre desenvolvedores e designers, incentivando um diálogo produtivo e a colaboração entre as equipes para melhorar a qualidade das soluções desenvolvidas. Para isso, foi montada uma apresentação baseada no contexto do projeto Conecta Fapes, em parceria com o Laboratório Forma da UFES. Dessa forma, o IFES serviu como contexto para essa iniciativa educativa, representando um exemplo da necessidade de integração entre áreas no setor de TI.
A apresentação foi estruturada para levar os desenvolvedores desde os conceitos fundamentais até a aplicação prática de diretrizes técnicas. O conteúdo abrange:
UX Design (Design de Experiência do Usuário) refere-se a como o usuário interage com o sistema como um todo. Envolve aspectos como facilidade de uso, eficiência, satisfação e a resposta emocional do usuário durante essa interação. É um processo que busca entender as necessidades reais do usuário, criando soluções que tornem sua jornada intuitiva, fluida e significativa.
UI Design (Design de Interface) diz respeito à parte visual e interativa do sistema, ou seja, tudo aquilo com que o usuário vê e interage diretamente — botões, menus, cores, tipografia, ícones, espaçamentos e layout. O objetivo é tornar a interface visualmente atraente, consistente e acessível, facilitando a navegação e o uso.
Esses dois campos, embora diferentes, são complementares e atuam juntos para criar experiências digitais eficazes e agradáveis.
Neste tópico, detalhamos as diretrizes técnicas que guiaram o desenvolvimento do projeto, focando em garantir uma interface funcional e acessível.
Uma das principais distinções que trouxemos para a equipe foi a diferença entre legibilidade e leiturabilidade.
Aplicação: No projeto, ressaltamos que uma fonte pode ser ótima para títulos por ser legível, mas péssima para o corpo do texto por prejudicar a leiturabilidade em textos longos. Além disso, evitamos o uso excessivo de caixa alta (ALL CAPS) em parágrafos, pois as hastes das letras minúsculas facilitam o reconhecimento das palavras pelo cérebro, tornando a leitura menos cansativa.
O uso de cores no projeto não é apenas estético, mas funcional e focado em acessibilidade.
Para organizar a informação de forma lógica, utilizamos princípios de espaçamento e grids.
Fundamentamos nossas decisões em leis psicológicas:
Integrar design e desenvolvimento não é apenas uma questão de “deixar as coisas bonitas”, mas sim de garantir que a solidez técnica da nossa equipa seja traduzida numa experiência fluida, lógica e acessível para quem utiliza o sistema.
Esta apresentação no Laboratório LEDS foi um marco importante para alinhar a nossa visão. No projeto Conecta Fapes, vimos na prática que quando os desenvolvedores compreendem o “porquê” por trás de uma decisão de espaçamento ou da escolha de uma paleta de cores, o processo de construção torna-se muito mais ágil e o produto final, substancialmente melhor.
A publicação “Transforme seu website em um aplicativo de web progressivo” foi elaborado durante meu período como estagiária, com o propósito de servir como documentação futura para o Laboratório de Design Instrucional. A publicação oferece uma análise detalhada sobre Progressive Web Apps (PWAs), destacando sua importância no desenvolvimento web moderno e sua capacidade de unir o melhor das aplicações nativas e web.
No conteúdo, são explorados conceitos fundamentais, como a definição das PWAs e suas características essenciais, como instalação rápida, funcionamento offline através do uso de Service Workers, notificações push e melhorias significativas no desempenho e na experiência do usuário. Além disso, o artigo detalha os componentes técnicos críticos para a construção de uma PWA funcional, incluindo a criação do Manifest, que define as propriedades visuais e comportamentais da aplicação, e estratégias eficientes de cache para garantir a disponibilidade do conteúdo mesmo sem conexão com a internet.
A publicação também aborda os benefícios trazidos pelas PWAs, como maior engajamento do usuário, facilidade de manutenção e compatibilidade multiplataforma, tornando-se uma alternativa versátil para projetos que buscam inovação e melhor performance.
Destinado a desenvolvedores iniciantes e profissionais da área, bem como a recrutadores com interesse em tecnologias emergentes, o artigo foi estruturado para oferecer um conteúdo técnico, porém acessível, facilitando a compreensão e fomentando a adoção dessas práticas no desenvolvimento frontend.
Assim, o material não apenas contribui para a minha formação, mas também visa apoiar a equipe do laboratório, servindo como um guia prático e referência para futuras implementações de PWAs.