2P Web Dev - Case de Produto | Floriano Silva Designer

Produto Digital Interno

Web Dev 2.0

De uma planilha pública com dados sensíveis de clientes a uma plataforma interna segura, personalizada e adotada espontaneamente pelo time.

Resumo

A Dois Palitos guardava dados sensíveis de dezenas de clientes em uma planilha do Google Sheets com link público ativado. Qualquer pessoa com o link conseguia ver tudo. Sem login, sem rastreamento, sem nenhuma barreira.

Todo mundo no time sabia que a planilha estava ruim. Mas a agência não parava: clientes para atender, projetos para entregar. Resolver a infraestrutura interna ficava sempre para depois.

Decidi gastar meu tempo livre nisso. Proativamente, sem que ninguém pedisse. Não havia engenheiro de software na equipe, então usei o Claude AI como ferramenta de desenvolvimento, apoiado no conhecimento técnico que tenho de servidores e infraestrutura, adquirido na graduação em Segurança da Informação. O resultado foi um sistema personalizado, em produção, com adoção imediata e espontânea.

Autor
Floriano Silva – Product Designer

Empresa
Dois Palitos Growth | doispalitosmkt.com.br

Papel

Líder do projeto (discovery, definição de produto, prototipagem, decisões técnicas e coordenação do desenvolvimento via IA)

Função

Líder do projeto (discovery, definição de produto, prototipagem, decisões técnicas e coordenação do desenvolvimento via IA)

Ferramentas

Figma · Bit System · Claude AI · PHP · MySQL · Hostinger

Duração

Beta: 1 a 2 semanas. Ciclo de iteração e v2: 1 a 2 semanas adicionais

Adoção

100% do time ativo no sistema desde o primeiro dia

O Problema

O que a planilha guardava

Era a memória operacional do time de Web Dev. Senhas de WordPress, cPanel, servidor e e-mail de todos os clientes. Além dos protocolos técnicos e das senhas internas da agência.

Link público ativado. Qualquer pessoa na internet, com o link, podia ver tudo. Sem precisar fazer login, sem deixar rastro.

O problema que não aparece na superfície

Além da exposição, havia um segundo problema mais silencioso: a carga cognitiva.

Abrir a planilha custava mentalmente. O time sabia o que esperava:

Rolar centenas de linhas, filtrar colunas sem título claro
Tentar lembrar em qual aba estava a informação certa.
Não havia hierarquia.
Tudo estava no mesmo nível, com o mesmo peso visual.
Senhas ao lado de URL de domínio ao lado de nota interna, sem separação, sem contexto.

Era o tipo de ferramenta que ninguém queria abrir. E conforme a agência crescia, isso só piorava.

Problema de UX	Como se manifestava	Como o sistema resolve
Ausência de hierarquia	Todos os dados no mesmo nível visual (senha, servidor, URL, nota) sem distinção de importância	Ficha por cliente com seções agrupadas: e-mail, domínio, servidor, WordPress
Carga cognitiva alta	Para achar uma informação, o usuário precisava lembrar em qual coluna ela estava	Busca com autocomplete + ficha fixa por cliente — a informação sempre está no mesmo lugar
Erro humano facilitado	Uma linha errada editava o cliente errado sem nenhuma fricção	Cada cliente tem tela própria. Editar exige navegação intencional

O Alternativas Consideradas

Opção	Prós	Contras	Decisão
1Password	Solução robusta para senhas	Custo de assinatura. Sem personalização para protocolos, logs por cliente ou fluxos específicos da agência	Descartado
Notion	Personalizável e flexível	Custo de assinatura. Risco de segurança por ser plataforma externa	Descartado
Build com IA	Custo zero, 100% personalizado para a 2P. Permite testar o Claude como ferramenta de desenvolvimento	Sem engenheiro de software na equipe, depende da qualidade das decisões de produto e da IA	Escolhido

Construir ou comprar? A ideia nunca foi fazer o time aprender uma plataforma nova. Era construir algo feito para a 2P, não para uma agência genérica. Com os fluxos, as permissões e a linguagem correta. Ferramentas prontas não entregariam isso.

