KaBuM!GG: a plataforma que não foi pro ar mas mudou como a empresa faz design KaBuM!GG: the platform that never shipped but changed how the company does design

Quando entrei no KaBuM! em 2022, a empresa já tinha uma presença forte no universo gamer: patrocínio de times de e-sports, uma base de clientes apaixonada por tecnologia, e o KaBuM!GG — um site voltado para a comunidade gamer que existia de forma básica, quase como uma landing page glorificada.

A liderança viu uma oportunidade: e se o KaBuM!GG deixasse de ser um site e se tornasse uma plataforma de verdade? Uma ferramenta de campeonatos online onde jogadores de Valorant, League of Legends, CS, Street Fighter, FIFA e outros títulos pudessem se cadastrar, participar de torneios promovidos pelo KaBuM!, acompanhar resultados, e fazer parte de uma comunidade competitiva. Além dos campeonatos, a plataforma exibiria produtos exclusivos com assinatura KaBuM!GG e Husky, criando um ecossistema que conectava competição, comunidade e comércio.

Fui escalado como ponto focal de design. O time incluía desenvolvedores, um arquiteto de software e um PO. Minha responsabilidade: discovery, definição visual, prototipação de toda a experiência, e — o que acabou sendo a decisão mais importante — a criação de um Design System para sustentar o projeto.

Transformar um site simples em uma plataforma complexa trazia problemas reais de design:

Públicos muito diferentes num mesmo produto. De um lado, jogadores casuais que nunca participaram de um torneio. Do outro, competidores hardcore que vivem de campeonato. A interface precisava ser acessível para quem estava começando, mas completa o suficiente para quem já sabia exatamente o que queria.

Uma identidade visual que precisava existir sem conflitar com o KaBuM! principal. O KaBuM!GG tinha que ser reconhecível como parte do ecossistema KaBuM!, mas com personalidade própria — mais gamer, mais competitivo, mais comunidade. Definir essa linha foi um exercício constante de equilíbrio.

Escala desde o dia zero. Não era um MVP descartável. Campeonatos têm datas, inscrições, brackets, resultados em tempo real. A plataforma precisava ser robusta desde o lançamento. E para um produto dessa complexidade, sem um sistema de design, cada tela seria uma improvisação.

Comecei mapeando o cenário competitivo: como plataformas como FACEIT, Battlefy e Challengermode resolviam os mesmos problemas. O que funcionava, o que era confuso, onde havia oportunidade de diferenciação. O KaBuM! tinha algo que nenhuma dessas plataformas tinha: uma marca com significado emocional para o público gamer brasileiro e um e-commerce por trás para monetizar.

A partir desse mapeamento, defini a arquitetura de informação e os fluxos principais: cadastro, inscrição em campeonatos, acompanhamento de brackets, perfil do jogador, e a vitrine de produtos exclusivos.

Logo no início percebi que construir tela por tela sem um sistema seria suicídio. O KaBuM!GG tinha dezenas de estados diferentes: campeonato aberto, em andamento, finalizado. Jogador inscrito, em partida, eliminado, campeão. Produto disponível, esgotado, exclusivo para membros. Cada combinação gerava uma interface diferente. Sem padrões, o caos era inevitável.

Propus e implementei o Design System do projeto. Foi a primeira vez que tive a oportunidade de montar um DS de verdade dentro do KaBuM!, e investi pesado:

Tokens de design usando Figma Variables e Modes: cores, espaçamento, tipografia, sombras, bordas. Tudo parametrizado para que uma mudança de token propagasse automaticamente por toda a interface.

Componentes documentados com propriedades, estados, variantes e dependências claras. Cada componente tinha sua documentação explicando quando usar, como usar, e o que não fazer.

Colaboração com engenharia através de Storybook: cada componente que eu desenhava no Figma tinha sua contrapartida implementada e documentada no Storybook, garantindo paridade visual entre design e código.

