Site de consultório de psicologia — design e código, sozinho

Uma psicóloga clínica que atende sozinha precisava de um site de uma página capaz de transformar uma visita em uma sessão marcada. Não havia CMS a construir, nem login, nem backend: o mecanismo de agendamento inteiro seria o WhatsApp. O trabalho era fazer uma única página carregar o posicionamento, o acolhimento e a primeira frase de uma conversa — e depois construí-la.

Trabalho freelance sob a Locuz, depois da fase Spaceapps. Design e código sozinho: a pesquisa de referências, o moodboard, o guia de estilo, o design da página e o build de produção foram todos meus. Não havia marca pré-existente, e a única fotografia que recebi foi uma foto de perfil de 150×150.

O briefing

Uma página, em português, para uma psicóloga clínica que atende sozinha. Ela precisava fazer o que o site de um consultório faz quando não existe recepção atrás dele: dizer quem ela é e quem ela atende, nomear os sentimentos com que as pessoas de fato chegam, explicar a abordagem, listar os planos aceitos, responder as dúvidas que travam a primeira mensagem e mostrar onde fica. Doze seções no fim, e cada uma precisando justificar o lugar numa página que ninguém rola duas vezes.

Sem marca, uma foto de 150×150, duas semanas

O projeto começou de quase nada: sem logo, sem paleta, sem tipografia definida, e uma foto de perfil de 150×150. Então a primeira metade do trabalho foi construir aquilo de que o design seria feito — uma passagem de referências visuais, um moodboard, estudos de logo e um guia de estilo com a paleta, o par Cormorant Garamond e Montserrat, e os grids de desktop e mobile. Por baixo, uma rampa de doze passos em areia quente, com aliases semânticos que resolvem em claro e em escuro.

📄12

seções na página

🧱13

componentes de seção próprios

⚙️9

primitivos shadcn por baixo

🎨30

tokens de design autorais

Com o design fechado, marquei o arquivo como liberado para DEV e construí eu mesmo, como export estático em Next.js: treze componentes de seção próprios sobre nove primitivos shadcn, três páginas legais e um 404 próprio. Ele foi publicado na primeira semana, e a segunda semana foi de ajustes e correções que ela pediu. Desenhar e construir a mesma página tem uma vantagem específica, e não é velocidade. É que nada é desenhado sem poder ser construído, e nada é construído abandonando em silêncio o que foi desenhado.

O agendamento é código, não enfeite

O WhatsApp era o caminho de conversão inteiro, o que significa que o problema de design interessante não era o botão — era o que a mensagem já diz quando o aplicativo abre. Quem precisa redigir sozinho a primeira mensagem para uma psicóloga é quem fecha a aba. Então cada ponto de entrada do site abre o WhatsApp com sua própria mensagem pré-escrita, formulada para o lugar de onde a pessoa saiu: sete deep links distintos, quatorze instâncias renderizadas na página publicada.

A minha favorita está no 404, onde a mensagem pré-preenchida não fala de agendamento:

Um link quebrado no site de um consultório é uma pessoa que queria alguma coisa e não conseguiu. Entregar a ela uma frase que descreve a situação real custa uma linha de código e transforma a pior página do site em um ponto de entrada que funciona.

A responsividade foi feita no navegador, não no Figma

A prancheta de mobile no arquivo de design está vazia, e isso não é uma omissão que eu queira esconder — foi assim que este projeto foi feito. A página desktop foi desenhada em fidelidade total e o comportamento responsivo foi escrito direto no código, onde os breakpoints de fato existem; o HTML publicado carrega 177 ocorrências de utilitários responsivos. É um método razoável quando a mesma pessoa desenha e constrói, e um método ruim para entregar a outra pessoa. Em projeto com desenvolvedor separado, a prancheta é desenhada.

O que isto não é

• Não é backend. O arquivo Express do repositório é sobra morta de template e nunca foi publicado; o site é um export estático servido por Apache.
• Não é um site com tema. O arquivo de design resolve um conjunto completo de tokens claro e escuro, mas a página publicada não traz nenhum utilitário de modo escuro e a biblioteca de tema fica sem uso. Foi decisão de escopo sob prazo curto, não funcionalidade.
• Não é análise competitiva. O grande quadro de benchmark do arquivo são dez capturas de tela inteiras lado a lado — referência visual, nada anotado e nada sintetizado.
• Não é um design system de 1.189 tokens. Trinta tokens foram criados para este projeto; o resto daquele número são rampas herdadas que vieram com o arquivo base.
• Não é analytics. Só o Google Tag Manager aparece na página publicada.
• O arquivo base não é meu. Ele veio de um template de curso, que eu tornei pronto para produção com auto-layout e tokenização — e depois virou o arquivo padrão em todo lugar onde trabalhei.

O material que ninguém pediu

Um consultório não para de precisar de coisas quando o site sobe. Junto com o build eu produzi capas de destaques do Instagram, um cartão de visita e um passo a passo de quatro páginas para configurar o e-mail dela no Thunderbird, com mockups de celular anotados. Nada disso estava no escopo. Tudo isso é a diferença entre entregar um site e entregar algo que alguém consegue realmente tocar.

Evidência

O build foi concluído, publicado, e continua inspecionável no meu próprio host. Ele nunca entrou no ar sob o domínio da cliente. As imagens são geradas por IA, ela não quis que representassem o consultório dela, e o domínio raiz acabou estacionado redirecionando para o perfil dela no Google. O projeto não foi pago. Eu tinha pedido fotografias e recebido uma foto de perfil de 150×150, então gerei as imagens em vez de deixar a data de entrega escorrer; ela não aceitou, e a relação terminou ali. O artefato é real e o código é público. A lição vale mais do que o projeto valeu: fotografia hoje é uma precondição que eu resolvo antes de começar, não uma dependência que eu contorno no design.