Saltar para o conteúdo
Guia7 min de leitura

Vídeo de Apresentação Guiada de Revisão de uma Aplicação Bubble

Mostrar ao revisor o único fluxo que prova que a construção corresponde ao briefing.

Dar ao revisor de um projeto Bubble um fluxo gravado que prova que a construção corresponde ao briefing, em vez de uma atualização de estado escrita.

Ver como funcionaOs primeiros 60 segundos de vídeo são gratuitos, com marca de água. Verifique o seu correio eletrónico para o descarregar.

Uma apresentação guiada de revisão de uma aplicação Bubble existe para responder a uma pergunta que um cliente ou responsável de projeto continua a fazer sem a dizer em voz alta: será que a coisa que pedi foi mesmo construída. As atualizações de estado escritas são más a responder a isto. Descrevem intenção, não resultado, e um revisor que lê "o fluxo de trabalho de faturas está concluído" não tem forma de saber se isso significa que funciona corretamente ou que alguém escreveu a frase com esperança. Um fluxo gravado do fluxo de trabalho real em funcionamento remove essa ambiguidade, porque ou o clique no botão produz o resultado prometido no ecrã, ou não produz.

O GogoScreen constrói isto a partir do URL de uma aplicação web e de uma indicação de uma linha a descrever o fluxo a gravar. Devolve um MP4 narrado, normalmente com cerca de dois minutos, com edição que corta tempos mortos, suaviza o cursor, aplica zoom sobre os cliques, e incorpora legendas. Para um fluxo de trabalho que só aparece depois de alguém iniciar sessão, pode ser fornecida uma conta de demonstração, que é cifrada, utilizada para uma única renderização, e depois eliminada. Se for planeado primeiro um storyboard, as credenciais ficam cifradas durante essa sessão e são eliminadas, no máximo, duas horas após a última utilização. Nada disto substitui a leitura do código ou da lógica do fluxo de trabalho no editor Bubble. Substitui pedir a um revisor não técnico que faça isso em vez disso.

O que exatamente deve a apresentação guiada provar?

Comece pelo briefing, não pela aplicação. Releia o pedido específico que o cliente ou gestor fez, quer tenha sido "os utilizadores conseguem submeter uma candidatura e ver o estado mudar" ou "um administrador consegue aprovar uma listagem e esta aparece publicamente". A apresentação guiada deve mostrar precisamente esse caminho, acionado da forma como um utilizador real o acionaria, terminando no resultado descrito no briefing. Uma apresentação guiada que se desvia para funcionalidades adjacentes que o revisor nunca pediu desperdiça a sua atenção e pode convidar novo âmbito para uma revisão que devia fechar âmbito antigo.

Os fluxos de trabalho do Bubble são lógica visível no editor, uma sequência de passos associada a um evento, mas um revisor não técnico não consegue ler essa sequência e não vai tentar. O que consegue avaliar é se clicar no botão produziu a mudança que lhe disseram que devia esperar. Mantenha a apresentação guiada ancorada a esse único resultado observável.

  1. Confirme exatamente o que o briefing pedia e escolha o único fluxo de trabalho que o prova.
  2. Coloque a aplicação no estado imediatamente anterior ao gatilho, para que a gravação comece no momento relevante.
  3. Grave a apresentação guiada e envie-a ao revisor junto com uma nota curta sobre o que ainda está em aberto.

Como se prepara a aplicação antes de gravar?

Abra a aplicação, seja a versão em produção ou a versão de teste, consoante a fase que a revisão cobre, e coloque-a no estado que precede diretamente o gatilho. Se o fluxo de trabalho depender de dados já existentes, um registo já criado, um utilizador já inscrito, prepare isso com antecedência, em vez de gravar também os passos de configuração. Um revisor não precisa de ver uma conta a ser criada antes de ver a funcionalidade que realmente pediu.

Passo de preparaçãoPorque importa para a apresentação guiadaO que saltar
Confirmar a redação exata do briefingMantém a gravação ancorada ao que foi pedidoFuncionalidades acrescentadas desde o briefing mas ainda não aprovadas
Chegar ao estado anterior ao gatilhoA gravação começa na ação relevanteCriação de conta, integração inicial, navegação não relacionada
Escolher produção ou teste de versãoO revisor sabe qual fase da construção está a aprovarMisturar as duas numa gravação sem o dizer

Se o fluxo de trabalho só for acionado para um utilizador com sessão iniciada, forneça uma conta de demonstração através do processo aprovado, em vez de partilhar o início de sessão real de um cliente. O tratamento no GogoScreen é que as credenciais são cifradas, utilizadas para uma única renderização, e depois eliminadas. Se for planeado primeiro um storyboard, as credenciais ficam cifradas durante essa sessão e são eliminadas, no máximo, duas horas após a última utilização. Diga-o dessa forma se surgir o assunto, já que a descrição exata é também a mais tranquilizadora para um revisor que pergunte.

O que deve dizer a indicação de uma linha?

