Saltar para o conteúdo
Guia6 min de leitura

Partilhar Cursor com um Cliente

Mostre a um cliente a compilação a funcionar, sem lhe pedir para abrir uma ligação.

Entregue a um cliente não técnico prova de que uma compilação Cursor funciona, partindo de uma implementação real em vez de uma ligação que não vai abrir.

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.

Um cliente que encomendou trabalho num projeto Cursor não tem interesse no editor, na linguagem ou em como o código está organizado. Quer saber se aquilo por que pagou está feito. Enviar-lhe uma ligação pede-lhe que confie num endereço que nunca viu, que navegue numa interface que não conhece e que encontre por si próprio a parte relevante. Um vídeo curto elimina todos esses passos. Ele carrega em reproduzir e vê o trabalho pedido a acontecer.

O GogoScreen recebe um URL de aplicação web e uma indicação de uma linha sobre o que mostrar, e depois devolve um MP4 narrado e editado com zooms nos cliques, suavização do cursor, cortes de tempo morto e legendas incorporadas. Para uma compilação Cursor especificamente, há um passo antes de tudo isso: a aplicação tem primeiro de estar implementada nalgum lugar acessível, uma vez que o próprio Cursor não gera uma ligação de pré-visualização. Assim que essa implementação existir, a ferramenta funciona da mesma forma que funcionaria com qualquer outro URL.

Por que motivo uma entrega Cursor precisa de um passo extra?

Confirme que a implementação está ativa e estável antes de gravar seja o que for que vai ser mostrado ao cliente. Uma plataforma que é lançada com uma ligação de pré-visualização automática torna este passo invisível. Um projeto Cursor não, por isso tem de ser tratado deliberadamente, normalmente implementando no alojamento que a equipa já utiliza para o projeto, ou configurando uma implementação especificamente para apoiar a entrega. Faça isto antes de escrever a indicação, não ao mesmo tempo, porque a implementação pode demorar mais do que o esperado se ainda não tiver sido feita antes.

Verifique que a implementação é uma que ainda vai estar ativa quando o cliente realmente assistir ao vídeo, e não um ambiente temporário que é desativado no dia seguinte. Um cliente que contacta com uma pergunta de acompanhamento uma semana depois e encontra a ligação morta vai interpretar isso como prova de que o trabalho nunca foi realmente concluído, mesmo que o fluxo gravado fosse preciso na altura.

Esta entrega é diferente do guia de demonstração de portefólio Cursor, que é escrito para um público geral a decidir se vale a pena contratar o programador, e do guia de apresentação guiada de revisão de aplicação Cursor, que é escrito para um revisor a verificar uma compilação em relação a um briefing escrito. Uma entrega a um cliente fica entre estes dois: o público já encomendou o trabalho, por isso a única pergunta em aberto é se a coisa específica que pediu agora existe e funciona.

O que o cliente está a avaliarO que uma ligação de pré-visualização simples lhe pedeO que o vídeo elimina
Se o trabalho pedido está feitoClicar, navegar, encontrar o ecrã relevanteVê o fluxo exato concluído
Se isto parece digno de confiançaAvaliar um endereço que nunca viuNada a clicar, nada a questionar
Se isto corresponde ao que foi pedidoComparar a aplicação com a sua memória do briefingA narração pode nomear o pedido diretamente

Como escolher o fluxo a mostrar?

Escolha o único fluxo que corresponde exatamente ao que o cliente pediu, não uma visita mais ampla à compilação. Volte ao pedido original, não ao estado atual do código. Se o briefing pediu um formulário de encomenda que envia um e-mail de confirmação, mostre exatamente isso, concluído, em vez de uma visão mais ampla ao painel de administração por trás dele. Um cliente que compara o vídeo com a sua memória do pedido vai reparar se os dois não coincidirem.

  • Confirmar a rota exata a partir da qual o fluxo pedido começa.
  • Utilizar dados de exemplo plausíveis em vez de tabelas vazias ou texto de marcador de posição.
  • Remover do ambiente quaisquer informações de outros clientes antes de gravar.
  • Se um início de sessão bloquear o fluxo, arranjar uma conta de demonstração em vez de uma real.

Porque as compilações Cursor tendem a incluir lógica de backend genuína em vez de uma maqueta rápida, este passo de preparação importa mais do que importaria para um protótipo leve. Teste o fluxo manualmente imediatamente antes de gravar, para que o estado captado no vídeo corresponda ao que foi verificado pela última vez a funcionar.

