Kanguro Counter APP — Scanner

Projetar uma ferramenta de logística para pessoas que nunca tinham tocado num computador.

Função Product Designer
Ano 2023
Tipo Startup · Equipa internacional 🇪🇸 🇩🇪 🇮🇳 🇸🇾
Plataforma iOS · Android
Ferramentas
Figma Material Design 3 React Native Paper Firebase Crashlytics
Transportadoras integradas
Amazon UPS GLS Ontime Paack
Ver protótipo no Figma
Kanguro Counter App em uso num Kanguro Point
+2.700 Kanguro Points ativos em Espanha, Portugal e Alemanha
2.900 utilizadores ativos mensais
99,9% sem crashes no Android

Desafio

Logística para pessoas que nunca tinham tocado num computador

O Kanguro liga grandes transportadoras — Amazon, UPS, GLS, Ontime, Paack — a uma rede de comércios locais onde os clientes levantam as suas encomendas. Alguém tem de gerir essas encomendas em cada ponto, e essa pessoa é o dono de uma papelaria ou de um cabeleireiro que nesse dia também tem de atender clientes, fechar a caixa e gerir o negócio. O produto foi desenvolvido inteiramente em inglês: a equipa de engenharia estava distribuída entre a Síria, a Índia e a Alemanha, e o inglês era a única língua comum. Por isso os ecrãs estão em inglês. Havia uma app em produção. Funcionava. Mas os kounters — os funcionários dos pontos — digitalizavam encomendas sem saber ao certo o que estavam a fazer.

O desafio não era apenas de UI. Era de compreensão: fazer com que alguém sem contexto logístico execute corretamente, sem erros, com um cliente à espera ao lado.

Investigação

Antes de abrir o Figma, fui aos pontos

Visitei comércios com e sem experiência logística prévia. A diferença era notável: os primeiros entendiam o vocabulário; os segundos precisavam que tudo fosse autoexplicativo. Observei como trabalhavam e conduzi duas rondas de entrevistas — uma para entender o contexto, e uma segunda já com uma primeira versão desenhada, para recolher feedback direto sobre a app.

Observação em campo

Visitei os pontos sem intervir. Observei como os kounters processavam encomendas reais, onde ficavam bloqueados, o que ignoravam e o que consultavam com os colegas. Sem guião, sem perguntas — primeiro perceber, depois perguntar.

Entrevistas semiestruturadas × 2 rondas

Ronda 1: descoberta contextual — o que entendiam do processo logístico e o que não entendiam. Ronda 2: validação com uma primeira versão desenhada. Dois momentos distintos do projeto, dois objetivos distintos.

Jobs to be Done

O marco que organizou os insights. O job central do kounter: "Quando chega um estafeta ou um cliente, quero registar a operação rápido e sem erros, para poder voltar a atender a minha loja sem ficar com a dúvida de se o fiz bem."

O insight-chave: o problema não era a falta de habilidade. Era a falta de contexto. Um kounter que há vinte anos atende a sua loja consegue aprender qualquer processo — se esse processo estiver explicado na sua linguagem, não na linguagem da logística.

Exploração

O processo começou no papel

Antes de abrir o Figma, precisava de resolver se fazia sentido unificar os diferentes tipos de transação num único ponto de entrada. O sketch de fluxo foi o artefacto mais importante do projeto — o losango de decisão no centro e a anotação "combinar fluxo correto" são o momento exato em que nasceu a lógica da app. Daí passei diretamente para alta fidelidade, documentando cada fluxo completo antes de desenhar ecrã a ecrã.

Sketch em papel do fluxo de digitalização — losango de decisão e anotações
O sketch onde nasceu a lógica de "digitaliza primeiro, decide depois" — o losango de decisão no centro é a solução.

Os fluxos de utilizador são apresentados com detalhe reduzido por acordo de confidencialidade. O conteúdo completo está disponível em conversa direta.

Fluxo Figma "Parcels from DD to Counter" — estados Created, Dropping e Dropped-off
O fluxo principal do estafeta: desde que chega com encomendas até ficarem registadas no counter com validação concluída.
Detalhe do fluxo Counter to Recipient com ramificações por transportadora
O fluxo Counter → Recipient é o mais complexo: a ramificação inferior mostra como o mesmo ecrã de validação gere estados diferentes por transportadora.

Antes · Depois

Antes

A versão anterior partia de uma premissa incorreta: que o kounter já sabia o que estava a fazer quando abria a app. O ecrã inicial pedia para digitalizar sem contexto. O scanner não diferenciava entre receber e entregar. O sistema visual — amarelo intenso, cyan, ilustrações 3D decorativas — priorizava a energia visual sobre a clareza operacional.

Depois

O redesign parte do problema real: orientar o kounter antes de cometer um erro, não depois. Cada ecrã tem uma única pergunta. O sistema visual retira-se para que o conteúdo não tenha concorrência.