Escreva a indicação da forma como orientaria um colega que nunca abriu a aplicação. Nomeie o ponto de partida, a ação, e o resultado exato que o briefing prometeu. "A partir da lista de candidaturas, aprovar a candidatura pendente e mostrar o estado a mudar para aprovada" dá um alvo preciso. Uma indicação vaga como "mostrar a funcionalidade de aprovação" convida a uma gravação que se afasta do único momento de que o revisor realmente precisa de ver.

Mantenha a redação na indicação consistente com a redação do briefing e da própria aplicação. Se o briefing chama a algo uma candidatura e a interface da aplicação lhe chama uma submissão, escolha um termo e use-o na indicação, para que a narração não introduza uma incompatibilidade que o revisor tenha de resolver sozinho.

O que corre mal se a apresentação guiada for demasiado ampla?

Uma apresentação guiada que tenta cobrir o fluxo de trabalho pedido mais três outras coisas que por acaso estão próximas costuma deixar o revisor menos seguro, não mais. Se um fluxo secundário tropeçar num caso limite a meio da gravação, o cliente tem agora uma nova pergunta em aberto sobre algo que nem sequer estava a rever inicialmente. Mantenha cada apresentação guiada restrita, um pedido, um resultado, e envie uma separada para cada item distinto do briefing, em vez de os combinar para poupar uma renderização.

Aproximadamente uma em cada cinco renderizações precisa de nova tentativa ou falha por completo, o que vale a pena saber antes de prometer a um revisor um envio no mesmo dia. Integre isso no calendário, em vez de tratar a primeira tentativa como garantida. O guia de falha de renderização de vídeo de demonstração cobre o que verificar antes de submeter de novo quando uma renderização não volta da forma esperada.

Como se liga isto ao resto do fluxo de revisão e lançamento?

Uma apresentação guiada Bubble enviada para revisão interna é apenas uma fase. Assim que um fluxo de trabalho é aprovado, o mesmo fluxo pode precisar de aparecer novamente para um público diferente, e a mesma disciplina de fundo mantém-se, ainda que as especificidades da plataforma mudem. Um vídeo de demonstração Firebase Studio começa pela mesma pergunta sobre o que um fluxo prova, enquanto o guia do vídeo de página de destino Firebase Studio é sobre prova para um estranho, e não para um revisor que já conhece o projeto. O guia do vídeo de lançamento Firebase Studio no Product Hunt cobre um público de galeria de lançamento, e o guia de partilha Firebase Studio com um cliente e o guia de demonstração de portefólio Firebase Studio tratam cada um de uma versão do problema de entrega que esta página resolve para o Bubble.

Para uma construção originada numa conversa com investidores em vez de um briefing de cliente, o guia do vídeo de demonstração para investidores por agente de IA cobre um público relacionado mas distinto, com expectativas diferentes. Se a própria aplicação foi montada através de um construtor de sites com IA em vez de à mão no editor Bubble, o guia do vídeo de demonstração de construtor de sites com IA é a opção mais próxima. Assim que um fluxo de trabalho revisto acaba por ser lançado como funcionalidade, o guia do vídeo de demonstração de lançamento de funcionalidade e o guia do vídeo de changelog para um SaaS cobrem o anúncio público, o que é uma tarefa separada da revisão privada a que esta apresentação guiada se destina.

Feche o ciclo com uma nota curta escrita junto ao vídeo: o que foi revisto, o que passou, e o que continua em aberto. O vídeo prova que o fluxo de trabalho funcionou. A nota é o que o revisor guarda como registo da decisão. Para tudo o resto no fluxo de trabalho, veja as alternativas Bubble a uma ferramenta de gravação de ecrã guiada, a página de preços para os planos e carregamentos, a biblioteca completa de guias, as páginas de comparação, e a página inicial do GogoScreen para o próprio fluxo de trabalho de URL e indicação.

Esclarecimentos

Antes de começar

O que deve provar uma apresentação guiada de revisão de uma aplicação Bubble?

Deve provar que o fluxo de trabalho específico pedido no briefing corre de ponta a ponta na construção em produção ou em teste de versão, desde o gatilho que o revisor espera até ao resultado que lhe foi dito que devia esperar.

Quem é o público de um vídeo de apresentação guiada de revisão Bubble?

Normalmente um cliente, gestor de projeto, ou responsável de agência que não vai abrir o editor Bubble nem clicar sozinho num link de teste de versão. Precisam de ver o resultado, não de inspecionar a lógica do fluxo de trabalho.

Uma apresentação guiada de revisão substitui uma atualização de estado escrita?

Não. Substitui a parte de uma atualização de estado que é difícil de descrever por palavras, o momento em que um fluxo de trabalho realmente é acionado e a aplicação responde. Combine-a com uma nota curta escrita sobre o que foi revisto e o que ainda está em aberto.

Cole um URL, descreva um fluxo e obtenha um vídeo de demonstração da sua aplicação web.

Os primeiros 60 segundos de vídeo são gratuitos, com marca de água. Verifique o seu correio eletrónico para descarregar o vídeo.