As referências que utilizamos para construir essa seção sobre POC, MVP e protótipos são variadas e propõem diversas classificações. 

Uma grande divisão é quando tratamos do desenvolvimento de software (foco da maior parte das publicações mais recentes) ou do desenvolvimento de artefatos físicos (hardware, bens de consumo, de capital etc.).

Na flexM4I, partimos dessas contribuições para propor uma tipologia unificada, que busca organizar POC, MVP e protótipos (em suas múltiplas variações) em uma única estrutura, relacionando cada um deles ao risco que ajudam a reduzir — seja de desejabilidade (as pessoas querem?), de viabilidade técnica e operacional (é possível entregar?) ou de sustentação econômica (é financeiramente viável?).

A figura abaixo mostra as seções da flexM4i relacionadas com protótipos, que remete para as seções relacionadas com a conexão empresa-startups.

Figura 1402: Seções da flexM4i relacionadas com protótipos (clique na figura para abrir um PDF em outra aba com os links para essas seções)

Até aqui, a discussão sobre POC, MVP e protótipo funcional foi estruturada a partir de relações B2B e B2C (veja a figura 430 do início desta seção). No entanto, quando startups interagem com o setor público (B2G — Business to Government), a lógica se altera, pois a administração pública deve seguir regras jurídicas e regulatórias específicas.

O Marco Legal das Startups e do Empreendedorismo Inovador (Lei Complementar nº 182/2021) introduziu instrumentos próprios para viabilizar o teste e a contratação de soluções inovadoras pelo poder público. Dois desses instrumentos são formais: 

• o sandbox regulatório e 
• o Contrato Público para Solução Inovadora (CPSI). 

Na prática, muitas prefeituras e órgãos públicos também utilizam um terceiro estágio não normatizado, a POC não remunerada, como forma preliminar de interação com startups. Nesse caso, é a startup que deve bancar a POC, o que muitas vezes é um grande risco para ela.

Assim, em ambientes B2G, observa-se frequentemente uma escada de três degraus:

• POC (não remunerada): testes exploratórios conduzidos sem pagamento, nos quais a startup assume o custo inicial de demonstrar viabilidade;
• Sandbox regulatório: ambiente controlado em que normas são flexibilizadas para permitir experimentação supervisionada;
• CPSI (Contrato Público para Solução Inovadora): instrumento contratual que permite ao poder público remunerar o desenvolvimento e teste de soluções inovadoras, mesmo com risco tecnológico.

Serve para confirmar a viabilidade do conceitos e a robustez técnica: 

Tanto no contexto B2C como no B2B, o caminho mais frequente dessa trilha é se iniciar em uma POC (elo forte) e depois explorar os protótipos funcionais. No entanto, é possível que o criador da solução comece com um protótipo de baixa fidelidade antes de desenvolver a POC

Como já mencionado acima, os protótipos de baixa fidelidade podem explorar ideias iniciais e ajudar na avaliar a lógica de conceitos embrionários.

Tanto após a validação dos protótipos de baixa fidelidade, como após a aprovação de uma POC, pode ocorrer que o desenvolvedor crie um MVP para validar a tecnologia com mais clientes. No entanto, essas duas últimas opções são menos frequentes na trilha tecnológica. Por esse motivo, a ligação desses dois últimos artefatos com a trilha é fraca.

No contexto da relação empresa-startup, o desenvolvimento da tecnologia / solução para a empresa estabelecida, se inicia com uma POC.

Essa trilha é voltada para  testar atratividade e valor percebido. Conforme indicado na figura 430, exploramos essas trilhas para a relação B2C e B2B.

No contexto B2C

Nessa trilha é comum se iniciar com um MVP, logo após a ideia de uma nova solução, principalmente no contexto B2C. É a primeira atividade do ciclo do Lean Startup: construir (o MVP) – medir (testar) – aprender.

Quando não partimos diretamente de uma ideia, iniciamos com o entendimento do espaço problema, antes de gerar várias ideias (fase divergente), selecionar algumas, prototipar e testar.

