Saltar para o conteúdo
Guia7 min de leitura

Partilhar um Projeto Windsurf com um Cliente

Alguns clientes nunca clicam na ligação. Envie-lhes o resultado.

Entregue uma aplicação Windsurf concluída a um cliente não técnico que não vai abrir uma ligação de pré-visualização, usando um vídeo em vez de um URL.

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.

Alguns clientes abrem todas as ligações que lhes envia. Outros não, seja por falta de tempo, por falta de à-vontade com software pouco familiar, ou simplesmente por preferirem que lhes digam em vez de lhes mostrarem onde clicar. Um projeto Windsurf construído para esse segundo tipo de cliente precisa de uma entrega diferente de um URL de pré-visualização e uma mensagem esperançosa. Um vídeo curto que se reproduz sozinho, sem necessidade de início de sessão nem de navegação, respeita tanto o tempo do cliente como a realidade de que talvez nunca tenha aberto uma ligação de staging na vida.

O próprio Windsurf é um editor de código, e o cliente quase de certeza nunca ouviu falar dele e não precisa de o fazer. O que pediu foi um resultado, descrito nas suas próprias palavras durante uma chamada ou um email, não uma funcionalidade técnica. O vídeo deve responder diretamente a esse pedido original, usando o vocabulário do próprio cliente em vez dos termos internos da interface, uma vez que um cliente que tem de traduzir rótulos pouco familiares de volta para o seu pedido original está a fazer um trabalho que o vídeo devia ter feito por ele.

Este é um problema diferente de mostrar o mesmo projeto a uma audiência técnica. Uma demonstração de portefólio Windsurf é avaliada por alguém que quer ver perícia e está disposto a suportar alguma nuance. Um vídeo de revisão para cliente é avaliado por alguém que quer uma resposta de sim ou não e não vai suportar mais nada além disso. Confundir os dois, enviando a um cliente algo construído para uma audiência de portefólio, é uma forma comum de uma entrega a um cliente correr mal, mesmo quando o vídeo subjacente está bem feito.

O que precisa mesmo de ver um cliente não técnico?

Comece pelo pedido original, não pela estrutura da aplicação. Se o cliente pediu "uma forma de os clientes marcarem uma hora", o vídeo deve mostrar exatamente esse fluxo de marcação, descrito como marcação, não como quer que a base de código chame o objeto subjacente. Salte qualquer ecrã que o cliente não pediu, mesmo que polido, uma vez que um ecrã inesperado convida a uma pergunta sobre o âmbito em vez de confiança na entrega.

Os clientes também leem o ritmo de forma diferente de um revisor técnico. Um programador a ver um vídeo de revisão consegue acompanhar um corte rápido entre ecrãs porque já compreende a estrutura subjacente. Um cliente não consegue, e um vídeo que se move ao ritmo de um programador deixá-lo-á sem certezas sobre o que acabou de ver. Abrande o ritmo, deixe cada ecrã assentar tempo suficiente para ser registado, e resista à tentação de comprimir o vídeo apenas porque um corte mais rápido pareceria mais polido aos seus próprios olhos.

O que o cliente pediuO que o vídeo deve mostrarO que confunde mais do que ajuda
Uma descrição simples de um resultadoExatamente esse resultado, do início ao fimEcrãs ou termos que nunca mencionaram
Uma correção a algo que estava avariadoOs mesmos passos que antes falhavam, agora a funcionarUma área diferente que também foi alterada
Uma nova funcionalidadeEssa funcionalidade usada como a descreveramOpções de configuração dirigidas a um utilizador técnico

Uma checklist de vídeo de demonstração SaaS é uma referência geral útil para este tipo de preparação, ainda que este guia específico esteja escrito para uma audiência de cliente em vez de um comprador geral.

Como preparar a aplicação para um cliente que não vai explorá-la?

Abra a rota implementada você mesmo e complete exatamente a tarefa nas palavras do cliente. Confirme que não há dados de depuração esquecidos, nem texto de substituição, nem nada no ecrã que levante uma pergunta que prefira não responder por email. Um cliente que não vai explorar a aplicação também não lhe vai dar o benefício da dúvida sobre nada que pareça inacabado, uma vez que não tem outro contexto do projeto com que o comparar.

  • Percorra exatamente a tarefa que o cliente descreveu, pela ordem que descreveu.
  • Remova quaisquer dados de depuração ou de substituição que tenham ficado durante o desenvolvimento.
  • Prepare uma conta de demonstração se o fluxo precisar de início de sessão, em vez de enviar credenciais reais.
  • Confirme que nada no ecrã vai exigir uma explicação de seguimento.

