G-Storm

A G-Storm é uma marca brasileira de hardware gamer, com produtos como gabinetes, water coolers, fontes e kits fan, que entrou no mercado sem base de clientes, sem histórico de comportamento de navegação e sem um produto anterior para iterar. Fui responsável por desenhar a experiência de compra do zero: da arquitetura de categorias ao design de interface, passando pela implementação em front-end com apoio de IA no processo, construindo o produto em paralelo ao lançamento da própria marca.

Diferente dos outros projetos deste portfólio, aqui não havia analytics, não havia clientes recorrentes nem uma versão anterior do produto para melhorar. O desafio era duplo: primeiro, tomar decisões de UX sem a fonte de verdade mais comum de um product designer, que é o comportamento real do usuário; segundo, construir confiança para uma marca desconhecida em um mercado dominado por nomes estabelecidos, onde o comprador de hardware pesquisa compatibilidade técnica de forma exaustiva antes de decidir. Interface bonita não basta quando a marca ainda não tem reputação para sustentar a decisão de compra.

Sem uma base própria para pesquisar, substituí a pesquisa tradicional por fontes indiretas de sinal, no que chamo de pesquisa por proxy:

• Benchmark competitivo aprofundado com seis concorrentes diretos (fluxo de compra, arquitetura de categoria, ficha técnica, política de garantia)
• Mapeamento de reclamações recorrentes em reviews públicos de concorrentes, com dores como "não sabia se cabia no meu gabinete" e "ficha técnica incompleta"
• Entrevistas com o time comercial que já respondia dúvidas técnicas de compradores de hardware em outros canais
• Leitura ativa de comunidades e fóruns de montagem de PC para entender vocabulário e critérios reais de decisão de compra

Esses sinais foram consolidados em uma proto-persona: uma hipótese estruturada de usuário, não uma persona validada com entrevistas próprias, e tratada como tal em todo o processo.

Organizei a navegação em torno de como o comprador de hardware pensa, por categoria de componente (gabinetes, kit fans, fontes, water cooler, air cooler), não por coleção ou campanha. A ficha de produto priorizou compatibilidade e especificação técnica acima de elementos puramente visuais, e o fluxo de checkout foi reduzido ao mínimo de etapas possível: sem histórico de marca para sustentar fricção extra, cada passo a mais era risco de abandono.

Na página de produto, o wireframe já nasceu com um módulo que não existia na estrutura original: um bloco de compatibilidade rápida logo abaixo do título, com os limites de GPU, cooler, fonte e water cooler visíveis antes de qualquer descrição longa, o ponto de maior atrito identificado na etapa de descoberta.

Antes de qualquer linha de código, validei as decisões mais arriscadas com métodos que não dependem de uma base de clientes existente:

• Teste de 5 segundos com gamers reais fora da base, para medir primeira impressão de marca e clareza da proposta de valor
• Tree testing para validar se a estrutura de categorias fazia sentido antes de desenhar qualquer tela
• Teste guiado do protótipo navegável com voluntários da empresa, observando onde travavam ao tentar "comprar" um gabinete compatível em um cenário fictício

Nenhum desses métodos substitui dados reais de uso, mas reduziram o risco das decisões mais caras (arquitetura, fluxo de compra, primeira impressão) antes de existir um único usuário real para errar com elas.

O direcionamento visual buscou equilibrar a agressividade típica da estética gamer, com preto, vermelho e acentos RGB, com legibilidade e confiança: um equilíbrio delicado para uma marca sem histórico, já que visual demais sem clareza reforça a desconfiança do comprador técnico. Tipografia condensada e bold para títulos, hierarquia clara para especificações técnicas, e uso de RGB limitado a elementos de destaque, não à interface inteira.

A implementação em front-end também fez parte do escopo do projeto. Usei o Claude Code para acelerar o primeiro momento de codificação: estrutura HTML, organização dos componentes em CSS e a base das interações em JavaScript, seguindo o design system definido no Figma. A partir dessa primeira versão, entrei manualmente no código para revisar, ajustar detalhes de acabamento e refinar interações que a IA não capturou com precisão, como microanimações, estados de hover e o comportamento responsivo em telas menores.

Nesse projeto, IA aplicada ao processo significou ganhar velocidade na primeira versão do código, sem abrir mão da revisão humana no resultado final.

Como o produto foi ao ar sem histórico, não havia uma baseline para medir "melhoria": o critério de sucesso mudou de quanto melhorou para o que vamos aprender primeiro. Antes do lançamento, defini os sinais que orientariam a primeira rodada de iteração:

*Como o projeto foi lançado sem base histórica de usuários, os números acima representam metas de design e decisões de instrumentação definidas antes do lançamento, não resultados de A/B test.

Projetar um produto do zero, sem usuários, não significa projetar no escuro: significa trocar a fonte da verdade. Benchmark, proxies de comportamento e testes com não-clientes não substituem dados reais, mas reduzem o risco das decisões mais caras antes que existam usuários reais para errar com elas. A lição mais clara ficou para depois do lançamento: instrumentar tudo desde o dia 1, porque a pesquisa "de verdade" só começa quando os primeiros usuários chegam.

O mesmo raciocínio valeu para o código. Usar o Claude Code para ganhar velocidade na primeira versão do front-end não eliminou a etapa de revisão, apenas mudou onde o meu tempo era investido: menos na digitação de HTML, CSS e JavaScript, mais no refinamento de detalhes, interações e no julgamento de o que ficava e o que precisava ser reescrito.