Site institucional para consultório odontológico

O ponto de partida

Um site de um profissional da saúde precisa transmitir confiança desde os primeiros segundos. Quem acessa a página geralmente está buscando mais do que informações sobre serviços, está também tentando decidir se pode confiar naquele profissional. Muitas vezes, essa pessoa chega com receios, como a dor, o custo do tratamento ou até de ser julgada por ter demorado a procurar ajuda. Por isso, a página precisa transmitir segurança, acolhimento e clareza para facilitar essa decisão.

Isso muda o objetivo da página. Não é empurrar para a conversão o mais rápido possível, mas sim reduzir a ansiedade o suficiente para que o contato pareça um passo pequeno. Foi essa a régua que usei para cada decisão do projeto.

Arquitetura de conteúdo

Diferente da landing page de página única, aqui o conteúdo não cabia em um documento só. Organizei em uma página institucional com seções ancoradas mais um conjunto de páginas de artigo independentes:

• Apresentação da profissional — quem atende, antes do que é oferecido. Em saúde, a pessoa vem antes do serviço.
• Serviços — descritos pelo que resolvem, não pelo nome técnico do procedimento.
• Como funciona o atendimento — o passo a passo do primeiro contato ao acompanhamento, que é o antídoto direto para o medo do desconhecido.
• Artigos — três páginas próprias, cada uma com sua rota, alimentadas por um catálogo central de metadados.
• Perguntas frequentes — as dúvidas que travam a decisão, respondidas antes de a pessoa precisar perguntar.
• Contato — formulário e canais diretos, no fim de um percurso que já respondeu às objeções.

Decisões de confiança

A parte do projeto que mais me interessou foi transformar a honestidade em um requisito da interface, e não apenas em uma observação secundária.

• Depoimentos rotulados como fictícios. A seção de relatos declara na própria interface que os depoimentos são inventados. Prova social falsa sem aviso é o tipo de coisa que, num site real de saúde, atravessa a linha.
• Formulário que avisa o que não faz. O formulário é só demonstração, não há back-end, nada é enviado ou guardado. A página diz isso explicitamente e pede que ninguém digite dados pessoais ou de saúde. Um formulário de aparência funcional em contexto médico convida a pessoa a escrever coisas sensíveis; era preciso desarmar isso.
• Sem número de contato real. O canal de WhatsApp só aparece se houver um número autorizado configurado. Sem isso, o botão explica que é demonstração em vez de discar para algum desconhecido.
• Demonstração fora dos buscadores. As páginas do site fictício pedem para não ser indexadas. Conteúdo odontológico assinado por uma profissional que não existe não deveria disputar a busca de quem tem uma dúvida real. Este estudo de caso é que é o conteúdo público.

Direção visual

Paleta de verdes suaves sobre fundo quase branco, com bastante respiro entre os blocos. Consultório é um contexto em que o visual precisa transmitir limpeza e calma; densidade visual alta funciona contra o objetivo.

Fotografia de apoio em tom claro e natural, com o cuidado de mostrar acolhimento em vez de procedimento. Imagem clínica reforçaria exatamente o medo que a página tenta reduzir.

Decisões técnicas

• Módulos por responsabilidade. Navegação, animação, formulário, perguntas frequentes e catálogo de artigos são arquivos separados, cada um com uma função. Foi o que manteve o projeto navegável conforme ele cresceu.
• Catálogo de artigos centralizado. Os metadados dos artigos vivem em um módulo de dados, e as páginas consomem dele. Adicionar um artigo é acrescentar uma entrada e uma pasta, não editar várias listas espalhadas.
• Cada artigo é uma rota real. São páginas estáticas próprias, descobertas automaticamente pelo build, não conteúdo trocado por JavaScript. Cada uma pode ser aberta, compartilhada e lida direto.
• Funções que recebem o documento por parâmetro. As funções que tocam o DOM aceitam a referência do documento em vez de acessar o global, o que permite testá-las injetando um documento simulado.
• Verificação de build automatizada. Um script roda depois do build e falha se as páginas esperadas, o pacote JavaScript ou as imagens dos artigos não estiverem lá, inclusive se alguma imagem tiver escapado do processamento de assets.

Acessibilidade e desempenho

• Formulário com rótulos associados, mensagens de erro ligadas aos campos e erros anunciados para leitores de tela.
• Perguntas frequentes em elementos que comunicam seu estado de expandido ou recolhido, operáveis por teclado.
• Movimento reduzido quando o sistema pede, com as animações de entrada desligadas.
• Imagens em WebP com dimensões declaradas, para o navegador reservar espaço e não deslocar o texto durante a leitura.

O que eu levo deste projeto

Aprendi que, em um site de saúde, não é só o código que importa. A forma como as informações são apresentadas também faz muita diferença. Por isso, deixei claro que os depoimentos eram fictícios, que o formulário era apenas uma demonstração e que o projeto não deveria aparecer nos buscadores