Neste contexto, utilizamos protótipos de baixa fidelidade que exploram ideias iniciais e ajudam a avaliar atratividade, lógica de fluxo e compreensão de conceitos embrionários. 

Como já mencionado acima, os protótipos de baixa fidelidade também podem ser utilizados nesta trilha para explorar ideias iniciais.Eles podem fornecer pistas preliminares sobre valor percebido quando apresentados a clientes, mas não em condições de uso real — o que caracteriza a chamada zona cinzenta entre protótipo de baixa fidelidade e MVP (veja o tópico “Superposição entre protótipo de baixa fidelidade e MVP” ).

Um protótipo de baixa fidelidade pode evoluir em diferentes direções: 

• para uma prova de conceito (POC), quando o objetivo é verificar a viabilidade técnica de um princípio ou tecnologia; ou 
• para um produto mínimo viável (MVP), quando o foco está em validar hipóteses de valor e de mercado, com o mínimo de funcionalidades necessárias.

A partir daí, a evolução pode seguir até um protótipo funcional (em estágios mais avançados do desenvolvimento).

Função do protótipo funcional

O protótipo funcional busca demonstrar desempenho técnico, confiabilidade, usabilidade e aceitação em fases mais próximas da certificação ou da entrada em operação.

• digitais, realizados em ambiente virtual. São úteis para simular e validar lógica, usabilidade e desempenho sem a necessidade imediata de construir o artefato físico.
• físicos, construídos no mundo real.

Tanto digitais como físicos podem assumir caráter focado — quando testam partes ou aspectos específicos — ou abrangente, quando cobrem o funcionamento integrado da solução.

No contexto B2B

No relacionamento B2B dentro de trilha de mercado (atente que não estamos discutindo a trilha tecnológica, apresentada anteriormente), o criador da solução, antes de aplicar uma POC em um cliente, pode ter iniciado o desenvolvimento com um protótipo de baixa fidelidade e até funcional. Isso ocorre principalmente em  startups  mais maduras. 

Mas após ter certeza da viabilidade tecnológica da solução, o contato da startup com a empresa cliente ocorre normalmente por meio de uma POC.

Em startups nas fases iniciais, essa POC pode ser construída em cooperação com o cliente (empresa estabelecida) usando inicialmente um protótipo de baixa fidelidade.

Na trilha de mercado / usuário e uma vez aprovada a POC na relação B2B, a trilha pode evoluir diretamente para um protótipo funcional, como discutido no contexto anterior.

Evolução para o projeto piloto

Quando o protótipo funcional atinge maturidade suficiente, ele pode abrir caminho para a fase seguinte — o projeto piloto —, conforme ilustrado na figura a seguir.

Figura 1401: evolução de uma POC, para um projeto piloto para um protótipo até o roll out que culmina com a solução em produção
Fonte: adaptado de Maksimavicius (2017) 

Não podemos esquecer que um protótipo funcional (digital ou físico) ainda não é o produto final (obvio). Se o projeto piloto (que não é um artefato e sim uma fase) for aprovado,  passamos para o roll out, jargão que indica que a solução será implementada em operação.

Apesar de tratarmos cada trilha de forma separada, é importante lembrar que, na prática, elas podem se cruzar e se retroalimentar.

O entrelaçamento das duas trilhas permite que uma prova de conceito reforce a confiança para construir um MVP, ou que um MVP retroalimente a busca por um protótipo funcional.

Prototipar é uma prática essencial para reduzir incertezas ao longo do desenvolvimento de inovações. Mais do que uma etapa técnica, trata-se de uma abordagem estratégica que combina aprendizado rápido, validação incremental e eficiência no uso de recursos.

Valor de prototipar
Segundo Warfel (2009), os protótipos cumprem um papel generativo, ajudando equipes a materializar ideias que, de outra forma, permaneceriam abstratas. Além disso, funcionam como mecanismos de aceleração, permitindo visualizar, discutir e iterar soluções em um ritmo mais rápido do que se ficassem restritas a planos ou descrições. Finalmente, contribuem para a economia de tempo e custo, pois permitem descartar alternativas inviáveis antes de comprometer recursos significativos em desenvolvimento.