Comparação antes/depois da Counter App — fila superior versão antiga em amarelo e cyan, fila inferior versão redesenhada com Material Design 3
Acima: versão anterior — o início apenas dizia "Digitaliza o QR", sem contexto de ação nem transportadora. Abaixo: versão redesenhada com MD3, orientação prévia ao scan e estrutura de passo único.

Decisões de design

Digitaliza primeiro, decide depois

A versão anterior obrigava o kounter a decidir o tipo de transação antes de digitalizar. O problema: muitas vezes não sabiam. Investi a lógica. Digitaliza primeiro. Depois, a app mostra uma confirmação com as opções possíveis nesse contexto: estás a receber esta encomenda do estafeta ou a entregá-la ao cliente? Uma pergunta clara, com ilustrações de cada pessoa, não ícones abstratos.

O kounter já não precisa de perceber de logística para usar a app. Só precisa de saber quem tem à frente.

Fluxo completo de digitalização — lógica invertida
Home · Scanner · Confirmation Overlay — o fluxo completo em alta fidelidade
Scanner com confirmation overlay e ecrã Parcel Validated
Scanner — confirmation overlay com a ação contextual e confirmação de encomenda validada
Overlay de confirmação após a digitalização
Scanning Confirmation Overlay — opções contextuais com ilustrações, não ícones abstratos

Um ecrã, toda a complexidade absorvida

Cada transportadora requer passos diferentes ao entregar uma encomenda: assinatura, PIN, pagamento em dinheiro, documentação aduaneira. Gerir quatro transportadoras com requisitos diferentes poderia ter significado quatro fluxos de validação diferentes. Desenhei um ecrã de validação único com widgets condicionais que aparecem ou desaparecem conforme o que essa encomenda específica precisa. O kounter vê sempre a mesma estrutura: uma lista numerada de passos.

Para o kounter, é sempre a mesma experiência. A complexidade do sistema é absorvida pelo design.

Fluxo de validação adaptativa para as quatro transportadoras
Mesma estrutura, widgets condicionais por transportadora — assinatura · PIN · pagamento · documentação
Ecrã de validação com assinatura digital
Validação com assinatura — o widget aparece apenas quando a transportadora o exige
Ecrã de validação com PIN de entrega
Validação com PIN — mesmo layout, widget condicional diferente

O sistema que alinhou design e desenvolvimento desde o primeiro dia

Os programadores usavam React Native Paper, uma implementação de Material Design para React Native. A versão anterior ignorava esse sistema e gerava uma UI inconsistente com que os devs tinham de lidar constantemente. Construí o novo design system sobre Material 3: alinhou design e desenvolvimento, reduziu a dívida técnica desde o primeiro dia e deu-me componentes acessíveis e consistentes sem ter de construir tudo de raiz.

Não foi a escolha óbvia. Foi a correta: elevar a decisão de design o sistema que os devs já usavam.

Capa do Kanguro Design System v1.3 — baseado em Material 3
Kanguro Design System v1.3 — construído sobre Material 3, partilhado entre design e desenvolvimento
Componentes de botões do Kanguro Design System — Buttons, FAB, Icon button, Segmented button
Biblioteca de componentes — Buttons, FABs, Icon buttons e Segmented buttons documentados com todas as variantes
Canvas do Kanguro Design System — tipografia e guia de cor em vista completa
Vista de canvas — tipografia Nunito Sans e Color Guidance com paleta tonal e Light Theme documentados
Mão a digitalizar uma etiqueta de encomenda com a Counter App
Scanner em uso — frame de deteção ativo sobre a etiqueta da encomenda
Ecrã de validação da Counter App sobre superfície geométrica colorida
Ecrã de validação — três passos concluídos, pronto para confirmar a entrega
Counter App em produção — ativa em +2.700 pontos
Counter App em produção — Espanha, Portugal e Alemanha

Resultado

Infraestrutura real, não um side project

A primeira versão chegou a produção em 3 meses. Hoje, a Counter App está ativa em mais de 2.700 Kanguro Points em Espanha, Portugal e Alemanha, com cerca de 2.900 utilizadores ativos mensais e uma estabilidade técnica de 99,9% sem crashes no Android e 99,3% no iOS.

Não são métricas de um side project. É infraestrutura de produção real, usada diariamente por pessoas que não escolheram ser operadores logísticos — e que agora executam esse papel com fluência.

Reflexão

Este projeto ensinou-me que desenhar para utilizadores com baixa familiaridade tecnológica não significa simplificar até ao vazio: significa perceber que informação é imprescindível e qual é ruído, e tomar decisões claras sobre essa diferença. Também aprendi a mover-me sem rede — fui o único perfil de produto durante todo o processo, sem PM nem outro designer, e tive de defender o espaço para investigar num ambiente onde tudo avançava rápido. Aquela semana de visitas e entrevistas foi um luxo que tive de justificar. E que mudou o produto.

Em produção.

+2.700 pontos. Expansão internacional em curso.

Falar sobre o processo

Outros projetos