Design e Prototipagem

Figma e Bit System

Antes de qualquer linha de código, criei um protótipo no Figma para validar fluxos e hierarquia de informações. A identidade visual foi construída sobre o Bit System, o Design System que desenvolvi para a Dois Palitos, garantindo consistência desde o início sem decisões arbitrárias de estilo.

Decisões de navegação

O fluxo principal foi desenhado para ter fricção zero no uso mais comum: encontrar as informações de um cliente.

Fluxo Principal Início > campo de busca com autocomplete > ficha do cliente > dado copiado com um clique.Quatro passos, zero cliques desnecessários.

A segunda decisão foi separar visualização de edição. O colaborador nunca vê um botão de editar. Não há risco de alteração acidental. O admin edita de forma deliberada, não por engano. Essa separação também reduziu a ansiedade de uso para quem não tem perfil técnico: ver a tela e entender o que pode e o que não pode fazer.

Estados e casos de borda

Alguns detalhes que parecem pequenos, mas que definem a qualidade percebida:

Estado vazio na busca: quando nenhum cliente é encontrado, a tela não quebra. Exibe mensagem clara e botão de cadastro, visível só para admin.
Senha mascarada com intenção: o campo não revela a senha por hover ou foco, só por clique explícito no ícone. Exposição sempre intencional.
Feedback de ação: copiar uma credencial dispara um toast de confirmação. O usuário sabe que funcionou sem precisar conferir.
Sessão expirada: em vez de uma tela de erro genérica, redireciona para o login com mensagem explicativa.
Gamificação nos protocolos: barra de progresso por cliente, percentual de conclusão visível e animação de confetes ao atingir 100%. O objetivo era tornar o acompanhamento algo que o time quisesse fazer, não uma obrigação.

Decisões técnicas com impacto direto em UX

Decisão	Raciocínio	Impacto em UX
Dois perfis distintos	Refletia como o trabalho estava organizado na prática: quem edita e quem executa	Colaborador nunca se perde em funções que não são suas. Admin tem controle total sem fricção
Busca com autocomplete	Com 88 clientes, rolar uma lista é ineficiente	Tempo de busca de ~2 a 3 min na planilha para ~10 segundos no sistema
Tela individual por cliente	Eliminar a confusão de linhas e colunas	Redução drástica de erros de alimentação. Cada informação tem seu lugar fixo
Log de auditoria	Rastreabilidade é parte do produto, não um extra	Time sabe o que foi feito, por quem e quando. Sem dependência de memória

Desenvolvimento com IA

O desenvolvimento técnico foi viabilizado com o Claude AI como ferramenta de implementação. O papel de produto foi inteiramente meu: identificar o problema, levantar os requisitos, definir os fluxos, tomar as decisões de UX e conduzir as iterações com base no feedback real da equipe.

Limitação honesta do modelo Sem um engenheiro de software na equipe, algumas decisões técnicas foram tomadas com base no que a IA sugeria, não com base em revisão humana especializada. Isso funcionou bem para a maior parte do sistema, mas é uma limitação real; especialmente em aspectos de segurança mais avançados, que entrarão na próxima iteração com mais cuidado assim que possível.

Beta, Feedback e Iteração

A v1 como hipótese

A v1 foi lançada como hipótese, não como produto final. O sistema ficou em uso por uma a duas semanas. Durante esse período, coletei feedback qualitativo diretamente de quem estava usando: atendimento e marketing e gerência.

O que deu errado na v1

Nem tudo funcionou de primeira.

O horário no log de atividades estava errado desde o início. O servidor rodava em UTC e o sistema não fazia a conversão para o fuso brasileiro. Parecia um detalhe, mas comprometia a credibilidade do log: como confiar em uma auditoria com horários errados?

O dashboard mostrava 1.513 protocolos pendentes. O número assustou a gerência. Eram clientes inativos sendo contados junto com os ativos. Um bug de query que distorcia completamente a leitura do progresso do time.