Protótipo como meio de validação incremental
Para Bland e Osterwalder (2019), o protótipo é apenas uma entre várias formas de experimentação, mas cumpre um papel central na validação incremental de hipóteses. Ele ajuda a reduzir riscos de três naturezas principais:

• Desejabilidade: as pessoas querem essa solução?
• Viabilidade: é tecnicamente e operacionalmente possível entregar?
• Sustentabilidade financeira: o modelo de negócio é financeiramente viável?

Nesse sentido, cada protótipo é visto como um experimento que gera evidências, permitindo decisões mais embasadas sobre seguir em frente, adaptar ou abandonar uma iniciativa.

Diferença entre prototipar e lançar produto pronto
É importante diferenciar a lógica de prototipar da de lançar um produto final. O protótipo tem como objetivo aprender — ele pode estar incompleto, ser imperfeito ou mesmo conter funcionalidades simuladas, desde que produza evidências úteis para reduzir incertezas. 

Já o lançamento de um produto pronto envolve a entrega de uma solução robusta, confiável e escalável ao mercado. Confundir os dois momentos pode gerar riscos elevados, seja por investir cedo demais em algo ainda não validado, seja por interpretar um protótipo como um produto final.

Ulrich et al. (2019) definem um protótipo como “uma aproximação de um produto que apresenta uma ou mais características de interesse”. Eles classificam os protótipos em duas dimensões: físico / analitico e focado / abrangente (próxima figura):

• Protótipos físicos: modelos tangíveis, usados para testar forma, ergonomia, impacto ou funcionalidades específicas (ex.: mock-ups, modelos em escala, bancadas de laboratório).
  Protótipos analíticos: representações não físicas, como modelos matemáticos, simulações computacionais, CAD/CAE, CFD/FEM ou mesmo gêmeos digitais.
  Protótipos focados: implementam apenas alguns atributos ou subsistemas, úteis para explorar riscos técnicos específicos (ex.: mock-up de forma, subsistema hidráulico, lote-piloto de alimentos).
  Protótipos abrangentes: implementam a maior parte das funcionalidades, próximos ao produto final (ex.: versão operacional em escala real, protótipo de certificação, protótipo de qualificação).

Na figura abaixo, representamos  alguns exemplos de protótipos usando a caracterização de Ulrich et al. (2019).

Figura 418: tipologia de protótipos
Fonte: adaptado de Ulrich et al. (2019)

 Na figura original, os autores colocaram a região que inclui protótipos abrangentes e analíticos como normalmente não factíveis. Entretanto, com os avanços recentes em gêmeos digitais, tornou-se possível construir réplicas virtuais completas de produtos ou sistemas, alimentadas por dados em tempo real. Por isso, acrescentamos essa categoria à nossa adaptação.” 

Observe que a maior parte desses protótipos é utilizada quando já se possui o conceito do produto. Esses protótipos são construídos normalmente na fase de detalhamento. No entanto, os autores já previram usar protótipos como prova de conceito (POC) para provar ideias, ou seja, após a existência de um conceito embrionário para se testar alternativas.

Além dessa classificação apresentada por Ulrich et al. (2019), é importante destacar que, no campo do design e da inovação, fala-se também em protótipos de baixa fidelidade. Eles podem assumir a forma de representações analíticas (como esboços, storyboards, mock-ups digitais) ou até versões físicas simples, sejam focadas ou abrangentes, mas sempre com o objetivo de antecipar percepções sem a construção de um artefato robusto. Embora não apareçam de forma explícita na tipologia de Ulrich, são amplamente utilizados em práticas como Design Thinking e metodologias ágeis.

Outro ponto de articulação é que, na prática, os protótipos abrangentes e físicos são frequentemente chamados de protótipos funcionais, pois reúnem um conjunto integrado de funcionalidades e se aproximam do uso real do produto. Essa é a base para a diferenciação que será discutida posteriormente entre protótipos e MVPs.

