Kiskadi, sistema de cashback e fidelidade para varejo
A v2 da plataforma tinha sido construída integralmente pela engenharia, sem designer no processo. O resultado era funcional, mas com buracos de UX que, com o crescimento da base de clientes, precisavam ser resolvidos.
O objetivo da v3 era duplo: sanar a dívida técnica de UX acumulada e incorporar novas funcionalidades que o produto demandava para escalar.
A plataforma tem dois perfis principais:
- Lojistas (gestores): acessam o painel web para configurar campanhas, visualizar métricas e gerenciar o programa de fidelidade.
- Colaboradores: usam o PWA (Progressive Web App) para registrar vendas e consultar o saldo de cashback dos clientes na frente do caixa.
Conduzi uma bateria de testes de usabilidade enxuta com aproximadamente 5 usuários, de forma remota e moderada, com foco no fluxo de Fidelidade, a funcionalidade central do produto. O formato reduzido foi intencional: o suficiente para identificar os principais pontos de atrito e orientar as decisões de redesign.
O público é, em sua maioria, pouco familiarizado com ferramentas complexas. Os principais achados foram:
- Os usuários precisam de controle e detalhe, não basta o resultado, eles querem entender cada etapa.
- O conceito de 'cashback por nível' não era compreendido imediatamente. A lógica de premiação progressiva precisava ser explicada visualmente.
- A densidade de informação na v2 gerava sobrecarga cognitiva, os gestores perdiam o fio da navegação.
O engajamento com o projeto me colocou diante de um desafio concreto: a engenharia estava entregando rápido, e o design era o gargalo. Eu precisava aumentar minha velocidade de prototipação sem comprometer a qualidade.
O processo evoluiu em etapas:
- 1
Gherkin como padrão de comportamento
Antes de abrir o Figma, eu escrevia os critérios de aceitação em Gherkin (Given / When / Then). Isso alinhava expectativas com a engenharia e evitava retrabalho, qualquer ambiguidade de fluxo era resolvida em texto, antes de virar tela.
- 2
Figma Make, tentativa e abandono
Tentei usar o Figma Make para acelerar a geração de telas. A experiência foi promissora, mas a cota de tokens foi cortada antes de eu conseguir avançar o suficiente. Descontinuei o uso e busquei outra alternativa.
- 3
Claude Code como ambiente de prototipação
Passei a usar o Claude Code diretamente para gerar interfaces no localhost. Com o design system baseado em shadcn/ui, escolhido justamente pela compatibilidade com ferramentas de IA e MCP -, o nível de refinamento visual e técnico dos protótipos superou minhas expectativas. O que era para ser uma solução temporária virou o núcleo do processo.
- 4
Figma como entregável de hand-off
Com os fluxos validados no protótipo de código, eu levava o resultado de volta ao Figma para documentar, ajustar tokens e gerar os assets para a engenharia. O Figma deixou de ser o espaço de exploração e passou a ser o espaço de formalização.
Kiskadi Portal
Kiskadi Fidelidade
A escolha do shadcn/ui como base do design system não foi arbitrária. A lógica de instalar e adicionar apenas os componentes que realmente vou utilizar, com acesso direto ao código-fonte, tornava a biblioteca ideal para três contextos:
- Compatibilidade com IA: componentes com estrutura semântica clara são mais previsíveis para ferramentas como Claude Code, que os interpreta e expande corretamente.
- Compatibilidade com MCP: o Figma MCP consegue mapear os componentes com mais precisão quando eles seguem convenções conhecidas.
- Flexibilidade: como o código é seu, o design system cresce conforme o produto, sem depender de atualizações de terceiros.
O sistema foi construído progressivamente ao longo do projeto, com tokens de cor, tipografia, espaçamento e padrões de componentes estabelecidos a partir das necessidades reais de cada feature.
A v3 reorganizou a arquitetura de informação da plataforma, com foco em clareza hierárquica e densidade controlada. As principais intervenções foram:
- Fluxo de Fidelidade redesenhado com visualização progressiva dos níveis de cashback, o usuário agora entende a lógica sem precisar de explicação verbal.
- Dashboard do lojista reorganizado por prioridade de decisão, com métricas principais em destaque e dados secundários acessíveis sob demanda.
- Design system documentado e escalável, permitindo que a engenharia implemente novas features com consistência.
Telas da v3
Metas
Métricas
Logs
Comparativo v2 → v3
v2
v3
✅ O que deu certo
- O Gherkin como ponto de partida eliminou retrabalho de fluxo, a engenharia e o design chegavam à mesma conversa perfeitamente alinhados, evitando processos de retrabalho.
- O Claude Code se provou um ambiente de prototipação de alta fidelidade. O nível de refinamento visual e técnico superou qualquer expectativa que eu tinha com ferramentas de geração de UI.
- A escolha do shadcn/ui foi estratégica: a biblioteca cresceu com o produto sem atrito.
🧐 O que melhorar
- Ampliar a base de testes de usabilidade - 5 usuários deram uma direção boa, mas alguns fluxos secundários ficaram sem validação qualitativa.
- Documentar as decisões de design ao longo do processo, não só no hand-off. Algumas escolhas que faziam sentido na prototipação perderam contexto ao chegar no Figma.
Você chegou no final :)