Resista à tentação de mostrar mais do que o cliente pediu, mesmo quando outras partes da compilação estão terminadas e são impressionantes. Um cliente que vê um vídeo a desviar-se do pedido delimitado para território não relacionado pode questionar-se se o pedido original se perdeu algures no processo. Se houver trabalho adicional terminado que valha a pena mencionar, refira-o separadamente, depois de o cliente ter confirmado que o fluxo pedido é exatamente o que queria.

Como lidar com um início de sessão real para esta gravação?

Se um início de sessão bloquear o fluxo, uma conta de demonstração pode ser fornecida através do processo aprovado e, no GogoScreen, 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. Não utilize a própria conta ou credenciais do cliente para isto, mesmo que fosse a forma mais rápida de mostrar exatamente os dados que ele espera. Uma conta de demonstração dedicada mantém o processo de gravação separado de qualquer conta que importe a alguém, e significa que o cliente nunca terá de se questionar sobre o que aconteceu ao seu próprio início de sessão depois.

Escreva uma indicação que nomeie o início, a ação e o resultado, e depois envie o ficheiro terminado em vez de uma ligação. Formule-a com as próprias palavras do cliente sempre que possível, correspondendo à forma como o briefing original descreveu o pedido, em vez de como a base de código acontece por rotular as coisas internamente.

  1. Confirmar que a implementação está ativa e estável antes de gravar seja o que for que vai ser mostrado ao cliente.
  2. Escolher o único fluxo que corresponde exatamente ao que o cliente pediu, não uma visita mais ampla à compilação.
  3. Escrever uma indicação que nomeie o início, a ação e o resultado, e depois enviar o ficheiro terminado em vez de uma ligação.

O que deve verificar antes de o enviar?

Aproximadamente uma em cada cinco renderizações falha ou precisa de nova tentativa, por isso assista ao candidato antes de chegar ao cliente. O guia de vídeo de demonstração de produto para README é uma comparação útil aqui, uma vez que ambos os públicos precisam de que o vídeo se sustente por si só, sem exigir uma explicação separada ao lado. Se a aplicação incluir um estilo de narração muito centrado em voz sobreposta, o guia de voz sobreposta para um vídeo de demonstração de produto cobre como garantir que a narração corresponde ao fluxo com precisão, em vez de soar como texto de marketing genérico.

Se o produto do cliente ainda estiver antes do lançamento, o guia de vídeo de demonstração para uma lista de espera SaaS cobre um caso de uso relacionado para criar expetativa antes de a aplicação ser totalmente pública. Se a compilação em questão tiver sido feita em v0 em vez de Cursor, o guia de vídeo de demonstração de aplicação v0 cobre a mesma disciplina de entrega para um projeto com um ponto de partida diferente. Para um contexto de lançamento mais amplo, além de um único cliente, a lista de verificação de lançamento de agente de IA cobre o conjunto mais amplo de passos que um lançamento normalmente precisa.

Para a mesma tarefa noutras páginas Cursor, veja o guia de vídeo de demonstração Windsurf, o guia de vídeo de página de destino Windsurf e o guia de vídeo de lançamento no Product Hunt Windsurf, que cobrem a entrega equivalente para um editor assistido por IA diferente. Para uma comparação direta de ferramentas de gravação, veja GogoScreen versus Demosmith. Comece pela página inicial para o fluxo de trabalho de URL e indicação, percorra os guias para o resto da série, verifique as comparações com outras ferramentas, e reveja os preços antes de submeter uma renderização para um cliente.

Esclarecimentos

Antes de começar

Por que motivo um vídeo é melhor do que uma ligação para uma entrega Cursor a um cliente?

Um cliente que não constrói software muitas vezes não vai clicar numa ligação desconhecida, e um projeto Cursor de qualquer forma não tem um URL de pré-visualização automático para lhe indicar. Um vídeo elimina ambos os problemas mostrando o trabalho diretamente.

O cliente precisa de saber como a aplicação foi construída?

Não. O cliente está a avaliar se o trabalho pedido está feito, não que editor ou ferramentas o produziram. Mantenha a narração centrada no fluxo, não no processo de construção.

E se a aplicação exigir um início de sessão real?

Utilize uma conta de demonstração descartável em vez das credenciais do próprio cliente ou de uma conta pessoal. No GogoScreen, as credenciais fornecidas 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.

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.