Protótipos funcionais

Além dessa classificação por natureza, podemos identificar protótipos funcionais, que são aqueles capazes de reproduzir fluxos de uso completos. Eles podem ocorrer no domínio virtual (como um subconjunto dos protótipos analíticos) ou no domínio físico (como um subconjunto dos protótipos físicos abrangentes). Por essa razão, vamos dividir os protótipos funcionais em dois grupos:

• Protótipo funcional-virtual (PFv): analítico/simulável, executa as funções fim-a-fim em ambiente digital.
• Protótipo funcional-físico (PFm): físico, executa as funções no mundo real (energia/matéria/informação).

Por fim, vale mencionar que Ulrich et al. (2019) também propõem uma categorização mais detalhada dos protótipos funcionais físicos, distinguindo entre protótipos alfa, beta e de pré-produção (veja o tópico “Protótipos funcionais físicos abrangentes” da seção sobre protótipos funcionais).

Warfel (2009) propôs uma tipologia que organiza os protótipos de acordo com o grau de fidelidade, ou seja, o quanto eles se aproximam do produto ou sistema final.

Baixa fidelidade
Protótipos simples, rápidos e baratos. Normalmente feitos em papel, wireframes ou mockups estáticos.
Objetivo: testar conceitos iniciais, fluxos e interações de forma exploratória.

Fidelidade média
Protótipos que já simulam a aparência e, em parte, o funcionamento.
Podem incluir interações limitadas, simulações digitais ou maquetes mais elaboradas.
Objetivo: validar usabilidade, arquitetura de informação e caminhos de navegação.

Alta fidelidade
Protótipos quase indistinguíveis do produto real, tanto na estética quanto na funcionalidade.
Incluem cliques reais, dados simulados e até comportamento dinâmico.
Objetivo: testar a experiência do usuário em condições próximas às finais, servindo também para validação técnica.

Essa escala não significa que sempre é preciso passar por todas as etapas. A escolha depende dos objetivos do projeto, do estágio de desenvolvimento e dos recursos disponíveis.

Na tipologia proposta por Synytsia (2022), os protótipos são organizados segundo seu estágio de desenvolvimento e nível de complexidade, como ilustra a figura abaixo.

Figura 1397: tipologia de protótipos segundo Synytsia (2022)
Fonte: Adaptado de Synytsia (2022)

As formas iniciais incluem fluxogramas (flowcharts), esboços de interface (wireframes) e mockups (mockups), que estruturam fluxos e interfaces, mas não são considerados funcionais.

O termo protótipo funcional (functional prototype) é reservado a três tipos que já permitem testes mais próximos do produto real:

• Protótipos de viabilidade (feasibility prototypes)
  São versões simplificadas que verificam se a tecnologia ou abordagem escolhida pode realmente ser implementada. Normalmente incluem um código mínimo e uma interface simples para demonstrar a lógica de funcionamento. Seu valor está em reduzir incertezas técnicas, principalmente em projetos que usam novas tecnologias ou quando a equipe não tem experiência anterior. Muitas vezes, após cumprirem seu papel, esses protótipos são descartados e reescritos em versões mais robustas.
• Protótipos de alta fidelidade (high-fidelity user prototypes)
  Representam de forma detalhada a experiência planejada para o usuário. Criados em plataformas como InVision ou Adobe XD, simulam a navegação e permitem interações próximas do real, mesmo sem ter um back-end desenvolvido. São usados para testes de usabilidade, avaliando arquitetura da informação, clareza de comandos, tempo de execução de tarefas e reações a elementos visuais (cores, animações, mensagens). Também cumprem um papel estratégico ao apresentar a visão do produto para clientes, investidores e equipes internas.
• Protótipos com dados reais (live-data prototypes)
  São os mais avançados, pois integram dados vindos de fontes reais (via APIs, por exemplo). Isso permite observar a interação dos usuários em cenários próximos da operação prática, revelando problemas e oportunidades que dificilmente apareceriam em protótipos com dados fictícios. Costumam ser desenvolvidos sobre produtos já existentes, em ambientes controlados, e fornecem métricas mais confiáveis para orientar decisões de design e confirmar se a solução atende às necessidades reais do mercado.

