// case · 757-station
757 Station
Plataforma B2B para gestão de design systems com motor de IA embutido. Arquitetura dual-persona que elimina o handoff manual e garante consistência na geração de código.
O problema
Em uma holding que entrega produtos digitais em ritmo constante, o caos visual era inevitável. Cada novo projeto nascia com sua própria paleta, sua própria tipografia, sua própria convenção de componente. A dívida visual acumulava mais rápido do que conseguíamos pagar feature a feature.
Mas o problema real não era inconsistência visual: era o abismo entre quem projeta e quem constrói.
Designers trabalham com hex codes, moodboards e semântica visual. Desenvolvedores (e vibe-coders usando IA) precisam de variáveis CSS, componentes escaláveis e regras lógicas estritas. Sem uma ponte entre os dois mundos, o código gerado por IA simplesmente não respeitava a identidade da marca. Cada nova tela era uma aposta.
O 757 Station nasceu para fechar esse gap de uma vez.
A estratégia de produto
Diferencial: AI Prompt Engine
A maioria das ferramentas de design system armazena guidelines de marca. O 757 Station vai além: ele tem um motor de IA embutido (prompt-architect.ts) que compila prompts ultra-contextualizados a partir das decisões do designer.
O valor real para clientes B2B não é ter um manual de marca online. É conseguir que IAs codifiquem telas perfeitas na primeira tentativa, sem corrigir cores, fontes ou espaçamentos depois.
O designer aprova o visual. O sistema trava as variáveis. A IA recebe o contexto técnico completo e entrega código que já nasce dentro do design system.
Arquitetura Dual-Persona
A decisão mais arriscada (e mais recompensadora) foi recusar criar uma interface que tentasse agradar todo mundo ao mesmo tempo.
Duas personas usam a plataforma com objetivos completamente opostos:
| Persona | Perfil | O que importa |
|---|---|---|
| Designer Gráfico | Acostumado com Figma e Illustrator | Paletas, referências visuais, escalas tipográficas |
| Vibe-Coder / Dev | Foco técnico | Tokens, componentes (Radix/shadcn), exporters, configurações de infra |
A regra foi clara: o que pertence a uma persona jamais aparece na tela da outra. A plataforma opera no background como tradutor universal entre os dois mundos.
Stack tecnológica
| Camada | Tecnologia | Decisão |
|---|---|---|
| Frontend | React 18 + Vite + Tailwind 4 | Máxima flexibilidade e performance |
| Backend & Infra | Supabase (PostgreSQL + Edge Functions) | Dados relacionais + serverless sem overhead |
| Auth & Segurança | Row Level Security (RLS) | Isolamento total entre Workspaces e Projetos |
| AI Engine | prompt-architect.ts | Compilação de prompts a partir dos tokens da marca |
Decisões de UX
Estruturei cada decisão de design cruzando com as heurísticas de Nielsen, não como exercício acadêmico, mas como ferramenta de argumento interno.
| Heurística | Decisão de design | Resultado prático |
|---|---|---|
| H4: Consistência e padrões | Zero cores hardcoded. Toda a interface consome variáveis CSS. Tipografia com tamanhos mínimos travados na arquitetura | O dev sabe que não existe exceção visual que quebre o código |
| H5: Prevenção de erros | Cores primárias e tipografias base tratadas como dados críticos. Alterações profundas exigem Double-Check Modals. Regras WCAG embutidas no sistema | Um clique acidental não quebra o design system da empresa |
| H8: Estética minimalista | Dark Mode default com glassmorphism. Tokens transparentes (--glass-bg, --glass-border-hover) criam hierarquia espacial sem peso visual | A interface sai do caminho; a identidade do cliente é a protagonista |
| H3: Controle e liberdade | PillTabNav com animações via Motion One que retêm o estado do usuário | O usuário alterna entre configurar tipografia e testar prompts sem perder o raciocínio |
As 4 camadas do sistema
A entrega final foi uma árvore de design organizada em camadas com dependência explícita:
- Tokens: cor, spacing, radius, motion, tipo. Os valores base de tudo.
- Primitivos: wrappers tipados sobre shadcn (Button, Input, Dialog, Tooltip). Nenhum componente do app toca o shadcn diretamente.
- Componentes: composições com intenção de produto (DocumentCard, UnitList, StageStepper).
- Padrões: receitas citáveis: formulário com validação, lista filtrada, detalhe com sidebar.
Cada camada tem docs MDX com exemplos executáveis e contra-exemplos ("não faça isso porque..."). Qualquer dev pode propor mudança via PR; alteração de token aciona review obrigatório.
Resultados
Fim das "alucinações" de UI. Com prompts contextualizados nos tokens da marca, IAs como Claude e Cursor geram componentes que respeitam 100% o design system na primeira tentativa.
Handoff manual zerado. O processo de documentar espaçamentos, regras de cor e fontes manualmente foi eliminado. Designer aprova o visual, sistema trava as variáveis.
Governança que escala. Times maiores conseguem colaborar no mesmo projeto sem risco de sobreposição. A estrutura de Workspaces combinada com os modais de prevenção de erro torna isso possível mesmo com devs juniores no time.
Aprendizado
O 757 Station me ensinou que a melhor UX muitas vezes não é a interface visual: é a arquitetura de informação por trás dela.
Ao abraçar a fricção real entre designers e desenvolvedores, e ao invés de criar uma ferramenta "tamanho único", separar os dois perfis em ecossistemas próprios provou que empatia em design de produto significa dar às pessoas exatamente o que precisam para ter sucesso. Nem mais, nem menos.
O produto deixou de ser um repositório B2B e virou o cérebro que opera a padronização visual na era da programação via IA.