O design do seu website está aprovado. Isso significa que pode publicá-lo? Ainda não: falta confirmar se o que foi construído permite ao cliente fazer o que precisa e à empresa gerir o que vai entregar.
A nossa recomendação é separar duas decisões: aprovar a apresentação e autorizar a publicação. A primeira confirma uma direção visual. A segunda aceita uma versão concreta do website, com funções verificadas e eventuais pendências conhecidas.
Para um responsável de empresa, esta fase não deve transformar-se numa inspeção ao código. Deve ser uma revisão orientada por tarefas, com alguém a decidir o que está concluído, o que precisa de correção e o que fica fora desta entrega.
Comece por esclarecer o que foi aprovado
Antes da revisão final, escreva uma frase que descreva a aprovação anterior. Por exemplo: «Aprovámos a apresentação da página inicial e da página de serviço, incluindo cores, tipografia e organização dos blocos.»
Esta formulação é preferível a «o site está aprovado». Torna explícito o que já foi decidido, sem dar por concluído aquilo que ainda não foi visto.
Propomos separar o projeto em três momentos:
- Aprovação visual: organização, identidade gráfica e apresentação dos modelos de página.
- Aceitação funcional e editorial: utilização do website construído, com conteúdos finais e tarefas verificadas.
- Autorização de publicação: decisão de disponibilizar uma versão identificada no endereço público.
Não é preciso criar três reuniões. Basta não confundir os respetivos resultados.
Junte a proposta aceite, as alterações entretanto acordadas e a versão disponível para revisão. Use esse conjunto como referência. Se houver interpretações diferentes sobre uma funcionalidade, esclareça-as antes de classificar o trabalho como terminado ou incompleto.
Reveja tarefas, não apenas páginas
«Ver a página dos serviços» é uma instrução demasiado vaga. «Descobrir se a empresa presta assistência no meu concelho e encontrar como a solicitar» já permite avaliar uma necessidade concreta.
O manual de conteúdos do Office for National Statistics descreve os critérios de aceitação precisamente como condições específicas que permitem verificar se uma necessidade do utilizador foi satisfeita. É uma base útil para organizar esta revisão, embora não seja uma obrigação aplicável às empresas portuguesas. (service-manual.ons.gov.uk)
Exemplo hipotético: uma empresa de aluguer de equipamento industrial prepara o lançamento do seu primeiro website. A apresentação está aprovada, mas o responsável comercial ainda precisa de confirmar se um visitante consegue:
- Identificar o equipamento adequado à utilização pretendida.
- Perceber em que zonas existe entrega.
- Consultar as condições de aluguer publicadas.
- Encontrar o contacto certo para esclarecer disponibilidade.
Escolha tarefas ligadas ao objetivo contratado. Um website de apresentação de serviços não precisa do mesmo guião que um catálogo com pesquisa e filtros.
Para cada tarefa, registe o ponto de partida e o resultado esperado. Evite indicar o caminho completo: se disser antecipadamente onde clicar, deixa de observar se a organização do website faz sentido.
Distribua a revisão por competência
Sugerimos uma divisão simples: a equipa comercial confirma oferta e condições; quem vai atualizar o website experimenta a edição; a equipa de desenvolvimento verifica o funcionamento técnico. Uma pessoa reúne os resultados e resolve contradições.
Esta participação da empresa complementa os testes técnicos, não os substitui. O Service Manual do GOV.UK recomenda testar tanto a utilização como os componentes técnicos e envolver a equipa na identificação dos problemas de qualidade. (gov.uk)
Use uma folha de decisão para autorizar o lançamento
A tabela seguinte é uma proposta de trabalho para um website empresarial. Adapte-a ao âmbito contratado e acrescente duas colunas: responsável e estado. Os estados podem ser «por verificar», «aceite» ou «pendente».
| Área de aceitação | Evidência a guardar | Regra proposta para a decisão |
|---|---|---|
| Oferta publicada | Páginas revistas por quem conhece os serviços e as condições comerciais | Informação comercial incorreta bloqueia a publicação |
| Percursos principais | Registo das tarefas realizadas e dificuldades encontradas | Uma tarefa essencial impossível de concluir bloqueia |
| Utilização em telemóvel | Revisão das páginas e funções prioritárias nos dispositivos acordados | Conteúdo ou ações essenciais inacessíveis bloqueiam |
| Edição pela empresa | Demonstração de uma alteração representativa por quem vai gerir o site | Se a autonomia foi contratada e não funciona, corrigir ou acordar uma solução antes de lançar |
| Acessibilidade | Resultados da avaliação com âmbito identificado | Barreiras nas tarefas essenciais precisam de resolução antes da autorização |
| Publicação técnica | Confirmação das verificações no endereço definitivo | Problemas que impedem o acesso público bloqueiam |
| Pendências | Lista com impacto, responsável e prazo acordado | Não autorizar com problemas relevantes ainda por classificar |
Estas regras são uma recomendação editorial, não uma norma universal de aceitação. O seu valor está em tornar a decisão explícita antes de surgir pressão para cumprir uma data.
Não aceite apenas uma marca verde. Uma evidência pode ser uma nota com a tarefa, o resultado, a data e a versão revista. Um vídeo curto pode ajudar a reproduzir uma dificuldade, mas não é necessário gravar toda a revisão.
Dê atenção ao que uma apresentação não mostra
Peça para rever o website construído, não apenas imagens do design. Para a aceitação, propomos incluir páginas com conteúdo curto e longo, menus abertos, resultados vazios e mensagens de erro, quando esses estados existirem no projeto.
No exemplo hipotético do aluguer industrial, vale a pena experimentar uma pesquisa sem equipamentos correspondentes. O resultado ajuda o visitante a tentar outra pesquisa ou deixa-o sem orientação? Esta é uma decisão de experiência de utilização, não uma discussão sobre cores.
Na acessibilidade, a W3C apresenta verificações iniciais como navegação por teclado, ampliação do conteúdo, títulos e identificação dos campos. Também avisa que essas verificações cobrem apenas parte dos problemas e não constituem uma avaliação completa. Não transforme uma passagem rápida numa declaração de conformidade. (w3.org)
Se a avaliação revelar barreiras, registe a tarefa afetada e encaminhe a correção para quem tem competência para a executar. Uma aprovação empresarial não deve servir para dispensar requisitos de acessibilidade aplicáveis ao projeto.
Experimente também o trabalho de quem vai editar
Se contratou um website que a empresa pode atualizar, inclua uma pequena demonstração feita pelo futuro editor: alterar um horário, substituir uma imagem ou acrescentar um serviço, conforme o âmbito acordado.
A pergunta não é «existe um painel de gestão?». É «a nossa equipa consegue fazer as alterações previstas, com as instruções e permissões entregues?».
Caso a gestão de conteúdos fique a cargo de uma agência, a verificação muda: confirme como se envia um pedido, quem o aprova e como se confirma a publicação. Não imponha autonomia de edição a um modelo de serviço que não a prevê.
Separe erros de alterações ao projeto
Recomendamos que cada observação da revisão receba uma destas classificações:
Correção: o resultado não corresponde ao que foi acordado. Uma opção prevista no menu não aparece, por exemplo.
Alteração: a empresa pretende mudar uma decisão aprovada. Pode fazer sentido, mas deve ser avaliada quanto ao trabalho e ao calendário antes de ser executada.
Melhoria posterior: existe uma ideia útil que não é necessária para cumprir o objetivo desta entrega.
Considere outro exemplo hipotético: o projeto incluía um catálogo organizado por categoria. Durante a revisão, a empresa decide acrescentar um comparador de equipamentos. Trate esse pedido como uma alteração de âmbito, não como um erro do catálogo.
Já uma categoria acordada que não pode ser aberta deve entrar na lista de correções.
Não há uma regra universal sobre quantas revisões estão incluídas ou quanto custa uma alteração. A resposta deve estar nas condições acordadas. Antes de aprovar trabalho adicional, obtenha a descrição da mudança, o respetivo valor e o efeito previsto na entrega, sem confundir esse orçamento com a resolução de defeitos.
Autorize uma versão e volte a verificar depois da publicação
Para fechar a revisão, recomendamos uma autorização escrita curta: identificação da versão, data pretendida, pendências aceites e nome de quem pode decidir. Evite autorizações vagas como «podem avançar, depois vemos».
Combine também quem confirma o funcionamento no endereço definitivo. Essa confirmação deve incluir os percursos prioritários e os elementos que dependem do ambiente público.
Uma verificação técnica relevante é garantir que as páginas destinadas à pesquisa não mantêm bloqueios usados durante a preparação. A documentação da Google identifica proteção por palavra-passe, diretivas `noindex` e bloqueios de rastreio entre as possíveis causas de páginas ausentes da pesquisa. A equipa técnica deve distinguir esses mecanismos e verificar a configuração apropriada. (support.google.com)
Estar acessível não significa aparecer imediatamente nos resultados. A Google explica que descobrir e rastrear páginas publicadas pode demorar de alguns dias a algumas semanas. Por isso, recomendamos não usar «já aparece no Google» como condição única para aceitar a publicação. (developers.google.com)
Antes de encerrar o projeto, deixe ainda combinado quem recebe problemas detetados após o lançamento e como se distingue a correção da entrega de novos pedidos ou manutenção continuada. Não assuma que esses serviços estão incluídos sem o confirmar.
A próxima ação é simples: marque uma revisão de aceitação com tarefas reais e leve a folha de decisão preenchida. Se estiver a contratar a criação de um website, inclua esta etapa no processo desde o início. A data de lançamento deve resultar de uma versão pronta para servir o seu negócio, não apenas de uma apresentação que recebeu aprovação.