Esses dois problemas foram identificados em menos de uma semana de uso real. Nenhum teria aparecido em testes simulados.

O que o feedback gerou na v2

Tipo	Feedback	Decisão tomada	Impacto
Bug	Clientes inativos contados nos pendentes	Query corrigida para filtrar apenas clientes ativos	Número de pendentes passou a refletir a realidade
Bug	Horário incorreto no log	Fuso horário forçado no banco de dados	Log passou a exibir o horário correto de Brasília
Bug	Sem opção de alterar perfil pela interface	Botão de alternar perfil adicionado na gestão de usuários	Operação que exigia acesso ao banco virou 1 clique
Feature	Time queria ver cobertura de protocolo entre todos os clientes	Criada tela de Panorama por Ferramenta	Visibilidade estratégica: quantos clientes têm cada protocolo concluído
Feature	Precisava adicionar protocolos sem atualizar cliente por cliente	Criada Gestão Global com propagação automática	Novo protocolo propagado para todos os clientes ativos de uma vez

Resultado

Métrica	Antes	Depois
🔒 Exposição de dados sensíveis	100% público. Qualquer pessoa com link via tudo	100% restrito. Acesso apenas por login autenticado
⏱️ Tempo de busca de informação	~2 a 3 min (rolar, filtrar, localizar na planilha)	~10 seg (autocomplete, abrir ficha) — redução de ~60%
⚠️ Risco de erro de alimentação	Alto. Linhas e colunas sem estrutura visual clara	Baixo. Tela própria por cliente, campos fixos e com contexto
🧠 Carga cognitiva de uso	Alta. Usuário precisava lembrar onde cada dado estava	Baixa. Hierarquia visual clara, busca inteligente, navegação previsível
👥 Adoção do time	Planilha aberta com resistência mental	100% do time ativo desde o primeiro dia, sem fricção
📋 Rastreabilidade de ações	Zero. Sem histórico de quem editou o quê	Log completo: usuário, ação, data e hora de tudo

Feedback direto do time AS equipes de marketing, atendimento e gerência disseram que o sistema estava muito fácil de usar. Antes, abrir a planilha era mentalmente cansativo. Com o sistema, essa fricção desapareceu. A gamificação funcionou: ver o progresso por cliente criou engajamento real com os protocolos, algo que antes simplesmente não existia.

Segurança

O sistema tem segurança real agora:

Senhas de login criptografadas com bcrypt (cost 12) — algoritmo robusto e amplamente adotado para autenticação
Controle de sessão com timeout automático de 4 horas — sessão expirada automaticamente por inatividade
Log de auditoria completo — toda ação registrada com usuário, IP, data e hora
Backup diário automático — via Cron Job da Hostinger, com retenção dos últimos 30 dias
HTTPS com SSL ativo — tráfego criptografado entre o navegador e o servidor
Controle de perfis verificado server-side — permissões validadas no servidor, não apenas no frontend

Limitação conhecida e próximo passo As credenciais dos clientes (senhas de WordPress, cPanel, etc.) estão armazenadas em texto simples no banco de dados. É uma limitação real. A próxima iteração prevê criptografia AES-256 para esses campos. Mesmo assim, esses dados só são acessíveis por usuários autenticados, com log de cada acesso e backup diário.

Aprendizados

Lançar como hipótese funciona. A v1 foi deliberadamente simples. O feedback real do time valeu mais do que qualquer especificação prévia.
Resistência existe e é legítima. O time sabia do problema mas não tinha espaço para resolvê-lo. Tomar a iniciativa sozinho foi o que desbloqueou o projeto.
IA como ferramenta de produto é viável agora. A qualidade do output é proporcional à qualidade da especificação. O processo de produto precisa existir antes.
Carga cognitiva é tão crítica quanto segurança. Resolver o acesso não autenticado era urgente. Mas resolver a experiência de uso foi o que gerou adoção real.
Personalização vence generalização. Ferramentas prontas existiam. Nenhuma delas seria a 2P.