1. Defina o que o redesign deve mudar
Uma lista de verificação útil para o redesign de um site cumpre três funções: proteger o que já ajuda os clientes, especificar o que precisa de ser corrigido e definir como será testada a nova versão. Comece pelo site atual e por algumas tarefas reais dos visitantes. A renovação visual é uma parte do trabalho; os pedidos de contacto, o conteúdo útil e os links existentes também precisam de sobreviver à transição.
Registe os problemas que consegue identificar de forma concreta. Talvez os visitantes não consigam comparar serviços num telemóvel, o formulário de contacto peça dados que a sua equipa nunca utiliza ou os colaboradores não consigam atualizar os horários. Ao lado de cada problema, descreva o funcionamento pretendido. «Um visitante consegue escolher um serviço e enviar um pedido de contacto sem nos telefonar para pedir instruções» dá a quem avalia algo que pode testar.
Distinga a renovação visual das alterações ao conteúdo, à estrutura das páginas e às ferramentas ligadas ao site. Podem integrar o mesmo projeto, mas cada uma exige uma decisão explícita. Se o principal problema for uma oferta desatualizada, mudar a tipografia não será suficiente. Use o guia do briefing de um projeto de site para definir o projeto mais alargado; esta lista centra-se no que um site existente deve preservar durante um redesign.
2. Decida o que manter, rever, juntar ou retirar
Crie um inventário das páginas antes de aprovar novos layouts. Registe cada endereço atual, a sua finalidade, o conteúdo importante e a pessoa que pode aprovar alterações. Inclua páginas fora do menu principal, documentos descarregáveis, versões noutros idiomas e páginas de destino de campanhas. Pergunte aos colegas que links enviam aos clientes; o material útil nem sempre tem destaque na navegação.
Atribua uma decisão a cada elemento:
- Manter: a finalidade e a informação continuam a ser úteis, mesmo que a apresentação mude.
- Rever: a página mantém-se, mas uma parte identificada do conteúdo precisa de aprovação.
- Juntar: outra página irá incorporar o seu material útil e responder à mesma necessidade do visitante.
- Retirar: o conteúdo já não tem uma finalidade válida e a sua remoção foi acordada.
Preserve a informação concreta que ajuda alguém a decidir: limites dos serviços, condições de acesso, zonas de cobertura, instruções práticas e dados de contacto. Um texto mais curto não é necessariamente mais claro se eliminar a resposta que o cliente procurava. Guarde os textos e as imagens anteriores que estavam aprovados, para que seja possível comparar tanto o conteúdo como a apresentação.
Se existirem registos de pedidos de contacto ou relatórios de pesquisa, use-os para identificar páginas que merecem mais atenção. Se houver poucos dados, assinale essa incerteza. A opinião interna de que uma página «não faz nada» é um motivo para investigar, não uma prova suficiente para a eliminar.
3. Dê um destino a cada URL que mude
Um redesign pode manter os endereços existentes das páginas. Peça uma justificação sempre que um deles mudar: a junção de serviços ou uma estrutura mais clara podem justificá-lo; uma nova paleta de cores, não. Para cada página movida, registe o endereço antigo e o destino adequado que o substitui. Peça ao programador que verifique todo o mapeamento acordado, não apenas a página inicial.
A Google recomenda redirecionamentos permanentes do lado do servidor, como HTTP 301 ou 308, quando uma página muda de endereço de forma permanente. A verificação prática para a aceitação é simples: abrir o endereço antigo leva o visitante à página correta que o substitui, e esta carrega sem problemas.
As orientações da Google para a mudança de sites aconselham a encaminhar os redirecionamentos diretamente para o destino final e a evitar destinos sem relação, como redirecionar todas as páginas eliminadas para a página inicial. Uma página efetivamente retirada, sem substituição adequada, deve devolver a resposta 404 ou 410 apropriada. Peça ao programador que documente essa decisão.
Atualize os links internos, as referências canónicas, os links entre idiomas quando utilizados e o mapa do site para refletir os endereços alterados. As orientações da Google recomendam manter os redirecionamentos durante pelo menos um ano, ou mais tempo quando forem úteis aos visitantes. Acorde quem fará a sua manutenção após a entrega. Um plano de redirecionamentos protege a continuidade; não garante uma posição nos resultados de pesquisa nem uma data de indexação.
4. Acompanhe um pedido de contacto até chegar à sua equipa
Um formulário só está completo quando a informação do visitante chega ao destino acordado e alguém pode dar-lhe seguimento. Registe os campos atuais, o destinatário, a confirmação e qualquer sistema de reservas ou de gestão de clientes ligado ao formulário. Decida que funcionamento se mantém e o que muda. Um formulário reconstruído pode parecer igual e, ainda assim, enviar a informação para um destino diferente.
Execute uma pequena sequência de testes planeados
Use dados claramente identificados como dados de teste. Envie um pedido válido e verifique depois a caixa de entrada real ou o registo no sistema ligado: a escolha do serviço, a mensagem, o endereço de resposta e qualquer anexo acordado devem chegar corretamente. Teste campos obrigatórios em falta e um endereço de email inválido. Verifique se a explicação ajuda o visitante a corrigir o problema.
Peça ao programador que demonstre o comportamento acordado quando a entrega falha, num teste controlado. Uma mensagem de sucesso deve corresponder ao estado de envio bem-sucedido acordado, e uma falha deve indicar um próximo passo útil. Não use dados de clientes reais para testar o tratamento de erros.
Siga também os links de telefone e de email e os botões de reserva a partir da respetiva página de origem. Se uma página de serviço já transmitia a seleção do serviço ao formulário de contacto, confirme que continua a fazê-lo. Este pequeno elemento de contexto pode desaparecer facilmente quando as páginas e os formulários são reconstruídos em separado.
5. Avalie o design através de tarefas reais
Avalie a pré-visualização funcional com o conteúdo final, não apenas um design estático. Abra a página de serviço mais longa, uma página com várias imagens e o percurso principal de contacto. Nos telemóveis e navegadores de computador acordados, experimente as tarefas registadas no início. Verifique se a navegação continua utilizável, o texto cabe, os controlos respondem e os detalhes importantes permanecem visíveis.
Inclua a acessibilidade nesta avaliação. As verificações simples da W3C WAI apresentam testes iniciais para títulos, alternativas textuais de imagens, contraste, redimensionamento do texto, utilização do teclado e formulários. Experimente navegar sem rato, procure um indicador visível do foco do teclado e aumente o texto enquanto completa a tarefa principal.
Estas verificações constituem uma primeira avaliação. As orientações de avaliação do W3C explicam que uma ferramenta, por si só, não permite determinar se um site cumpre as normas de acessibilidade; é necessária uma avaliação humana com os conhecimentos adequados. Acorde com o fornecedor a norma exigida, o âmbito da avaliação e quem será responsável. Registe as barreiras por resolver juntamente com os restantes defeitos.
Quanto à velocidade, peça verificações comparáveis de páginas representativas do site antigo e do novo, em condições documentadas. Observe o que acontece enquanto as imagens e as fontes carregam e se é possível executar a ação principal. Trate a pontuação de um teste como um dado de diagnóstico. A discussão de aceitação deve identificar problemas reais, as páginas afetadas e as correções acordadas.
6. Use uma folha de verificação com critérios de aceitação observáveis
Copie a folha de verificação seguinte para o documento do seu projeto. Substitua cada exemplo pelas suas páginas, ferramentas e condições de teste acordadas. Acrescente a cada linha um responsável, um link para as evidências, o resultado e a data de revisão. «Parece bem» não permite à próxima pessoa saber o que foi verificado.
| Área | O que deve ser demonstrado |
|---|---|
| Conteúdo | Os detalhes dos serviços e os dados de contacto acordados aparecem em cada página aprovada; as revisões têm um responsável. |
| Links existentes | Cada endereço da lista de migração chega ao destino acordado ou devolve a resposta de remoção acordada. |
| Pedidos de contacto | Um envio identificado como teste chega ao destino correto com os campos acordados, e são verificados a validação e os estados de falha. |
| Tarefas dos visitantes | Uma pessoa conclui o percurso principal nos dispositivos e navegadores especificados, incluindo as verificações de teclado e zoom acordadas. |
| Publicação | O conteúdo aprovado está publicado, as verificações críticas passam no domínio público e uma pessoa designada consegue restaurar a versão anterior. |
| Responsabilidades | A empresa dispõe dos acessos acordados, das responsabilidades de manutenção definidas e das instruções para atualizações de rotina. |
Classifique os resultados antes da aprovação final. Um pedido de contacto que não chega, uma página de serviço inacessível ou uma ação essencial bloqueada devem impedir o lançamento. Um pequeno ajuste de espaçamento pode ter um responsável e uma data posterior acordada. Façam esta distinção em conjunto, para que nenhuma das partes confunda uma lista de trabalho por concluir com um registo de aceitação.
7. Planeie a mudança e uma forma viável de recuperação
Antes do lançamento, identifique a versão aprovada, a pessoa que fará a mudança e a pessoa que a irá verificar. Guarde uma cópia recuperável do site atual e da configuração relevante. Pergunte o que envolve o restauro, quem o pode fazer e o que acontece aos pedidos de contacto ou conteúdos enviados durante a transição. Uma cópia de segurança só é útil se a equipa souber recuperá-la.
Acorde quando terminam as edições de conteúdo e como serão incorporadas as alterações de última hora. Isto importa mesmo num site pequeno: caso contrário, um número de telefone atualizado ou uma descrição de serviço podem ser substituídos por um rascunho antigo. Se o alojamento ou as definições do domínio também mudarem, verifique explicitamente os serviços dependentes, como o email da empresa.
Repita as verificações críticas no domínio público imediatamente após a mudança. Confirme os links antigos, o percurso principal do visitante e a entrega real dos envios de teste. Peça ao programador que verifique se as páginas públicas têm as definições de indexação pretendidas e se as restrições temporárias da pré-visualização não passaram para produção. Mantenha a pessoa responsável pelas correções disponível durante o período de lançamento acordado.
8. Conclua o projeto com evidências e responsabilidades definidas
Marque uma revisão de acompanhamento com um responsável designado. Verifique os problemas comunicados, as páginas inesperadamente em falta e a entrega dos pedidos de contacto. Quando existirem relatórios de pesquisa, avalie as alterações no seu contexto em vez de tratar a evolução de um único dia como um veredito sobre o redesign. Guarde a data de lançamento e o registo de alterações para poder investigar observações posteriores.
Na entrega, reúna o inventário final de páginas, a lista de redirecionamentos, os resultados de aceitação, os acordos de acesso e as instruções de atualização. Pergunte que tarefas contínuas estão incluídas e quais precisam de um acordo separado. Antes de considerar a entrega concluída, peça à pessoa que irá manter o site que demonstre uma alteração de conteúdo de rotina.
O redesign de sites da Digital Studio começa nos 1 790 EUR para até cinco páginas existentes com o seu conteúdo atual, incluindo uma análise do site, reconstrução responsiva e os redirecionamentos de URL acordados. As migrações de maior dimensão têm orçamento separado. Para falar sobre um site existente, envie um pedido gratuito sobre o redesign com o endereço, o principal problema e o que deve ser preservado. Não é necessário efetuar qualquer pagamento para enviar o pedido.