Protótipos navegáveis que serviam tanto para validação com stakeholders quanto como referência de interação para o time de desenvolvimento.

O KaBuM!GG precisava de uma identidade que dissesse "gaming competitivo" sem parecer genérico. Trabalhei na definição de estilos visuais, padrões de comunicação com o público, e personalização — funcionalidades que permitiam ao jogador sentir que a plataforma era "dele".

A paleta de cores era mais escura e vibrante que o KaBuM! e-commerce. A tipografia era mais bold, mais assertiva. Os componentes tinham feedback visual mais agressivo — animações de transição, estados de loading com personalidade, e um sistema de notificações que deixava claro quando algo importante estava acontecendo no seu campeonato.

O projeto foi implementado parcialmente. Partes da plataforma chegaram a estar funcionais. Mas por decisão estratégica da empresa, o KaBuM!GG não seguiu adiante na forma que havíamos projetado.

Esse é o tipo de coisa que acontece em produto. Nem tudo que é bem desenhado e bem construído vai pro ar. Prioridades mudam, estratégias mudam, e faz parte da maturidade profissional aceitar isso e extrair valor do que foi feito.

E aqui está o plot twist: o projeto não foi adiante, mas o que eu construí dentro dele transformou a forma como o KaBuM! inteiro faz design.

O Design System que criei para o KaBuM!GG foi o primeiro DS estruturado da empresa. Os aprendizados — tokens parametrizados, documentação de componentes, colaboração via Storybook, governança de uso — se tornaram a base conceitual do que hoje é o DS.Sensei, o Design System do e-commerce principal do KaBuM!.

O DS.Sensei não é uma cópia do que fiz no GG. É uma evolução. Mas a semente foi plantada ali: a prova de que um Design System funciona, que acelera entregas, que reduz inconsistências, e que vale o investimento. Sem o KaBuM!GG, provavelmente eu não teria tido a oportunidade de demonstrar esse valor e promover o conceito para o produto principal da empresa.

Projetos que "não dão certo" ainda dão certo. O KaBuM!GG me ensinou que o valor de um projeto não está só no que vai pro ar. O processo, os padrões, os sistemas que você constrói ao longo do caminho podem ter impacto muito maior do que a feature que motivou a sua criação.

Design System não é documentação. É cultura. Criar um DS é fácil. Convencer um time inteiro a usar, manter e evoluir é o trabalho de verdade. O GG me deu a primeira oportunidade de fazer isso, e os erros que cometi lá me prepararam para fazer melhor no DS.Sensei.

O designer precisa vender a ideia, não só a interface. Se eu tivesse apenas desenhado as telas do KaBuM!GG sem propor e defender o Design System, o legado teria morrido junto com o projeto. A habilidade de articular por que algo importa — para stakeholders, para engenharia, para o negócio — é tão importante quanto saber projetar a interface.

When I joined KaBuM! in 2022, the company already had a strong presence in the gaming universe: e-sports team sponsorships, a customer base passionate about technology, and KaBuM!GG — a gaming community website that existed in a basic form, almost like a glorified landing page.

Leadership saw an opportunity: what if KaBuM!GG stopped being a website and became a real platform? A competitive tournament tool where players of Valorant, League of Legends, CS, Street Fighter, FIFA, and other titles could register, join KaBuM!-promoted tournaments, follow results, and be part of a competitive community. Beyond tournaments, the platform would showcase exclusive products under the KaBuM!GG and Husky brands, creating an ecosystem connecting competition, community, and commerce.

I was brought in as the design lead. The team included developers, a software architect, and a PO. My responsibility: discovery, visual direction, prototyping the entire experience, and — what turned out to be the most important decision — building a Design System to support the project.

Transforming a simple website into a complex platform brought real design problems:

Very different audiences in the same product. On one side, casual gamers who'd never joined a tournament. On the other, hardcore competitors who live for championships. The interface had to be approachable for beginners yet comprehensive enough for those who knew exactly what they wanted.