Essa tipologia destaca a importância de distinguir representações preliminares dos protótipos funcionais propriamente ditos, que cumprem papel central na redução de riscos e na validação antes do lançamento.

Bland & Osterwalder (2019) propõem uma tipologia baseada não em tipos de protótipos, mas em tipos de experimentos para testar ideias de negócios (o título do livro) com o objetivo  de reduzir incertezas no desenvolvimento de novos modelos de negócio.

A lógica é de que cada hipótese do Business Model Canvas ou do Value Proposition Canvas pode ser testada por meio de experimentos que fornecem evidências — inicialmente mais frágeis e baratas, depois mais robustas e próximas da realidade de mercado.

Essa tipologia organiza os experimentos em duas fases principais:

• Discovery Experiments: têm caráter exploratório e buscam levantar informações sobre clientes, contextos de uso e prioridades, antes da construção de soluções mais concretas.
  Exemplos de experimentos: entrevistas e análises de dados até protótipos conceituais usados em discussões com clientes.
• Validation Experiments: têm caráter confirmatório, colocando os clientes diante de interações, simulações ou chamadas à ação que permitem validar hipóteses em condições próximas ao mercado real.
  Exemplos de experimentos: protótipos interativos, landing pages, testes de pré-venda e simulações em ambiente real. Os experimentos que envolvem protótipos — como paper prototype, 3D print, clickable prototype ou Wizard of Oz — são destacados por seu papel em criar experiências tangíveis que apoiam a coleta de evidências.

Nem todos os experimentos envolvem protótipos, mas muitos deles fazem uso desses artefatos como meios de interação, seja em versões conceituais (para discussão) ou funcionais (para validação).

Além dessa categorização geral, os autores organizam os experimentos em sequências específicas por tipo de estratégia ou setor. Assim, apresentam percursos de experimentação para:

• hardware B2B, 
• software B2B, 
• serviços B2B, 
• negócios B2C, 
• modelos B2B2C e 
• setores altamente regulados.

Cada sequência combina experimentos em uma ordem lógica, de modo a gerar evidências progressivas de viabilidade técnica, valor para o cliente e atratividade de mercado.

Além de estruturarem os experimentos por fase (discovery e validation) e por sequências estratégicas, Bland & Osterwalder (2019) introduzem outras três formas de classificação que ajudam gestores e equipes a comparar, selecionar e direcionar os experimentos mais adequados conforme apresentamos a seguir.

1. Critérios de avaliação dos experimentos
   Cada experimento é avaliado em quatro dimensões: custo, tempo de preparação (setup time), tempo de execução (run time) e força da evidência. Esses critérios permitem comparar alternativas e decidir entre opções rápidas e baratas, porém menos robustas, ou mais demoradas e caras, mas com evidências mais fortes.
2. Competências necessárias
   Testar ideias de negócio requer um conjunto diversificado de competências, incluindo design, produto, tecnologia, jurídico, dados, vendas, marketing, pesquisa e finanças. Poucas equipes dominam todas essas habilidades internamente, de modo que muitas vezes é preciso complementar com parceiros, consultores ou colaboradores externos.

Camadas relacionadas ao time
Para que os experimentos sejam eficazes, não basta reunir as competências técnicas. É necessário cuidar de três camadas:

• Design do time (team design): a composição da equipe, garantindo papéis e complementaridade e que os membros do time que vai realizar um determinado experimento possua as competências necessárias (item anterior).
• Comportamento do time (team behavior): a forma como a equipe atua, interage e adota características empreendedoras. Essa característica é muito importante, pois não adianta possuir somente a competência necessária.
• Ambiente do time (team environment): o contexto em que a equipe opera, que deve ser favorável à experimentação, tolerando falhas como parte do processo de aprendizado. Esta camada está relacionada com o clima de trabalho e liderança.