Se for necessário início de sessão, pode ser preparada uma conta de demonstração para a renderização, e no GogoScreen as credenciais usadas 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. Isto importa aqui em particular, uma vez que é improvável que um cliente não técnico saiba o que fazer com um início de sessão mesmo que lhe enviasse um, e é melhor servido por nunca precisar de um sequer.

Pense no que o cliente vai fazer imediatamente depois de ver. Se o passo seguinte natural for uma resposta a dizer que sim, aprovado, essa resposta não deve exigir nada além do próprio vídeo. Se o cliente precisar de clicar para verificar algo que o vídeo não mostrou, o vídeo ainda não terminou o trabalho, e vale a pena acrescentar a parte em falta antes de enviar, em vez de esperar por uma pergunta de seguimento que uma gravação ligeiramente mais longa poderia ter evitado.

Como devem ser escritas a indicação e a narração?

  1. Traduza o pedido para as palavras do próprio cliente antes de decidir o que mostrar.
  2. Mostre o resultado antes de qualquer detalhe de interface, uma vez que é isso que pediram.
  3. Narre em linguagem simples, não terminologia de produto, para que nada precise de ser explicado depois.

Escreva a indicação da forma como explicaria o resultado ao telefone, não da forma como o descreveria a outro programador. Se a mensagem original do cliente usou uma frase específica, reutilize essa frase em vez de a substituir por um termo mais preciso mas pouco familiar. A precisão que exige um glossário não é uma precisão que o cliente consiga usar.

O que vem antes e depois desta entrega?

Se o cliente pediu uma revisão antes de o trabalho ser considerado terminado, este guia cobre o passo de entrega, enquanto o percurso de revisão de aplicação Windsurf cobre como estruturar o fluxo em torno do pedido original em si. Assim que um projeto é aprovado pelo cliente e a caminho de uma audiência mais ampla, um tratamento no estilo de vídeo de demonstração Base44, um vídeo de página de destino Base44, ou um vídeo de lançamento Base44 no Product Hunt respondem cada um a uma pergunta posterior diferente, ainda que a própria entrega ao cliente não precise de nada disso por agora.

Se o preço em vez da entrega for a questão em aberto com este cliente, um vídeo de demonstração para a página de preços de um SaaS é uma preocupação separada e posterior. Se o cliente estiver a ver a partir de um tópico público em vez de uma mensagem privada, isso está mais próximo de um vídeo de demonstração para o Show HN ou de uma demonstração de agente de IA no Product Hunt do que de uma entrega privada a um cliente, e o tom deve mudar em conformidade. A mecânica subjacente mantém-se igual de qualquer forma, e o guia de vídeo de demonstração de software a partir de um URL cobre essa mecânica com mais profundidade caso algum passo acima tenha ficado pouco claro.

O que deve verificar antes de o enviar?

Veja o vídeo terminado como se fosse o cliente, sem conhecimento prévio do projeto. Confirme que o resultado é visível sem narração, caso o vejam sem som num telemóvel, e confirme que nada no ecrã exige uma pergunta de seguimento para ser compreendido. Compare o formato com o Demosmith se estiver a ponderar uma forma diferente de empacotar esta mesma entrega.

Deixe margem para uma nova tentativa, uma vez que aproximadamente uma em cada cinco renderizações precisa de uma, e uma entrega a um cliente é um mau sítio para um atraso surpresa. Cada conta nova recebe 60 segundos de vídeo uma única vez, com marca de água, o que costuma ser suficiente para uma única tarefa de cliente, e depois disso o tempo comprado com carregamentos nunca expira e o tempo só é usado quando uma renderização é bem-sucedida. Consulte os preços para os planos, explore mais guias e comparações, ou comece pela página inicial do GogoScreen com a rota e a indicação em que esta entrega assenta.

Esclarecimentos

Antes de começar

Porque não enviar simplesmente ao cliente uma ligação de pré-visualização?

Uma ligação de pré-visualização assume que o cliente a vai abrir, perceber o que está a ver e interpretar corretamente uma interface pouco familiar. Muitos clientes não técnicos não fazem nada disso de forma fiável, e um vídeo elimina essa suposição por completo.

O que deve o vídeo mostrar a um cliente que não pediu detalhe técnico?

Mostre o resultado que lhe importa, descrito na sua própria linguagem em vez da terminologia interna da aplicação, com contexto suficiente para que não precise de ter visto o projeto antes.

Isto é diferente de um vídeo de demonstração geral?

O fluxo de trabalho de gravação é o mesmo. A diferença é a audiência. Um vídeo de revisão para cliente é escrito para alguém a decidir se o trabalho corresponde ao que pediu, não para um desconhecido a decidir se experimenta o produto.

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.