A visual identity that needed to exist without conflicting with the main KaBuM! brand. KaBuM!GG had to be recognizable as part of the KaBuM! ecosystem while having its own personality — more gaming, more competitive, more community-driven. Finding that balance was a constant exercise.

Scale from day one. This wasn't a throwaway MVP. Tournaments have dates, registrations, brackets, real-time results. The platform had to be robust from launch. And for a product of this complexity, without a design system, every screen would be improvisation.

I started by mapping the competitive landscape: how platforms like FACEIT, Battlefy, and Challengermode solved the same problems. What worked, what was confusing, where differentiation was possible. KaBuM! had something none of these platforms had: a brand with emotional significance for the Brazilian gaming community and an e-commerce engine behind it for monetization.

From this mapping, I defined the information architecture and key flows: registration, tournament enrollment, bracket tracking, player profiles, and the exclusive products showcase.

Early on, I realized that building screen by screen without a system would be unsustainable. KaBuM!GG had dozens of different states: tournament open, in progress, finished. Player registered, in match, eliminated, champion. Product available, sold out, members-only. Each combination generated a different interface. Without standards, chaos was inevitable.

I proposed and built the project's Design System. It was the first time I had the opportunity to create a proper DS within KaBuM!, and I invested heavily:

Design tokens using Figma Variables and Modes: colors, spacing, typography, shadows, borders. Everything parameterized so that a single token change would automatically propagate across the entire interface.

Documented components with clear properties, states, variants, and dependencies. Each component had documentation explaining when to use it, how to use it, and what not to do.

Engineering collaboration through Storybook: every component I designed in Figma had its counterpart implemented and documented in Storybook, ensuring visual parity between design and code.

Navigable prototypes that served both for stakeholder validation and as interaction references for the development team.

KaBuM!GG needed an identity that said "competitive gaming" without looking generic. I worked on defining visual styles, communication patterns, and personalization features that made players feel the platform was "theirs."

The color palette was darker and more vibrant than KaBuM!'s e-commerce. Typography was bolder, more assertive. Components had more aggressive visual feedback — transition animations, loading states with personality, and a notification system that made it clear when something important was happening in your tournament.

The project was partially implemented. Parts of the platform were functional. But due to a strategic company decision, KaBuM!GG didn't move forward in the way we had designed it.

This is the kind of thing that happens in product work. Not everything that's well-designed and well-built ships. Priorities change, strategies change, and accepting that and extracting value from what was built is part of professional maturity.

And here's the plot twist: the project didn't ship, but what I built inside it transformed how the entire company does design.

The Design System I created for KaBuM!GG was the company's first structured DS. The learnings — parameterized tokens, component documentation, Storybook collaboration, usage governance — became the conceptual foundation of what is now DS.Sensei, the Design System for KaBuM!'s main e-commerce platform.

DS.Sensei isn't a copy of what I built for GG. It's an evolution. But the seed was planted there: proof that a Design System works, that it accelerates delivery, reduces inconsistencies, and is worth the investment. Without KaBuM!GG, I probably wouldn't have had the opportunity to demonstrate that value and promote the concept to the company's main product.

Projects that "don't work out" still work out. KaBuM!GG taught me that a project's value isn't only in what ships. The process, the standards, the systems you build along the way can have a far greater impact than the feature that motivated their creation.

A Design System isn't documentation. It's culture. Creating a DS is easy. Convincing an entire team to use, maintain, and evolve it is the real work. GG gave me the first opportunity to do this, and the mistakes I made there prepared me to do it better with DS.Sensei.

Designers need to sell the idea, not just the interface. If I had only designed KaBuM!GG's screens without proposing and championing the Design System, the legacy would have died with the project. The ability to articulate why something matters — to stakeholders, to engineering, to the business — is as important as knowing how to design the interface.