Nas tipologias anteriores, a ênfase esteve em protótipos aplicados a produtos e serviços, testando funcionalidades, experiências e processos de entrega. Já na tipologia de Bland & Osterwalder (2019), o foco desloca-se para a validação de hipóteses de negócio, conectadas à proposição de valor e ao modelo de negócio como um todo.

Assim, protótipos deixam de ser apenas representações de produtos ou serviços e passam a ser entendidos como instrumentos de experimentação estratégica. Eles ajudam a verificar se a inovação proposta é:

• Desejável (desirable): se atende a necessidades e desejos de clientes;
• Viável (viable): se gera resultados econômicos sustentáveis;
• Realizável (feasible): se pode ser entregue com os recursos e capacidades disponíveis.

Essa mudança de ênfase dialoga diretamente com os conceitos estruturados na flexM4i:

• a inovação deve ser sempre analisada no contexto da visão sistêmica da empresa e do seu ecossistema;;
• toda inovação em produto ou serviço implica inovações associadas em outros elementos do negócio;
• os requisitos dos stakeholders precisam ser observados de forma diferenciada: o desejável do ponto de vista do cliente, o viável do ponto de vista dos sócios e o realizável do ponto de vista de quem cria e entrega o valor.

Dessa forma, a comparação não gera ruptura, mas mostra a complementaridade entre tipologias. É justamente a partir dessa integração que a flexM4i propõe sua própria tipologia, apresentada mais adiante.

Os próximos dois tópicos listam os experimentos de discovery e de validation.

Este tópico lista os experimentos de discovery (descoberta) da tipologia de Bland & Osterwalder (2019). Os experimentos estão divididos em categorias do discovery. O experimentos marcado com (*) correspondem a tipos de protótipos.

Recomendamos que você acesse a publicação original para poder conhecer esses tipos de experimentos e sua classificação segundo os critérios apresentados anteriormente.

Exploration:

• Entrevistas com clientes (Customer Interview)
• Entrevistas com stakeholders (Expert Stakeholder Interviews)
• Entrevistas com parceiros e fornecedores (Partner & Supplier Interviews)
• Um dia na vida (A Day in the Life)
• Pesquisas de descoberta (Discovery Survey)

Data Analysis:

• Análise de tendências de busca (Search Trend Analysis)
• Análise de tráfego da web (Web Traffic Analysis)
• Fóruns de discussão (Discussion Forums)
• Feedback da força de vendas (Sales Force Feedback)
• Análise de suporte ao cliente (Customer Support Analysis)

Interest Discovery:

• Anúncio online (Online Ad)
• Rastreamento de links (Link Tracking)
• Teste 404 (404 Test)
• Funcionalidade simulada (Feature Stub)
• Campanha de e-mail (Email Campaign)
• Campanha em mídias sociais (Social Media Campaign)
• Programa de indicação (Referral Program)

Discussion Prototypes:

• Impressão 3D (3D Print) (*)
• Protótipo em papel (Paper Prototype) (*)
• Storyboard (*)
• Folha de dados (Data Sheet) (*)
• Brochura (Brochure) (*)
• Vídeo explicativo (Explainer Video) (*)
• Boomerang (retorno de clientes potenciais)
• Finja que possui (Pretend to Own)

Preference & Prioritization Discovery:

• Caixa de produto (Product Box)
• Barco rápido (Speed Boat)
• Ordenação de cartões (Card Sorting)
• Comprar uma funcionalidade (Buy a Feature)

Este tópico lista os experimentos de validation (validação) da tipologia de Bland & Osterwalder (2019). Os experimentos estão divididos em categorias do validation. O experimentos marcado com (*) correspondem a tipos de protótipos.

Recomendamos que você acesse a publicação original para poder conhecer esses tipos de experimentos e sua classificação segundo os critérios apresentados anteriormente.

Interaction Prototypes:

• Protótipo clicável (Clickable Prototype) (*)
• MVP de funcionalidade única (Single Feature MVP) (*)
• Combinação de funcionalidades (Mash-up) (*)
• Concierge (*)
• Protótipo em escala real (Life-sized Prototype) (*)

Call to Action:

• Landing page simples (Simple Landing Page) (*)
• Financiamento coletivo (Crowdfunding)
• Teste A/B (Split Test)
• Pré-venda (Presale)
• Pesquisa de validação (Validation Survey)

Simulation:

• Assistente humano disfarçado de sistema (Wizard of Oz) (*)
• Venda simulada (Mock Sale) (*)
• Carta de intenção (Letter of Intent)
• Loja temporária (Pop-up Store) (*)
• Programação extrema (Extreme Programming Spike)

Além dos atributos que caracterizam cada protótipo, é importante considerar quem participa do processo de validação. Os usuários de validação indicam em que nível de exposição o protótipo é colocado à prova:

• U0 – Sem usuários: experimentação em laboratório, simulações e testes internos sem contato direto com usuários.
• U1 – Usuários internos ou stakeholders: colaboradores da própria organização ou de um cliente corporativo (por exemplo, equipe de engenharia, operações ou TI) e alguns clientes gerais.
• U2 – Clientes-piloto selecionados: usuários externos escolhidos para avaliar a solução em um ambiente controlado ou com condições específicas.
• U3 – Mercado aberto: clientes reais em ambiente de uso efetivo, sem seleção prévia, representando a validação em escala.

Cada tipo de protótipo pode envolver usuários de validação diferentes, conforme seu objetivo.

Um mockup é uma representação visual estática de um produto, usada para comunicar forma, layout e aparência, mas sem funcionalidade real — sua utilidade é avaliar estética, proporções e percepção inicial, não validar desempenho ou uso.

Ele está mais próximo de um protótipo de baixa fidelidade (quando feito em papel, espuma, impressões 2D) ou, em alguns casos, de um protótipo de média fidelidade (quando inclui detalhes visuais mais acabados).

Em software, o mockup (ou wireframe estático) é uma antecipação visual da interface, usado para feedback de layout e design, antes de se tornar clicável (aí sim entraria no grupo de protótipos funcionais digitais).

A descrição do apoio está relacionada com todas as seções sobre protótipos.

A primeira versão desta seção foi escrita sem apoio do chatGPT. A versão atual foi completada com o apoio do chatGPT 4.o, que foi utilizado para organizar os conteúdos encontrados em publicações citadas. Nenhum conteúdo foi criado exclusivamente pelo chatGPT. Sempre foram fornecidos trechos de fontes de referência com instruções de como deveriam ser combinadas e organizadas. Mais de 40 iterações foram necessárias para se obter a versão que foi editada pelo autor desta seção.

Conforme novas referências foram sendo conhecidas, novas versões foram realizadas sem apoio do chatGPT. Partes desta seção foram corrigidas, modificadas e novos tópicos foram inseridos, pelo autor. 

Após 10 meses da primeira versão, a revisão desta seção foi realizada adicionando novas referências, além da revisão da Isabela Simões na seção sobre Prova de Conceito (POC). Nessa fase foi utilizada a versão 5.0 do chatGPT.

Além disso, foi incorporado nesta seção um resumo de um vídeo do YouTube (tópico “Por que 90% dos MVPs falham”). Este vídeo foi resumido pelo Google NotebookLM.

A criação desta seção teve a duração de mais de 80 horas, com 230 interações “ser humano – agente de IA” (ChatGPT)”, realizadas ao longo de duas semanas. A conversa resultou em mais de 440 páginas de interação e cerca de 119 mil palavras geradas. A extensão do conteúdo deveu-se, em grande parte, à necessidade de construir, revisar e ajustar cada trecho da versão anterior da seção.

O foco delimitar os conceitos, que muitas vezes eram antagônicos em diferentes publicações procurando equilibrar profundidade teórica e adequação prática.

Após algumas interações, foram definidos novos tópicos do sumário da seção, a partir do sumário anterior. Iniciou-se então uma revisão conjunta “ser humano – agente de IA” de cada tópico.

