flowchart TD
VPC([Value Proposition Canvas<br/>Módulo 13]) --> HP
subgraph HP["IDENTIFICAÇÃO DA HIPÓTESE CENTRAL"]
direction TB
H1["Quem é o usuário específico?"]
H2["Qual funcionalidade ou experiência<br/>o produto oferece?"]
H3["Qual comportamento ou resultado<br/>se espera observar?"]
H4["Por que isso deveria ocorrer?<br/>(base nos dados de empatia)"]
H1 --> H2 --> H3 --> H4
end
H4 --> HC(["Hipótese Central<br/>Acreditamos que [usuário],<br/>quando exposto a [funcionalidade],<br/>vai [resultado], porque [razão]."])
HC --> TIPO["Escolha do tipo e<br/>nível de fidelidade<br/>do protótipo"]
TIPO --> PROT([Protótipo construído<br/>para testar a hipótese])
PROT --> TESTE([Teste com usuário real])
TESTE --> APRE([Aprendizado documentado])
APRE --> ADJ([Ajustes específicos<br/>no projeto])
ADJ --> M15([Módulo 15<br/>Validação e Modelo de Negócio])
style VPC fill:#2c7bb6,color:#fff,stroke:#1a5a8a
style HP fill:#f5f0e8,color:#333,stroke:#c8a96e
style H1 fill:#4dac26,color:#fff,stroke:#2d7a14
style H2 fill:#4dac26,color:#fff,stroke:#2d7a14
style H3 fill:#4dac26,color:#fff,stroke:#2d7a14
style H4 fill:#4dac26,color:#fff,stroke:#2d7a14
style HC fill:#1a1a2e,color:#fff,stroke:#0d0d1a
style TIPO fill:#f07d02,color:#fff,stroke:#b85c00
style PROT fill:#7b3294,color:#fff,stroke:#561f6a
style TESTE fill:#d7191c,color:#fff,stroke:#a01010
style APRE fill:#74add1,color:#fff,stroke:#4a8ab0
style ADJ fill:#74add1,color:#fff,stroke:#4a8ab0
style M15 fill:#2c7bb6,color:#fff,stroke:#1a5a8a
Startup: Prototipação
Ao final deste módulo, você será capaz de:
compreender que um protótipo é um instrumento de aprendizagem e não uma versão incompleta do produto final, reconhecendo por que a busca por perfeição prematura é o erro mais comum — e mais caro — no desenvolvimento de produtos; conectar a hipótese central que seu grupo identificou no Módulo 13 ao tipo e ao nível de fidelidade corretos de protótipo para testá-la; distinguir com precisão os três níveis de fidelidade — baixo, médio e alto — e aplicar critérios objetivos para escolher o nível adequado para cada momento do projeto; identificar e produzir pelo menos um dos cinco tipos de protótipo mais relevantes para HealthTechs, incluindo protótipo em papel, wireframe navegável, encenação de serviço, Wizard of Oz e protótipo físico; conduzir uma sessão de teste com um usuário real seguindo o protocolo de três fases — preparação, sessão e debriefing — evitando os erros que invalidam os dados coletados; documentar observações de forma que separe o que foi visto do que foi interpretado; e sintetizar o aprendizado obtido no teste em ajustes específicos e documentados para o projeto da sua startup.
O protótipo como instrumento de aprendizagem
Existe uma tensão que quase todo estudante de medicina carrega quando chega ao projeto de startup, e ela aparece com força total no momento em que você precisa construir alguma coisa concreta pela primeira vez. Você passou anos aprendendo que imprecisão tem consequências sérias. Na clínica, uma dose errada, um diagnóstico mal fundamentado, um procedimento executado sem a técnica correta — esses erros têm custos reais e imediatos. Esse treinamento é valioso e necessário. Mas ele cria, como efeito colateral, uma relação com a imperfeição que pode ser devastadora para a inovação: a resistência visceral a produzir algo que você sabe que não está pronto.
O problema é que, no contexto de desenvolvimento de produtos, “esperar até estar pronto” é a forma mais lenta e mais cara possível de aprender. Uma startup que passa seis meses construindo um produto completo antes de mostrá-lo para qualquer usuário está apostando seis meses de trabalho em uma hipótese que nunca foi testada. Se a hipótese estiver errada — e as hipóteses de produto estão erradas com muito mais frequência do que a maioria das equipes espera — todo esse trabalho precisará ser refeito. O protótipo é exatamente a solução para esse problema: ele é o instrumento que permite testar a hipótese antes de investir no produto.
A definição mais precisa que você pode guardar é esta: um protótipo não é uma versão incompleta do produto final. É uma representação deliberadamente simplificada de um aspecto específico do produto, construída com o único objetivo de gerar aprendizado sobre uma hipótese específica. Essas duas diferenças — “deliberadamente simplificada” e “hipótese específica” — são o que separa um protótipo de uma demo, de um MVP (produto mínimo viável) e de um produto em desenvolvimento.
A palavra “deliberadamente” é importante aqui. Um protótipo não é incompleto por falta de tempo ou de recursos — é incompleto por escolha. Você escolhe o que incluir com base no que precisa aprender, não com base no que seria necessário para um produto completo. Isso significa que um protótipo pode ser uma folha de papel com caixas desenhadas a lápis, e isso não é sinal de que o trabalho foi feito com pressa ou descuido. É sinal de que quem o construiu entende qual é o seu propósito.
A cultura maker, que permeia a abordagem de design thinking que seu grupo vem praticando desde o Módulo 9, tem um princípio que resume esse entendimento de forma direta: construir para pensar. Quando você desenha uma tela de aplicativo no papel, você não está apenas representando uma ideia que já existe na sua cabeça — você está descobrindo partes da ideia que não existiam antes de você começar a desenhar. O ato de construir força a especificidade: você não consegue desenhar uma interface sem decidir onde cada botão fica, o que cada palavra significa, qual é o fluxo que o usuário percorre. E cada uma dessas decisões revela uma suposição que o grupo estava fazendo sem perceber.
Por que o perfeccionismo clínico atrapalha — e o que fazer com ele
A resistência ao protótipo imperfeito não é fraqueza nem preguiça — é uma heurística que funciona muito bem em um contexto e muito mal em outro. No contexto clínico, a heurística é: não faça antes de estar seguro de que está fazendo certo. No contexto de desenvolvimento de produto, a heurística oposta é a que funciona: faça rápido, descubra o que está errado, corrija, repita.
Existe um momento específico em que essa resistência aparece com mais força: quando um usuário real olha para o protótipo do grupo pela primeira vez. O impulso imediato é explicar — “isso é só um rascunho”, “ainda não funciona direito”, “imaginamos que a tela real teria outra cor”. Esse impulso precisa ser suprimido, e você vai entender exatamente por que mais adiante neste material. Por agora, basta registrar que a necessidade de explicar o protótipo antes de o usuário interagir com ele é o sinal mais claro de que o grupo ainda não separou o protótipo do produto.
A separação mental que você precisa fazer é a seguinte: o produto é o que seu grupo vai construir quando souber que a solução funciona. O protótipo é o que vai revelar se a solução funciona antes de você construir o produto. Eles servem a propósitos radicalmente diferentes, são julgados por critérios radicalmente diferentes e são construídos com investimentos de tempo radicalmente diferentes. Um protótipo ruim que gera aprendizado é infinitamente mais valioso do que um protótipo bonito que confirma apenas o que o grupo já acreditava.
Esse reposicionamento mental — de “o protótipo representa o produto” para “o protótipo representa uma pergunta” — é a mudança mais importante que este módulo pede de você. E ela é difícil precisamente porque vai contra a forma como você foi treinado a pensar sobre qualidade e sobre a relação entre esforço e resultado.
Da proposta de valor à hipótese testável
No Módulo 13, seu grupo completou o Value Proposition Canvas e redigiu um parágrafo de proposta de valor. Esse trabalho produziu algo específico que você talvez não tenha reconhecido explicitamente: uma hipótese central. A hipótese central é a afirmação mais importante que o Value Proposition Canvas faz sobre a relação entre o produto e o usuário — a afirmação que, se for falsa, invalida toda a lógica do projeto.
Para entender o que é uma hipótese central, compare dois tipos de afirmação que seu grupo pode estar fazendo sobre o produto. O primeiro tipo é uma afirmação descritiva: “nosso produto envia lembretes de consulta por WhatsApp com 48 horas de antecedência”. Essa afirmação pode ser verdadeira ou falsa dependendo de você construir ou não construir a funcionalidade, mas ela não depende do comportamento do usuário — ela descreve o produto. O segundo tipo é uma afirmação hipotética: “pacientes hipertensos acompanhados em UBSs que recebem lembrete por WhatsApp com 48 horas de antecedência comparecem mais às consultas de retorno do que os que não recebem”. Essa afirmação depende de como o usuário se comporta na realidade — ela é uma hipótese que pode ser testada.
A hipótese central do seu projeto está contida nos aliviadores de dor e criadores de ganho do Value Proposition Canvas. Ela é a afirmação que conecta a funcionalidade principal do produto a um resultado real na vida do usuário. Para identificá-la, seu grupo precisa completar a seguinte estrutura: “Acreditamos que [usuário específico], quando exposto a [funcionalidade ou experiência específica que o produto oferece], vai [comportamento ou resultado esperado], porque [razão baseada nos dados de empatia dos Módulos 9 e 10].”
O motivo pelo qual identificar a hipótese central com precisão é o passo mais importante antes de construir o protótipo é simples: o protótipo precisa ser construído para testar essa hipótese, e nada mais. Todo elemento do protótipo que não contribui para testar a hipótese central é desperdício — pior, é ruído que pode distrair tanto o usuário durante o teste quanto o grupo durante a análise dos resultados.
A diferença entre testar uma hipótese e demonstrar o produto
Existe uma distinção que separa protótipos que geram aprendizado real de protótipos que apenas confirmam o que o grupo já acredita, e ela é frequentemente ignorada por equipes inexperientes. Quando o objetivo declarado de um teste de protótipo é “mostrar o produto para o usuário e ver o que ele acha”, o grupo está demonstrando o produto. Quando o objetivo declarado é “colocar o usuário em contato com a funcionalidade X e observar se o comportamento Y ocorre”, o grupo está testando uma hipótese.
A diferença tem consequências diretas sobre como o protótipo é construído e como o teste é conduzido. Um protótipo feito para demonstração tende a ser construído de forma a apresentar o produto da forma mais favorável possível — todas as funcionalidades, todos os estados positivos do fluxo, sem erros. Um protótipo feito para testar uma hipótese é construído especificamente para revelar o que acontece quando o usuário encontra a dificuldade que a hipótese assume que o produto resolve.
Há ainda um terceiro tipo de protótipo, talvez o mais valioso de todos, que quase nenhuma equipe pensa em construir: o protótipo projetado para revelar que a hipótese está errada. A lógica contraintuitiva aqui é a seguinte — o protótipo mais valioso é aquele que tem a maior probabilidade de revelar que a hipótese central é falsa. Isso porque, se a hipótese é de fato falsa, você quer saber disso o mais cedo possível, antes de investir meses construindo um produto baseado em uma premissa incorreta. E a forma de maximizar a probabilidade de revelar uma hipótese falsa é construir o protótipo mais simples possível que coloque o usuário exatamente na situação em que a hipótese seria testada, sem nenhum recurso de apresentação que torne o produto mais palatável do que ele seria na realidade.
Esse princípio tem um nome no vocabulário do design thinking: “prototipagem de hipótese crítica” — você protótipa o que pode estar mais errado, não o que você já sabe que funciona.
Conexão com o Módulo 13: a hipótese central que seu grupo precisa testar neste módulo não precisa ser criada do zero. Ela está implícita na sua proposta de valor — especificamente no aliviador de dor mais importante do seu Value Proposition Canvas. Releia o aliviador de dor central do seu canvas e reformule-o como uma afirmação sobre o comportamento esperado do usuário. Esse é o ponto de partida para o protótipo.
Níveis de fidelidade — quanto é suficiente?
Uma das perguntas mais frequentes de grupos que constroem protótipos pela primeira vez é: “quanto detalhe o protótipo precisa ter?”. A resposta depende de uma única variável: o que você precisa aprender. E para responder a essa pergunta, você precisa entender os três níveis de fidelidade que existem no continuum de prototipagem e o que cada um é capaz — e não é capaz — de revelar.
O conceito de fidelidade em prototipagem não se refere à qualidade visual ou à elegância estética. Refere-se ao grau de correspondência entre o protótipo e o produto final em termos de aparência, interatividade e comportamento. Um protótipo de alta fidelidade se parece e se comporta muito próximo do produto final. Um protótipo de baixa fidelidade representa a estrutura e a lógica do produto de forma deliberadamente esquemática. A questão não é qual nível é melhor — é qual nível é mais adequado para a hipótese que precisa ser testada no momento em que o protótipo está sendo construído.
Baixa fidelidade — aprender rápido, errar barato
O protótipo de baixa fidelidade é construído com os materiais mais simples disponíveis: papel, post-its, canetas coloridas, cartolina, encenação ao vivo. Seu objetivo primário é testar a lógica fundamental da solução — se a ideia central faz sentido para o usuário, se o fluxo principal é compreensível, se o problema que o produto pretende resolver é de fato reconhecido como tal por pessoas reais.
A característica mais importante do protótipo de baixa fidelidade não é o material com que é feito — é a velocidade com que pode ser construído e a facilidade com que pode ser descartado e refeito. Um conjunto de telas de aplicativo desenhadas em papel pode ser produzido em quarenta minutos por dois membros do grupo, testado com um usuário em meia hora, descartado completamente com base no aprendizado obtido e refeito em mais quarenta minutos. Esse ciclo inteiro — da ideia ao aprendizado — pode acontecer em menos de duas horas. Com um protótipo digital de alta fidelidade, esse mesmo ciclo levaria dias ou semanas.
No contexto de HealthTechs, os protótipos de baixa fidelidade mais relevantes assumem formas diferentes dependendo do tipo de produto. Para aplicativos e interfaces digitais, o protótipo em papel é o mais comum: cada tela do aplicativo é desenhada em uma folha separada de papel, e o usuário “navega” entre as telas enquanto o facilitador troca fisicamente as folhas em resposta às ações declaradas pelo usuário. Para serviços — como um fluxo de teleconsulta, um processo de triagem ou uma jornada de acompanhamento de paciente — a encenação (ou role-play) é o equivalente: membros do grupo interpretam os diferentes agentes do serviço, e o usuário real participa como ele mesmo.
Existe ainda um tipo de protótipo de baixa fidelidade que é especialmente poderoso para testar hipóteses sobre comunicação e organização de informação: o storyboard. O storyboard é uma sequência de quadros desenhados que representa a jornada do usuário com o produto, do primeiro contato até o resultado desejado. Ele não testa a usabilidade de uma interface específica — testa se a narrativa de uso do produto faz sentido para o usuário, se as etapas são compreensíveis na ordem proposta e se o resultado final é percebido como valioso.
A limitação principal do protótipo de baixa fidelidade é que ele não revela problemas que dependem de interação real com uma interface funcional. Você não consegue testar, com papel, se uma notificação enviada em determinado horário gera mais engajamento do que uma enviada em outro horário. Você não consegue testar se a velocidade de carregamento de uma tela influencia a percepção de valor do produto. Você não consegue testar como o usuário se comporta quando o produto falha de uma forma inesperada. Essas questões exigem níveis mais altos de fidelidade. A pergunta que você precisa responder antes de decidir que precisa de um protótipo de maior fidelidade é: minha hipótese central depende de algum desses aspectos que o papel não consegue revelar?
Média fidelidade — testar a navegação e a comunicação
O protótipo de média fidelidade é, na prática, um mockup digital estático ou um wireframe navegável. Ferramentas como Figma e Canva permitem construir representações digitais das telas do produto com um grau de detalhamento visual maior do que o papel, e a versão navegável dessas ferramentas permite criar interações básicas — cliques que levam de uma tela para outra — sem precisar escrever nenhuma linha de código.
O protótipo de média fidelidade é mais adequado do que o papel quando a hipótese a ser testada envolve a compreensão da interface pelo usuário em um ambiente digital, a navegabilidade entre seções do produto, ou a clareza da hierarquia de informação em telas reais. Se a hipótese central do seu grupo for algo como “usuários conseguem completar o fluxo de registro de pressão arterial em menos de três passos sem instrução adicional”, você precisa de um protótipo navegável que represente esse fluxo com fidelidade suficiente para que o usuário interaja com ele de forma genuína.
A vantagem principal sobre o papel é a proximidade com o ambiente real de uso: o usuário está interagindo com uma tela digital, usando gestos digitais, em um contexto que se aproxima mais da experiência que teria com o produto final. Isso aumenta a validade ecológica do teste — a medida em que o comportamento observado no teste é um bom preditor do comportamento que ocorreria com o produto real.
A limitação do protótipo de média fidelidade é que ele demanda um investimento de tempo significativamente maior do que o papel. Uma sessão no Figma para construir um wireframe navegável de dez telas pode levar de quatro a oito horas para um grupo sem experiência prévia na ferramenta. Esse investimento só se justifica quando a hipótese a ser testada realmente requer interação digital — quando as questões que o paper prototype não conseguiu responder são de fato centrais para a validade da solução.
Alta fidelidade — quando é cedo demais
O protótipo de alta fidelidade é uma simulação interativa funcional que se aproxima do produto final em aparência, comportamento e, às vezes, em tecnologia. Pode envolver código real, dados reais ou infraestrutura real. No extremo, o protótipo de alta fidelidade é o que o ecossistema de startups chama de MVP — produto mínimo viável.
Para o estágio em que seu projeto se encontra agora, o protótipo de alta fidelidade é, quase sempre, prematuro. A razão é precisa: você ainda não validou a hipótese central do produto. Construir uma solução técnica completa antes de saber se a hipótese central está correta é exatamente o erro que a abordagem de design thinking foi desenvolvida para evitar. É o equivalente a escrever um protocolo de pesquisa completo, recrutar participantes, coletar dados e analisar resultados antes de ter formulado a hipótese que a pesquisa pretende testar.
Existe uma armadilha psicológica específica associada ao protótipo de alta fidelidade que tem um nome na literatura de economia comportamental: o custo irrecuperável, ou sunk cost em inglês. Quando um grupo investiu três semanas construindo uma solução funcional, a resistência a abandonar essa solução — mesmo diante de evidências de que ela não funciona — é muito maior do que se o grupo tivesse investido três horas num paper prototype. O protótipo de baixa ou média fidelidade protege o grupo do custo irrecuperável precisamente porque o investimento foi pequeno o suficiente para ser descartado sem dor.
A regra prática que você pode aplicar é a seguinte: suba para um nível de fidelidade maior apenas quando o nível atual não consegue mais responder às perguntas mais importantes sobre a hipótese central. E quando você subir, suba um nível de cada vez — não salte diretamente do papel para uma aplicação funcional.
A tabela a seguir resume os três níveis de fidelidade, organizando quando usar cada um, quais são as principais vantagens e limitações e qual é o custo típico de produção para equipes de estudantes sem experiência prévia em desenvolvimento de produto.
| Nível | Exemplos | Quando usar | Principais vantagens | Principais limitações | Custo típico |
|---|---|---|---|---|---|
| Baixo | Papel, post-its, storyboard, encenação, Wizard of Oz | Testar a lógica central da solução, fluxos de interação, compreensão do conceito | Rápido, barato, facilmente descartável e refeito, não intimidante para o usuário | Não revela problemas de usabilidade digital, de performance ou de comportamento em falhas | 1 a 4 horas |
| Médio | Wireframe navegável (Figma, Canva, Marvel) | Testar navegabilidade, hierarquia de informação, fluxo em ambiente digital | Próximo do ambiente real de uso, revela problemas de interface sem código | Mais lento de produzir, exige familiaridade com a ferramenta | 4 a 16 horas |
| Alto | Simulação funcional, MVP, código real | Testar hipóteses que dependem de comportamento real com produto funcional | Máxima validade ecológica | Investimento alto, difícil de descartar (sunk cost), prematuro se hipótese central não foi testada | Semanas a meses |
Armadilha comum: grupos de estudantes tendem a subestimar o protótipo de baixa fidelidade e a superestimar o de alta fidelidade. Protótipos bonitos em Figma frequentemente passam em testes de usabilidade porque o usuário se impressiona com a aparência e suaviza as críticas. Protótipos em papel provocam reações mais brutas e mais informativas precisamente porque o usuário não tem como confundir o rascunho com o produto.
Tipos de protótipo para HealthTechs
Os produtos que emergem de projetos de HealthTech raramente pertencem a uma única categoria. Eles combinam interfaces digitais, serviços de saúde, dispositivos físicos e fluxos de comunicação — às vezes tudo ao mesmo tempo. Por isso, é útil conhecer os cinco tipos de protótipo mais relevantes para o contexto de saúde, entendendo o que cada um testa e quando cada um é a escolha mais adequada.
Protótipo em papel
O protótipo em papel é a forma mais antiga e mais versátil de prototipagem de interfaces digitais. Cada tela do aplicativo ou sistema é representada em uma folha de papel separada. Elementos interativos — botões, menus, campos de formulário — podem ser representados como recortes de papel sobrepostos que o facilitador move em resposta às ações declaradas pelo usuário durante o teste.
Para uma HealthTech que desenvolve um aplicativo de acompanhamento de pacientes com hipertensão, o protótipo em papel representaria telas como: a tela inicial com o histórico de medições, a tela de registro de uma nova medição, a notificação de alerta quando a pressão ultrapassa o limiar configurado, e a tela de agendamento da próxima consulta. O usuário “navega” pelo aplicativo dizendo “tocaria aqui” ou “abriria esse menu”, e o facilitador troca as folhas de papel correspondentes.
O que esse tipo de protótipo testa com eficácia é a compreensibilidade do fluxo principal, a clareza dos rótulos e da hierarquia de informação, e a localização intuitiva das funcionalidades mais importantes. O que ele não testa — e não precisa — é se a paleta de cores é agradável ou se as animações de transição são suaves.
A instrução prática para construir um protótipo em papel eficaz é: comece pelas três ou quatro telas que compõem o fluxo principal — o caminho que um usuário percorre da abertura do aplicativo até a realização da tarefa central que sua hipótese afirma ser valiosa. Não construa todas as telas possíveis antes de testar. Construa o mínimo necessário para expor o usuário à situação que sua hipótese descreve.
Protótipo de serviço — encenação
Muitas HealthTechs não são apenas aplicativos — são serviços que envolvem múltiplos agentes humanos, processos de comunicação e fluxos de informação clínica. Para esse tipo de produto, o protótipo mais adequado não é uma representação visual — é uma encenação ao vivo do serviço.
O protótipo de serviço por encenação funciona da seguinte forma: membros do grupo interpretam os diferentes agentes do serviço — o médico, a recepcionista, o sistema automatizado, o profissional de saúde que faz o acompanhamento remoto — e o usuário real participa como ele mesmo, na sua posição natural dentro do fluxo. A interação ocorre em tempo real, como uma peça de teatro, e o grupo observa como o usuário se comporta, o que ele entende, o que o confunde e quais são seus pontos de resistência.
Um exemplo concreto no contexto de saúde: uma startup que desenvolve um serviço de segunda opinião médica online pode encenar o processo de solicitação de consulta, o envio de documentos médicos, a interação com o especialista por videoconferência e o recebimento do laudo. Um usuário real — alguém que poderia genuinamente usar o serviço — percorre esse fluxo com os membros do grupo nos papéis dos profissionais, e as reações do usuário em cada etapa revelam hipóteses que nenhuma tela de aplicativo poderia testar.
O que a encenação testa de forma única é a experiência emocional do serviço — como o usuário se sente durante cada interação, em que momentos se sente respeitado ou desrespeitado, em que momentos o fluxo acelera o que importa e em que momentos cria burocracia desnecessária. Esses aspectos são invisíveis em interfaces digitais, mas são frequentemente os determinantes mais importantes da adesão ao serviço de saúde.
Wizard of Oz
O protótipo Wizard of Oz é uma das técnicas mais elegantes e mais subestimadas do repertório de prototipagem. O nome vem do conto em que o poderoso mágico de Oz é, na realidade, um homem comum operando alavancas e botões atrás de uma cortina — criando a ilusão de magia. No contexto de protótipo, o princípio é o mesmo: o usuário acredita que está interagindo com um sistema automatizado, mas na realidade um ser humano está executando manualmente as ações que o sistema executaria.
O Wizard of Oz é especialmente valioso para HealthTechs que pretendem incorporar automação, inteligência artificial ou decisões algorítmicas. Imagine uma startup que desenvolve um chatbot de triagem de sintomas para pronto-atendimento. Construir o algoritmo real de triagem antes de saber se os usuários vão usar o chatbot de forma genuína seria um investimento prematuro enorme. Com o Wizard of Oz, o usuário interage com uma interface de chatbot real, mas as respostas são digitadas em tempo real por um membro do grupo em outra sala — um médico ou estudante avançado de medicina que sabe responder adequadamente. O usuário experimenta a interação como se fosse automatizada. O grupo observa se a interface é usada como esperado, se as perguntas do chatbot são compreendidas, se as respostas são percebidas como úteis, e se o usuário completaria o fluxo de triagem até o final.
Esse tipo de protótipo testa algo muito específico: se a proposta de valor do produto existe independentemente da tecnologia que o implementa. Se o chatbot de triagem com humano por trás for percebido como útil, existe uma hipótese sólida de que a versão automatizada também seria útil. Se o usuário desistir a meio caminho, confiar menos na resposta do que numa consulta presencial, ou não entender o que fazer com a orientação recebida, esses problemas provavelmente persistiriam na versão automatizada — e você descobriu isso antes de investir meses em desenvolvimento de IA.
Protótipo físico
Quando a HealthTech envolve um dispositivo físico — um sensor de monitoramento, um acessório vestível, um equipamento de diagnóstico simplificado — o protótipo precisa ter dimensão física. A cultura maker entra aqui com toda a sua força: papelão, espuma de modelar, impressão 3D em baixa resolução, componentes eletrônicos básicos e materiais de artesanato são os instrumentos de construção.
Um protótipo físico de baixa fidelidade para um dispositivo médico não precisa funcionar — precisa ter o tamanho, o peso e a forma aproximados do dispositivo real para que o usuário possa simular como o usaria. Um estetoscópio digital que transmite dados para um aplicativo pode ser prototipado como um cilindro de papelão com um cabo, suficiente para testar se o profissional de saúde consegue posicioná-lo com uma mão enquanto usa o outro braço para segurar o tablet com o aplicativo, e se o tamanho estimado seria compatível com o uso durante uma consulta de atenção primária.
O que o protótipo físico revela de forma única são os problemas ergonômicos, de contexto de uso e de integração com o fluxo de trabalho clínico existente — todos aspectos que nenhuma tela digital é capaz de simular. A hipótese que um protótipo físico testa, portanto, não é sobre funcionalidade digital — é sobre usabilidade no mundo físico, sobre encaixe no ambiente clínico e sobre aceitabilidade por parte dos profissionais que precisariam incorporar o dispositivo à sua prática.
O diagrama a seguir representa a árvore de decisão que seu grupo pode usar para escolher o tipo de protótipo mais adequado para a hipótese central do projeto. As decisões são baseadas no tipo de produto, no aspecto da solução que a hipótese testa e no nível de fidelidade requerido.
flowchart TD
START([Hipótese central definida]) --> Q1{O produto tem<br/>componente físico?}
Q1 -->|Sim| Q2{O componente físico<br/>é o que a hipótese testa?}
Q1 -->|Não| Q3{O produto é<br/>principlamente um serviço<br/>com múltiplos agentes?}
Q2 -->|Sim| PF([Protótipo Físico<br/>papelão · espuma · impressão 3D])
Q2 -->|Não| Q3
Q3 -->|Sim| Q4{A hipótese envolve<br/>automação ou IA<br/>que ainda não existe?}
Q3 -->|Não| Q5{A hipótese envolve<br/>navegação em<br/>interface digital?}
Q4 -->|Sim| WOZ([Wizard of Oz<br/>humano operando o sistema<br/>por trás da interface])
Q4 -->|Não| ENC([Encenação / Role-play<br/>membros interpretam agentes<br/>usuário real participa])
Q5 -->|Sim — fluxo básico e lógica| PP([Protótipo em Papel<br/>telas desenhadas · recortes])
Q5 -->|Sim — usabilidade em dispositivo real| WF([Wireframe Navegável<br/>Figma · Canva · Marvel])
style START fill:#2c7bb6,color:#fff,stroke:#1a5a8a
style Q1 fill:#f07d02,color:#fff,stroke:#b85c00
style Q2 fill:#f07d02,color:#fff,stroke:#b85c00
style Q3 fill:#f07d02,color:#fff,stroke:#b85c00
style Q4 fill:#f07d02,color:#fff,stroke:#b85c00
style Q5 fill:#f07d02,color:#fff,stroke:#b85c00
style PF fill:#7b3294,color:#fff,stroke:#561f6a
style WOZ fill:#d7191c,color:#fff,stroke:#a01010
style ENC fill:#4dac26,color:#fff,stroke:#2d7a14
style PP fill:#1a9641,color:#fff,stroke:#0d5c27
style WF fill:#74add1,color:#fff,stroke:#4a8ab0
Observação prática: seu grupo não precisa escolher apenas um tipo de protótipo. Na prática, muitas HealthTechs combinam dois tipos no mesmo teste — por exemplo, uma encenação do fluxo de serviço com um protótipo em papel das telas digitais que ocorrem em alguns pontos desse fluxo. O critério para combinar tipos é o mesmo: cada componente do protótipo deve existir porque a hipótese central exige que ele seja testado.
O protocolo de teste com usuário
Construir o protótipo é a metade mais simples do trabalho deste módulo. A metade que gera o aprendizado real é o teste com o usuário — e o teste precisa ser conduzido com um protocolo, porque sem protocolo ele coleta impressões, não dados. A diferença entre impressões e dados é a diferença entre “o usuário pareceu gostar” e “o usuário completou o fluxo principal em quatro minutos, hesitou por vinte e dois segundos antes de encontrar o botão de confirmação, e perguntou duas vezes o que o campo ‘médico responsável’ significava”.
O protocolo de teste com usuário que você vai aprender aqui é organizado em três fases sequenciais: preparação, sessão de teste e debriefing. Cada fase tem objetivos específicos, ações específicas e erros específicos que precisam ser evitados.
Fase 1 — Preparação
A preparação começa muito antes de o usuário chegar. O primeiro passo é transformar a hipótese central do grupo em uma tarefa específica que o usuário será convidado a realizar durante a sessão. A tarefa precisa ser descrita de forma que represente uma situação real de uso — não uma instrução de teste. “Use o aplicativo para registrar a sua pressão arterial de hoje” é uma tarefa bem formulada. “Clique no botão de registro e preencha o formulário” é uma instrução de teste que direciona o usuário e invalida a observação.
O segundo passo é definir com precisão o que o grupo vai observar durante a sessão. Quais comportamentos específicos confirmariam a hipótese? Quais comportamentos específicos a contradiriam? Um grupo que testa a hipótese “usuários encontram a funcionalidade de agendamento de consulta de forma intuitiva, sem precisar de instrução” precisa ter definido previamente: o que conta como “encontrar de forma intuitiva”? Menos de trinta segundos sem perguntar? Menos de três cliques? Sem nenhuma expressão de confusão verbal ou não verbal?
O terceiro passo é preparar os materiais: o protótipo completo e funcional para o fluxo que será testado, uma folha de observação com os comportamentos que o grupo vai registrar, e o roteiro do facilitador — a sequência exata de instruções e perguntas que o facilitador vai usar durante a sessão, redigido com antecedência para evitar improviso.
O quarto passo — frequentemente ignorado por grupos iniciantes — é realizar um teste piloto com um membro do próprio grupo que não participou diretamente da construção do protótipo. O teste piloto não testa o usuário: testa o protocolo. Ele revela se a tarefa está formulada de forma compreensível, se o protótipo está completo o suficiente para o fluxo proposto, e se o roteiro do facilitador está claro.
Fase 2 — Sessão de teste
A sessão de teste tem um único princípio organizador que contradiz todos os instintos naturais de quem construiu o protótipo: o facilitador apresenta a tarefa e então fica em silêncio. Não explica, não ajuda, não reage. Observa e registra.
A sequência da sessão começa com uma breve contextualização ao usuário — não sobre o produto, mas sobre o processo. O facilitador explica que o objetivo do exercício é entender como a pessoa usa o produto, que não existe resposta certa ou errada, que o que está sendo avaliado não é a competência do usuário mas a qualidade do produto, e que o usuário pode e deve verbalizar em voz alta o que está pensando enquanto realiza a tarefa.
Essa última instrução — “verbalize o que está pensando enquanto usa” — é o que a literatura de usabilidade chama de técnica do “think aloud” (pensar em voz alta). Ela é o mecanismo que transforma uma sessão de observação silenciosa em uma fonte rica de dados sobre o modelo mental do usuário. Quando o usuário diz “estou olhando para esse ícone mas não sei o que ele significa” ou “esperava que o botão de confirmação ficasse aqui em baixo, mas está em cima”, ele está revelando exatamente o que o grupo precisa saber para refinar o protótipo.
Enquanto o usuário realiza a tarefa, dois membros do grupo devem registrar observações simultaneamente — um focado no comportamento verbal (o que o usuário diz) e outro no comportamento não verbal (onde ele olha, onde hesita, quais expressões faciais ocorrem, quais gestos são feitos). A divisão de papéis é importante porque um observador sozinho inevitavelmente perde informação.
O facilitador só intervém em duas situações: quando o usuário pede diretamente uma informação que é necessária para continuar a tarefa, e quando a sessão inteira está prestes a parar por uma razão externa ao protótipo (como uma interrupção do ambiente). Em ambos os casos, a intervenção deve ser mínima e registrada na folha de observação como um dado — o fato de o usuário precisar de ajuda já é um dado relevante.
Fase 3 — Debriefing
O debriefing ocorre imediatamente após o usuário completar a tarefa — ou após o tempo estipulado para a sessão se esgotar. É uma conversa curta e estruturada, de dez a quinze minutos, cujo objetivo é aprofundar as observações feitas durante a sessão com as perspectivas do próprio usuário.
As perguntas do debriefing são abertas e retrospectivas. Perguntas eficazes incluem: “Qual parte do processo você achou mais simples?”, “Em que momento você sentiu mais incerteza sobre o que fazer a seguir?”, “O que você esperava encontrar em algum ponto e não encontrou?”, “Se você precisasse usar isso na sua rotina, o que te impediria?”. Perguntas ineficazes — e que devem ser evitadas — incluem qualquer pergunta com a palavra “gostou” (“você gostou da interface?”), perguntas que pressupõem uma resposta positiva (“foi fácil de usar, não foi?”) e perguntas hipotéticas abstratas (“você acha que outras pessoas usariam isso?”).
O debriefing encerra-se com o facilitador revelando o objetivo real do teste — que o protótipo foi construído para testar uma hipótese específica — e agradecendo a participação. Esse momento de revelação é importante: ele trata o participante como parceiro do processo de aprendizagem, não como sujeito de um experimento.
sequenceDiagram
participant G as Grupo (Facilitador)
participant U as Usuário Real
participant O as Observadores (2)
Note over G,O: FASE 1 — PREPARAÇÃO (antes da sessão)
G->>G: Define tarefa baseada na hipótese central
G->>G: Prepara folha de observação com comportamentos-alvo
G->>G: Redige roteiro do facilitador
G->>G: Realiza teste piloto interno
Note over G,U,O: FASE 2 — SESSÃO DE TESTE
G->>U: Contextualiza o processo (não o produto)
G->>U: Instrui sobre o "think aloud"
G->>U: Apresenta a tarefa
U->>U: Realiza a tarefa, verbalizando o pensamento
O->>O: Registra comportamento verbal e não verbal
G->>G: Silêncio (observa, não intervém)
U-->>G: Pede ajuda (registrado como dado)
G->>U: Resposta mínima se necessário
Note over G,U: FASE 3 — DEBRIEFING
G->>U: Perguntas abertas retrospectivas
U->>G: Perspectiva sobre a experiência
G->>U: Revela objetivo do teste
G->>U: Agradece a participação
Note over G,O: PÓS-SESSÃO (sem o usuário)
G->>O: Consolidação imediata das observações
O->>G: Síntese de padrões e aprendizados
Os erros que invalidam o teste
Existe um conjunto de erros que são cometidos de forma quase universal por grupos que conduzem testes de protótipo pela primeira vez, e eles têm algo em comum: todos eles decorrem do desejo de apresentar o produto da forma mais favorável possível, em vez de aprender com o comportamento real do usuário.
O primeiro e mais frequente erro é explicar o produto antes de iniciar a tarefa. “Então, o que a gente fez foi um aplicativo para pacientes hipertensos, a ideia é que você use para registrar sua pressão e agendar consultas, e tem também uma função de notificação, mas a gente ainda não prototipou essa parte…” Cada palavra dessa explicação contamina os dados da sessão inteira. Se o usuário precisar de explicação antes de começar, a necessidade de explicação já é um dado importante. Suprimir esse dado ao explicar é exatamente o oposto do que o teste deveria fazer.
O segundo erro é ajudar o usuário quando ele hesita ou se confunde. A confusão do usuário é dado. Quando o facilitador diz “não, aquele botão é para outra coisa, tente o de cima”, ele está apagando o registro de que o usuário se confundiu — que é provavelmente a informação mais importante que a sessão poderia revelar.
O terceiro erro é fazer perguntas direcionadas durante a sessão. “Você acha que a organização das telas ficou intuitiva?” pressupõe que o usuário deveria avaliar “intuitivo” como categoria relevante, e que a resposta positiva seria a correta. Perguntas direcionadas produzem respostas socialmente desejáveis, não observações genuínas.
O quarto erro — talvez o mais fácil de cometer e o mais prejudicial de todos — é fazer o teste com membros do próprio grupo ou com amigos próximos que conhecem o projeto. Um colega que sabe que você passou duas semanas construindo o protótipo tem todos os incentivos afetivos para dizer que ficou ótimo. O teste precisa ser feito com pessoas que genuinamente correspondem ao perfil de usuário identificado no Mapa de Empatia dos Módulos 9 e 10 e que não têm nenhuma relação com o projeto.
Recrutando participantes para o teste
A qualidade de um teste de protótipo depende de dois fatores em igual medida: a qualidade do protótipo e a adequação do participante. Um participante inadequado pode tornar inúteis mesmo os dados mais cuidadosamente coletados, porque o comportamento observado não é um bom preditor do comportamento do usuário real.
O participante adequado é aquele que corresponde ao perfil de usuário que seu grupo definiu no Módulo 9 e aprofundou no Módulo 10. Esse perfil inclui características demográficas, mas vai além delas — inclui o contexto de uso, as tarefas que o usuário realiza rotineiramente, o nível de familiaridade com tecnologia e, no contexto de saúde, a condição, papel ou posição no sistema de saúde que faz com que o produto seja relevante para essa pessoa.
Para uma HealthTech voltada a médicos que atuam em pronto-atendimento, um participante adequado é um médico que atua em pronto-atendimento — não um estudante de medicina do quinto semestre que nunca trabalhou num pronto-atendimento, não um enfermeiro que atua num pronto-atendimento, e certamente não um amigo do grupo que é arquiteto. A aproximação ao perfil real importa de forma substantiva porque os modelos mentais, as barreiras de uso e os comportamentos de interação são completamente diferentes entre perfis distintos.
O teste mínimo viável com usuários
Existe uma crença entre equipes iniciantes em pesquisa com usuários de que um teste com poucos participantes não é válido estatisticamente e, portanto, não tem valor. Essa crença confunde dois tipos muito diferentes de pesquisa. A pesquisa quantitativa — aquela que usa questionários, escalas e análise estatística para medir a frequência de comportamentos em populações — de fato requer amostras grandes para ser válida. O teste de protótipo qualitativo é um tipo diferente de pesquisa, com uma lógica diferente.
Jacob Nielsen, um dos pesquisadores mais influentes na área de usabilidade, demonstrou com base em dados empíricos que 85% dos problemas de usabilidade mais importantes de uma interface são revelados com apenas cinco usuários bem escolhidos. A curva de retorno marginal de cada usuário adicional é decrescente: o quinto usuário revela muito menos problemas novos do que o primeiro, e o décimo revela quase nada que os cinco anteriores já não tenham revelado.
Para o estágio do seu projeto, a conclusão prática é: um teste com um único usuário genuinamente adequado ao perfil definido no Mapa de Empatia é infinitamente mais valioso do que um teste com cinco membros do próprio grupo. Não espere ter cinco usuários antes de testar — teste com o primeiro usuário adequado que você conseguir recrutar, aprenda com esse teste, ajuste o protótipo e então, se possível, teste com um segundo e um terceiro usuário para verificar se os padrões se repetem.
Encontrar participantes no contexto de medicina não é tão difícil quanto parece. Médicos, enfermeiros e outros profissionais de saúde que conhecem membros do grupo, pacientes que já participaram de atividades de extensão da faculdade, funcionários do hospital universitário que correspondem ao perfil — todas essas são fontes legítimas. O requisito não é neutralidade absoluta do participante em relação ao grupo; é apenas que o participante corresponda ao perfil de usuário e não conheça os detalhes do projeto.
Registrar, interpretar e aprender
A sessão de teste gera uma quantidade de informação que pode parecer desorganizada imediatamente após o término: anotações dos dois observadores, impressões do facilitador, citações diretas do usuário, comportamentos não verbais registrados e as respostas do debriefing. Transformar essa massa de informação em aprendizado utilizável exige um método tão preciso quanto o método de conduzir o teste.
O primeiro passo após o término da sessão — e ele deve ocorrer enquanto a memória ainda está fresca, idealmente nos quinze minutos imediatamente seguintes — é a consolidação das observações. O facilitador e os dois observadores se reúnem e, sem discutir ainda o significado do que foi observado, registram em post-its ou em uma planilha compartilhada cada observação específica: cada hesitação, cada erro de navegação, cada comentário espontâneo, cada expressão de confusão ou satisfação, cada ponto em que o usuário pediu ajuda ou fez uma pergunta.
Separar observações de interpretações
A distinção mais importante em todo o processo de documentação de testes de usabilidade é a separação entre o que foi observado e o que o observador interpreta sobre o que foi observado. Essa distinção não é burocrática — ela protege o grupo de confirmar as próprias crenças em vez de aprender com o comportamento real do usuário.
Uma observação é uma descrição objetiva do comportamento do usuário: “O participante passou quarenta e cinco segundos na tela inicial sem interagir com nenhum elemento antes de dizer ‘não sei por onde começar’.” Uma interpretação é a explicação que o observador oferece para esse comportamento: “O participante não entendeu a funcionalidade principal porque a hierarquia visual da tela inicial não deixa claro qual é a ação primária.”
A interpretação pode estar correta, mas pode igualmente estar errada. O participante pode ter hesitado não porque a hierarquia visual estava confusa, mas porque estava distraído por um barulho externo, ou porque a tarefa foi formulada de forma ambígua, ou porque tem um padrão de uso de aplicativos que começa sempre pela exploração antes da ação. A única forma de separar essas hipóteses alternativas é manter as observações separadas das interpretações durante o processo de documentação, e só tentar interpretar depois de ter registrado todas as observações com precisão.
O método prático para essa separação é simples: use um formato com duas colunas. Na coluna esquerda, escreva a observação na forma mais neutra e descritiva possível: o que o usuário fez, disse ou expressou. Na coluna direita, escreva a interpretação possível — sempre formulada como hipótese, não como conclusão. “Pode indicar que…” ou “Sugere que…” são formas de redigir interpretações que mantêm o estado epistêmico correto.
Identificando padrões e o que constitui evidência
Quando o grupo testa com mais de um participante — o que é ideal mesmo que nem sempre possível nas condições deste módulo — o passo seguinte é identificar padrões nas observações. Um padrão é um comportamento ou comentário que se repete de forma similar em mais de um participante. O padrão é mais informativo do que qualquer observação isolada porque reduz a probabilidade de que o comportamento observado seja específico de um indivíduo em vez de uma característica da interação com o protótipo.
Para decidir o que fazer com os dados coletados, é útil distinguir três tipos de resultado possível. O primeiro tipo é a confirmação da hipótese: o usuário se comportou de uma forma consistente com o que a hipótese previa. Um resultado de confirmação não significa que a hipótese está provada — significa que os dados coletados são consistentes com ela e que o grupo tem base para continuar desenvolvendo a solução na direção atual. No estágio do protótipo, confirmação é sinal de continuar, não de parar de testar.
O segundo tipo é a evidência parcial: o usuário se comportou de uma forma consistente com a hipótese em alguns aspectos mas inconsistente em outros. Esse é o resultado mais comum e mais informativo, porque revela quais partes da hipótese são robustas e quais precisam ser refinadas. Um resultado de evidência parcial é sinal de ajuste seletivo — manter o que funcionou, modificar o que não funcionou.
O terceiro tipo é a invalidação da hipótese: o usuário se comportou de uma forma fundamentalmente inconsistente com a hipótese central. Por exemplo, se a hipótese era “usuários completarão o registro de pressão diariamente se o fluxo tiver menos de três passos” e o usuário declarou, durante o debriefing, que não registraria a pressão diariamente independentemente do número de passos porque não tem o hábito de medir a pressão em casa, a hipótese foi invalidada. Note que o problema não é o protótipo — é a suposição central sobre o comportamento do usuário. Um resultado de invalidação não é fracasso. É o resultado mais valioso que um teste de protótipo pode produzir, porque ele poupa o grupo de continuar desenvolvendo uma solução baseada em uma premissa incorreta.
A tabela a seguir organiza os três tipos de resultado do teste de protótipo, com exemplos no contexto de HealthTech e a ação recomendada para cada um.
| Tipo de resultado | Descrição | Exemplo em HealthTech | Ação recomendada |
|---|---|---|---|
| Confirmação | Comportamento do usuário consistente com a hipótese central | Usuário completou o fluxo de registro em menos de 3 passos sem pedir ajuda e verbalizou que repetiria o uso | Continuar desenvolvendo na direção atual; testar aspectos secundários na próxima iteração |
| Evidência parcial | Comportamento consistente em alguns aspectos, inconsistente em outros | Usuário completou o registro mas declarou que não entenderia o gráfico de histórico sem explicação | Ajustar o aspecto problemático específico; manter o que funcionou; re-testar o ajuste |
| Invalidação | Comportamento fundamentalmente inconsistente com a hipótese central | Usuário declarou que não mediria a pressão em casa independentemente da interface, porque não tem o equipamento | Reavaliar a premissa central do produto; considerar pivot ou reformulação da hipótese; novo teste antes de continuar |
O ciclo de iteração
O protótipo não é um evento único — é um ponto em um ciclo contínuo. A metodologia Lean Startup, desenvolvida por Eric Ries e amplamente adotada no ecossistema de startups globalmente, organiza esse ciclo em três fases que se repetem: construir, medir e aprender. No vocabulário de Ries, o ciclo é chamado de build-measure-learn loop, e a velocidade com que um time consegue percorrê-lo completamente é um dos principais preditores do sucesso de uma startup em estágio inicial.
Construir significa produzir o mínimo necessário para gerar aprendizado — não o produto, não o MVP completo, mas o protótipo mais simples possível que coloca a hipótese central em contato com a realidade. Medir significa coletar dados do comportamento real de usuários reais em contato com o que foi construído — não opiniões, não intenções declaradas, mas comportamentos observáveis. Aprender significa interpretar os dados com rigor suficiente para decidir o que mudar e em que direção, antes de começar o próximo ciclo.
O que torna o loop valioso não é a qualidade de qualquer ciclo individual — é a velocidade de repetição. Um grupo que conclui três ciclos completos de build-measure-learn em um dia de trabalho, com protótipos de papel, aprende mais sobre seu produto do que um grupo que passa o mesmo dia construindo um protótipo digital sofisticado que ainda não foi testado.
Pivotar ou persistir?
Um dos conceitos mais importantes — e mais mal compreendidos — no vocabulário do Lean Startup é o pivot. Na linguagem comum, “pivotar” é frequentemente usado de forma vaga para descrever qualquer mudança de direção do projeto. Na definição precisa de Ries, um pivot é uma mudança estruturada em uma ou mais hipóteses fundamentais do modelo de negócio, motivada por evidência de teste, que mantém o aprendizado acumulado até aquele ponto.
Essa definição precisa tem duas implicações importantes. A primeira é que um pivot não é uma desistência — é uma resposta informada por dados. Um grupo que descobre, no teste do protótipo, que o usuário real não tem o comportamento que a hipótese central supunha não está “falhando” ao pivotar — está aplicando o aprendizado gerado pelo protótipo exatamente da forma para a qual o protótipo foi construído. A segunda implicação é que um pivot não é aleatório — ele é estruturado. O grupo muda uma dimensão específica da hipótese com base em uma evidência específica, e mantém as outras dimensões que foram confirmadas pelos dados.
O contrário do pivot é persistir: manter a direção atual e refinar o protótipo ou a execução com base nos aprendizados do teste. Persistir é a resposta correta quando os dados de teste confirmam a hipótese central mas revelam problemas de execução — quando o usuário entendeu o valor do produto mas teve dificuldade com aspectos específicos da interface ou do fluxo. Nesses casos, o problema não é a hipótese — é o protótipo. E a solução é construir um protótipo melhor para o mesmo teste, não mudar a hipótese.
A confusão entre pivot e persistir é um dos erros mais comuns de grupos inexperientes, e ela costuma ocorrer em duas direções opostas. Alguns grupos pivotar quando deveriam persistir — quando o teste revelou um problema de execução e o grupo interpreta isso como invalidação da hipótese. Outros grupos persistem quando deveriam pivotar — quando o teste claramente invalida a hipótese central mas o grupo interpreta os dados de forma a confirmar o que já acreditava. O antídoto para os dois erros é o mesmo: manter as observações separadas das interpretações, como descrito na seção anterior, e formular as decisões de pivot ou perseverar explicitamente em termos de “a evidência mostra que a hipótese X é [confirmada / parcialmente confirmada / invalidada], portanto vamos [manter / ajustar / mudar] a hipótese X”.
Quando o protótipo estava errado, não a hipótese
Existe uma distinção analítica adicional que seu grupo precisa ser capaz de fazer ao interpretar os resultados do teste: a diferença entre “a hipótese está errada” e “o protótipo não representou a hipótese de forma adequada para que ela pudesse ser testada”. Essa distinção é mais sutil do que parece e exige honestidade intelectual por parte de todos os membros do grupo.
Imagine que a hipótese central do projeto é: “profissionais de saúde da atenção primária que recebem um resumo automático dos exames do paciente antes da consulta conseguem conduzir a anamnese de forma mais focada”. O grupo constrói um protótipo em papel representando o resumo de exames. No teste, o médico que participou como usuário hesita longamente, faz várias perguntas sobre os termos usados no resumo e declara que não usaria o resumo na forma apresentada.
Existem pelo menos três interpretações diferentes para esse resultado. A primeira: a hipótese está errada — o médico não quer um resumo, prefere ver os exames na íntegra. A segunda: o protótipo estava errado — o resumo foi construído com terminologia inadequada para o contexto de atenção primária, e um resumo melhor construído seria bem recebido. A terceira: o participante estava errado — o médico recrutado atua num contexto onde os exames nunca chegam antes da consulta, portanto a situação que o protótipo simula não é a situação real de uso.
Para distinguir entre essas interpretações, o grupo precisa de mais informação — pode ser uma pergunta adicional no debriefing, um segundo teste com um participante diferente, ou uma verificação da adequação do protótipo em relação à hipótese. O ponto principal é que um resultado negativo no teste não autoriza automaticamente a conclusão de que a hipótese central é falsa. Ele obriga o grupo a investigar qual elemento do sistema — hipótese, protótipo ou participante — foi o responsável pelo resultado observado.
Conectando ao Módulo 15
O trabalho que você fez neste módulo — construir um protótipo, testar com um usuário real, documentar as observações e sintetizar os aprendizados em ajustes específicos — é o fundamento sobre o qual o Módulo 15 vai operar. O Módulo 15 trata de validação de hipóteses e de Business Model Canvas, e essas duas atividades dependem diretamente do que você aprendeu aqui.
A diferença entre o que este módulo faz e o que o Módulo 15 fará precisa ser compreendida com precisão para que o trabalho de ambos os módulos seja realizado no nível certo. A prototipagem — o foco deste módulo — é um processo de exploração e de teste qualitativo. Ela usa protótipos de baixa ou média fidelidade para gerar aprendizado sobre hipóteses específicas com um número pequeno de usuários. O objetivo não é provar que a solução funciona — é entender como ela funciona, onde ela falha e como deve ser ajustada.
A validação — o foco do Módulo 15 — é um processo de confirmação e de teste em escala maior. Ela usa o aprendizado gerado pela prototipagem para formular hipóteses mais precisas e então testá-las com métodos que permitem maior generalização. No ecossistema de startups, a validação frequentemente envolve experimentos com métricas quantitativas: taxa de adoção, taxa de retenção, frequência de uso, NPS (Net Promoter Score), comparação entre grupos com e sem o produto. Para chegar à validação com rigor, é necessário ter passado pela prototipagem com rigor.
O que o teste de protótipo contribui para o Business Model Canvas
O Business Model Canvas, que seu grupo vai trabalhar no Módulo 15, é uma ferramenta que organiza todos os componentes de um modelo de negócio em nove blocos. Dois desses blocos são diretamente informados pelo trabalho de prototipagem que você realizou neste módulo: o bloco de Proposta de Valor e o bloco de Segmento de Clientes.
O que o teste do protótipo revelou sobre como o usuário real interage com a solução — quais aspectos foram compreendidos intuitivamente, quais precisaram de explicação, quais foram considerados valiosos e quais foram indiferentes ou confusos — atualiza a Proposta de Valor com evidência empírica em vez de apenas com a teoria do Value Proposition Canvas construída no Módulo 13. A Proposta de Valor que entra no Business Model Canvas no Módulo 15 é mais precisa, mais fundamentada e mais confiável do que a que foi construída apenas com base em empatia e ideação, porque foi confrontada com o comportamento real de pelo menos um usuário genuíno.
Da mesma forma, o teste de protótipo frequentemente revela nuances sobre o Segmento de Clientes que a pesquisa de empatia inicial não capturou. O usuário que participou do teste pode ter revelado condicionantes de adoção que não apareceram nas entrevistas — restrições institucionais, preferências de canal, objeções relacionadas a privacidade de dados de saúde, ou a necessidade de envolvimento de outros atores (familiares, gestores de saúde, administradores hospitalares) para que o produto seja adotado. Todas essas informações entram diretamente nos blocos de Segmento de Clientes, Canais e Relacionamento com Clientes do Business Model Canvas.
O trabalho deste módulo, portanto, não é um fim em si mesmo. É o elo que conecta a definição teórica da solução (Módulo 13) à construção do modelo de negócio (Módulo 15). E a qualidade desse elo depende da rigorosidade com que o protótipo foi construído para testar a hipótese central, com que o teste foi conduzido para gerar observações genuínas, e com que o aprendizado foi documentado de forma que possa informar as decisões do próximo módulo.
Diferença fundamental entre prototipagem e validação: prototipagem (este módulo) é teste qualitativo com poucos usuários para entender como a solução funciona e ajustá-la. Validação (Módulo 15) é teste quantitativo com métricas para confirmar que a solução funciona em escala. Você não pode fazer validação sem ter feito prototipagem primeiro — você não saberia o que validar.
O que entregar neste módulo
O trabalho prático deste módulo está organizado em quatro entregas que seu grupo precisa completar durante os 170 minutos de trabalho em grupo que seguem à exposição teórica. As quatro entregas formam uma sequência lógica — cada uma é insumo para a seguinte — e juntas representam o ciclo completo de prototipagem descrito ao longo deste material.
A primeira entrega é a formulação escrita da hipótese central. Seu grupo deve redigir a hipótese central do projeto na estrutura completa apresentada na Seção 2: “Acreditamos que [usuário específico], quando exposto a [funcionalidade ou experiência específica], vai [comportamento ou resultado esperado], porque [razão baseada nos dados de empatia].” Essa formulação deve ser suficientemente específica para que qualquer pessoa possa dizer se um teste a confirmou ou invalidou. Se a hipótese for vaga demais para ser testável — “acreditamos que os usuários gostarão do produto” — ela precisa ser reformulada antes de continuar.
A segunda entrega é o protótipo em si. Com base na árvore de decisão apresentada na Seção 4, seu grupo escolhe o tipo e o nível de fidelidade adequados para a hipótese central e constrói o protótipo. O protótipo deve ser descrito em um documento de uma página que inclui: qual tipo de protótipo foi escolhido, por que esse tipo é adequado para a hipótese formulada, quais elementos do protótipo existem e por quê. Se o protótipo for físico (em papel, cartolina ou outro material), ele deve ser fotografado e incluído no documento. Se for digital, o arquivo deve ser anexado ou o link para o Figma ou Canva deve ser fornecido.
A terceira entrega é o registro do teste. Após construir o protótipo, o grupo conduz pelo menos uma sessão de teste com um usuário real que corresponde ao perfil de usuário definido nos Módulos 9 e 10. O registro do teste deve incluir: a descrição do participante (perfil, não identificação pessoal), a tarefa apresentada ao usuário, as observações brutas organizadas em comportamento verbal e não verbal, e as respostas do debriefing. As observações devem estar separadas das interpretações, conforme o método descrito na Seção 7.
A quarta entrega é a síntese de aprendizados com ajustes propostos. Com base no registro do teste, o grupo produz um documento de síntese que responde às seguintes perguntas: a hipótese central foi confirmada, parcialmente confirmada ou invalidada pelos dados coletados? Quais observações específicas sustentam essa conclusão? Quais ajustes específicos — no protótipo, na hipótese ou na solução — são indicados pelo aprendizado obtido? O grupo vai pivotar ou persistir, e por quê?
Atenção ao tempo: os 170 minutos de trabalho em grupo são suficientes para completar as quatro entregas se o grupo dividir as tarefas e trabalhar em paralelo. Uma divisão eficaz é: dois membros trabalham na construção do protótipo enquanto dois membros preparam o protocolo de teste (folha de observação, tarefa, roteiro do facilitador) e um membro recruta o participante. O teste e o debriefing levam em torno de quarenta minutos. A síntese de aprendizados pode ser feita coletivamente nos trinta minutos finais.
A tabela a seguir organiza as quatro entregas do módulo com seus respectivos critérios de qualidade e o que cada uma contribui para o trabalho do Módulo 15.
| Entrega | Conteúdo mínimo | Critério de qualidade | Contribuição para o Módulo 15 |
|---|---|---|---|
| 1. Hipótese central | Formulação na estrutura completa: usuário + funcionalidade + resultado esperado + razão | Específica o suficiente para ser testável; não é uma afirmação sobre qualidade do produto | Ancora a validação de hipóteses no Módulo 15 |
| 2. Protótipo | Descrição do tipo escolhido + justificativa + descrição dos elementos + arquivo ou foto | O tipo é adequado para a hipótese formulada; inclui os elementos necessários para o teste | Documentação do estado atual da solução antes da validação |
| 3. Registro do teste | Perfil do participante + tarefa + observações brutas (verbal/não verbal separados) + debriefing | Observações separadas de interpretações; participante adequado ao perfil de usuário | Evidência empírica para a Proposta de Valor no Business Model Canvas |
| 4. Síntese de aprendizados | Resultado do teste (confirma/parcial/invalida) + observações de sustentação + ajustes específicos + decisão de pivot ou persistir | Conclusões ancoradas em observações específicas, não em impressões gerais | Atualiza a Proposta de Valor e o Segmento de Clientes para o Business Model Canvas |
Conexão com o que vem a seguir: as quatro entregas deste módulo são o insumo direto para o Módulo 15. Leve para a próxima aula a hipótese central testada, o registro do teste com as observações documentadas e a síntese de aprendizados com os ajustes propostos. Esses documentos informarão tanto o processo de validação de hipóteses quanto o preenchimento do Business Model Canvas, que é o produto final do Módulo 15.
Para consolidar o percurso completo que este módulo percorreu, o diagrama a seguir representa a trajetória do projeto do Módulo 13 ao Módulo 15, posicionando a prototipagem no centro do processo de desenvolvimento e mostrando como cada etapa alimenta a próxima.
flowchart LR
subgraph M13["MÓDULO 13 — Solução e Proposta de Valor"]
direction TB
VPC([Value Proposition Canvas])
SOL([Definição de solução<br/>com escopo e limites])
HIP([Hipótese central<br/>implícita])
VPC --> SOL --> HIP
end
subgraph M14["MÓDULO 14 — Prototipação (este módulo)"]
direction TB
HE([Hipótese central<br/>explícita e testável])
PT([Protótipo construído<br/>para a hipótese])
TE([Teste com<br/>usuário real])
AP([Aprendizado documentado<br/>observações + interpretações])
AJ([Ajustes específicos<br/>pivot ou persistir])
HE --> PT --> TE --> AP --> AJ
end
subgraph M15["MÓDULO 15 — Validação e Modelo de Negócio"]
direction TB
VAL([Validação de<br/>hipóteses em escala])
BMC([Business Model Canvas<br/>proposta de valor atualizada])
VAL <--> BMC
end
M13 --> M14
M14 --> M15
style M13 fill:#e8f4f8,color:#333,stroke:#2c7bb6
style M14 fill:#f5f0e8,color:#333,stroke:#c8a96e
style M15 fill:#e8f8e8,color:#333,stroke:#4dac26
style VPC fill:#2c7bb6,color:#fff,stroke:#1a5a8a
style SOL fill:#2c7bb6,color:#fff,stroke:#1a5a8a
style HIP fill:#74add1,color:#fff,stroke:#4a8ab0
style HE fill:#f07d02,color:#fff,stroke:#b85c00
style PT fill:#7b3294,color:#fff,stroke:#561f6a
style TE fill:#d7191c,color:#fff,stroke:#a01010
style AP fill:#74add1,color:#fff,stroke:#4a8ab0
style AJ fill:#4dac26,color:#fff,stroke:#2d7a14
style VAL fill:#4dac26,color:#fff,stroke:#2d7a14
style BMC fill:#1a9641,color:#fff,stroke:#0d5c27
Você chegou ao final deste material com um repertório completo para construir e testar protótipos de forma estruturada. O que este módulo pediu de você não foi habilidade técnica em ferramentas digitais nem experiência prévia em desenvolvimento de produto. Pediu uma mudança de postura: a disposição de produzir algo propositalmente incompleto para aprender o que a perfeição prematura nunca revelaria. Essa postura — a do profissional que constrói para aprender antes de construir para entregar — é uma das mais transferíveis que você pode desenvolver ao longo da sua formação, e ela vai aparecer de formas diferentes ao longo de toda a sua carreira, dentro e fora da medicina.