Em nenhum momento o autor solicitou que o ChatGPT gerasse respostas com base em seus conhecimentos gerais. Todo o conteúdo foi elaborado a partir de materiais fornecidos, trechos comentados ou instruções precisas baseadas em análises do autor. Os textos produzidos passaram por diversas iterações, com o autor sugerindo ajustes, criticando formulações e, ao final, realizando pessoalmente a edição final de todos os blocos de conteúdo.

O autor conferiu sempre se os textos gerados pelo ChatGPT estavam alinhados com as fontes originais. Quando surgiam inconsistências ou dúvidas, ele fazia a checagem diretamente nas publicações de referência antes de aprovar qualquer trecho.

Nesses momentos, para garantir que o chatGPT estava utilizando as fontes fornecidas, já que ele possui limitações para indicar de onde ele tirou cada trecho de texto avaliado, utilizamos em conjunto o NotebookLM da Google para conferir os trechos das fontes utilizadas.

Esse processo exigiu iterações intensas e repetitivas, com refinamento textual, ajustes conceituais e reorganização de argumentos. Em vários momentos, versões intermediárias foram reanalisadas no próprio ChatGPT, que indicava melhorias, tensionamentos ou oportunidades de aprofundamento. O autor avaliava criticamente essas sugestões, nem sempre concordando, e frequentemente propunha soluções alternativas, mantendo sempre o controle final da redação.

Foi solicitado ao ChatGPT que não aceitasse automaticamente as propostas do autor, mas que realizasse uma análise crítica, sugerisse alternativas e propusesse reformulações embasadas nos conteúdos utilizados. Nesses momentos, o próprio chatGPT selecionava um modelo que demorava mais para responder. Quando aplicável, o autor indicava práticas baseadas em sua própria experiência, e o ChatGPT as incorporava, respeitando a distinção entre conteúdo empírico e referenciado. Nesses casos, o autor “ditava” para o chatGPT formular as frases, que posteriormente foram melhoradas pelo autor..

Durante todo o processo, foi enfatizado que o ChatGPT não deveria reescrever blocos inteiros automaticamente, mas sim identificar pontos de melhoria e sugerir correções localizadas, com justificativas. A edição final foi sempre realizada manualmente pelo autor desta seção.

Essas referências estão relacionadas com todas as seções sobre protótipos.

Altersoft (2022) Functional Prototype: How to Iterate with Your Software Product. Disponível em: https://www.altexsoft.com/blog/functional-prototype/  Recuperado em: 26 setembro 2024.

Bland, D. J., & Osterwalder, A. (2019). Testing business ideas: A field guide for rapid experimentation. Hoboken: John Wiley & Sons.  

Blank, S., & Dorf, B. (2012). The startup owner's manual: The step-by-step guide for building a great company. John Wiley & Sons.

Dam, R. F. & Teo, Y. S. (2024, February 21). 5 Common Low-Fidelity Prototypes and Their Best Practices. Interaction Design Foundation - IxDF. https://www.interaction-design.org/literature/article/prototyping-learn-eight-common-methods-and-best-practices 

Ries, E. (2011). The lean startup. New York: Crown Business. 

Robot Mascot (2018). 18 types of minimum viable product (MVP) that won’t break the bank. Disponível em: https://www.robotmascot.co.uk/blog/18-types-of-minimum-viable-product/  Recuperado em: 26 setembro 2024.

Sparkmate (2023) Functional Prototyping: How the Iteration Process Goes. How to build a functional prototype and the road to building a MVP. Disponível em: https://www.sparkmate.com/blog/functional-prototyping  Recuperado em: 26 setembro 2024.

Ulrich, Karl T.; Eppinger, Steven D.; Yang, Maria (2019) Product Design and Development. 7th. ed. New York: McGraw Hill.

Uxpin, T. (2024). Examples of Prototypes – From Low-Fidelity to High-Fidelity Prototypes. https://www.uxpin.com/studio/blog/prototype-examples/