Square Register

Este case começou com um briefing que eu não escrevi, e terminou contrariando uma parte dele. Vale contar nessa ordem, porque foi a pesquisa que virou a mesa.

O ponto de partida

O desafio veio pronto: pegar o Square Register, que é um sistema de ponto de venda operado por um funcionário atrás do balcão, e transformá-lo num autoatendimento de supermercado. Tudo num tablet que acompanha a pessoa pela loja: escolher, registrar, pesar, pagar e receber o comprovante, sem depender de outro equipamento e sem passar por um caixa.

O objetivo declarado era reduzir fila. E vieram duas metas junto, escritas como perguntas:

01. Como poderíamos criar uma nova experiência de compra, onde o usuário tenha autonomia total?

02. Como simplificar a jornada do cliente, e oferecer um sistema confiável para sua jornada de compras?

Guarde a primeira. Autonomia total é a expressão exata que a pesquisa veio contradizer, e é dali que sai a decisão mais importante deste case.

O produto de onde o exercício parte. Esta imagem é material de divulgação da própria Square, e não trabalho meu.

Duas coisas precisam ficar claras antes de qualquer tela. A primeira é que este é um estudo: o briefing é de um bootcamp e usa uma empresa real como cenário. Nada aqui foi feito para a Square, encomendado por ela ou visto por ela. A segunda é que trabalhei sozinho, do primeiro desk research ao último componente.

O método estava planejado em quatro etapas desde o começo, e os quatro meses deram para cumprir as quatro.

O que não foi linear foi o percurso. Repare que o teste de usabilidade aparece duas vezes no plano, na descoberta e na entrega, e foi o segundo que mandou o projeto de volta para a definição: a validação de idade mudou de lugar quando o produto já tinha telas prontas.

A pesquisa

Comecei pelo mercado e terminei nas pessoas. A ordem importou menos do que eu esperava, porque o que mudou o projeto veio do fim.

Desk research. Levantei números sobre abandono de compra por causa de fila e sobre preferência por escanear os próprios produtos. Eles serviram para o que esse tipo de dado serve, que é confirmar que o problema existe e tem tamanho. Registro com a ressalva honesta: são números de 2023, de imprensa especializada de varejo, e a adoção de autoatendimento no Brasil subiu bastante desde então. Justificam o projeto na época, e não devem ser lidos como retrato de hoje.

Análise de competidores. Esta foi a parte que mais me ensinou sobre a categoria. Em vez de comparar folhetos, fui atrás de registro de uso real de quatro concorrentes: Amazon, Zaitt, Shopic e Caper by Instacart. Cada um virou uma faixa no quadro, com foto do equipamento, foto da tela em uso e anotação do que aquele momento resolvia ou atrapalhava.

Quatro concorrentes documentados por uso, e não por folheto. É daqui que sai a noção do que já era convenção na categoria.

Entrevistas. Três pessoas, cerca de vinte minutos cada, presencialmente. O objetivo era entender a preferência delas quanto ao tipo de atendimento em supermercado, e o recorte foi de propósito amplo: gente que frequenta supermercado, usando ou não o autoatendimento.

Eu entrei com três hipóteses concorrentes de formato, e elas estão registradas no roteiro: desenvolver só um aplicativo, desenvolver um totem para finalizar a compra, ou desenvolver um sistema em tablet com tudo dentro. As entrevistas existiam para decidir entre elas.

Três pessoas não é amostra para generalizar, e nada aqui deve ser lido como estatística. É amostra para achar direção.

O que os dados disseram

A dor mais forte não era a fila. Era ficar sem saída. Foi o achado que virou o projeto, porque contrariava o briefing que eu tinha recebido:

"Usuários preferem na maioria das vezes a ajuda de um funcionário para não perderem tempo resolvendo problema do sistema."

"Ter sempre pessoas próximas ajuda a ter mais confiança e acionar ajuda rapidamente caso precise."

A meta 01 pedia autonomia total. O que as pessoas descreveram foi outra coisa: resolver sozinhas o que funciona, sem ficar presas quando algo falha. Autonomia, para quem está comprando, não é ausência de gente. É não depender de gente para o caminho comum.

As pessoas pediram a balança sem saber que estavam pedindo um formato. Duas das falas mais concretas eram sobre pesar:

"Gostaria de poder pesar o produto no próprio autoatendimento para agilizar o processo."

"Ter uma balança inteligente que entenda o que eu quero pesar sem que eu tenha que ir a outro lugar."

Isso decidiu a disputa entre as três hipóteses. Um aplicativo no celular não pesa nada, e um totem no fim da loja obriga a ir até lá. Só o tablet preso ao carrinho resolvia, e foi por isso que ele ganhou, e não por ser o mais moderno dos três.

A balança integrada é a resposta direta a duas das três entrevistas, e o motivo de o formato ser tablet.

E apareceu um pedido bem concreto: mais formas de pagamento, incluindo vale-refeição. Foi o mais fácil de atender de todos, e o único que dá para conferir só olhando a tela: débito, crédito, dinheiro, PIX, compra dividida em dois cartões, e VR na fileira de bandeiras.

O pedido de uma das entrevistas, atendido e verificável: o VR está na fileira.

As decisões

Ajuda com prazo, e com saída

O botão de ajuda não abre chat nem central de atendimento. Ele chama uma pessoa de verdade e mostra a contagem regressiva até ela chegar.

A contagem é a decisão inteira. Sem ela, o pedido de ajuda vira espera indefinida, que é exatamente o estado descrito nas entrevistas como motivo para desistir do autoatendimento. Com ela, a pessoa sabe se vale a pena esperar.

E há um botão de cancelar, porque quem se resolveu sozinho nos primeiros segundos não deveria ficar refém do próprio pedido.

A contagem transforma um pedido de socorro numa espera com prazo. O cancelar existe porque nem todo pedido precisa ser cumprido.

Quem procura o produto é o sistema

Se a razão mais comum de chamar alguém é não achar um item, então achar o item não pode depender de chamar alguém.

A busca devolve o produto com o corredor onde ele está, marca o ponto na planta da loja e mostra a posição do carrinho em relação a ele. Quem prefere pegar na volta toca em "Avise-me", e o sistema avisa ao passar perto.

A planta responde "onde está o item" e "onde estou eu" na mesma tela.

Interromper uma vez só

Alguns produtos exigem comprovar maioridade. A primeira versão pedia essa validação no momento em que o item entrava no carrinho, que é onde a regra nasce.

Na prática isso parava a compra toda vez que um item restrito aparecia. A validação foi para o pagamento, uma vez só, com o CPF. No carrinho fica apenas um aviso de que aquele item vai precisar ser validado depois.

A regra continua valendo. O que mudou foi quantas vezes ela interrompe a compra.

Do problema à tela

Antes de desenhar tela, desenhei o serviço.

O canvas organizou problema, usuários, concorrentes, alternativas e proposta de valor numa página só. Vale a ressalva que já estava no projeto original: esse exercício foi feito sem stakeholder, com dados obtidos em pesquisa online. É um canvas de estudo, e não um alinhamento com quem decide o negócio.

Feito sem stakeholder, e isso está anotado no próprio material desde 2023.

O blueprint de serviço foi o que mais mudou o desenho. Ele cruza as etapas da jornada, da necessidade ao pós-compra, com o que a pessoa faz, os pontos de contato, o que o sistema faz por baixo, as dores, as oportunidades e as soluções possíveis. É ali que a validação de idade aparece como problema de serviço, e não de tela.

Etapa por etapa, o que a pessoa faz e o que o sistema precisa fazer para aquilo funcionar.

O task flow mapeou os caminhos com as decisões explícitas, incluindo as que não seguem adiante.

Cada losango tem saída para os dois lados. As que dão errado também precisavam de tela.

Só então vieram os rabiscos. Fiz Crazy 8's e rabiscoframes em papel, para testar arranjo de tela sem me apegar a nenhum.

Papel e caneta primeiro. Ideia ruim descartada aqui custa minutos, e não dias.

Nos wireframes em média fidelidade tomei uma decisão que atrasou o começo e pagou no fim: não usar nenhum UI kit pronto. Queria descobrir os componentes desenhando as telas, e não encaixar as telas em componentes que alguém já tinha resolvido. Foi essa versão que virou protótipo navegável e foi para o teste.

A versão que foi para as mãos dos participantes. Média fidelidade de propósito: acabamento demais faz o teste virar avaliação de estética.

O sistema por trás

O moodboard foi menos sobre estética e mais sobre quem usa. Supermercado é um dos poucos lugares por onde todo mundo passa, e a referência precisava mostrar isso: gente diferente, produtos, a origem do que se compra e o que acontece depois que a compra chega em casa.

A referência é o público, e não a interface. Quem usa autoatendimento de supermercado é todo mundo.

Na interface, a decisão foi não inventar. A Square já tinha um sistema de design estabelecido, e o exercício era estender um produto existente, não substituí-lo. Desenhei componentes novos para o que o autoatendimento exigia, seguindo o que já estava em uso.

O item do carrinho é o exemplo. Ele não é uma linha de lista: é um componente com estado. Entrando, saindo, e a variante que carrega o aviso de validação pendente.

O mesmo item em três momentos. O aviso de validação é estado do componente, e não uma tela à parte.

E o diagrama abaixo é o produto numa página só: as telas e as ligações entre elas.

As telas e os caminhos entre elas. O mapa da loja é alcançável de qualquer ponto, e isso é decisão, não sobra de layout.

O produto rodando

O case até aqui mostra decisão. Estas gravações mostram o resultado delas em movimento, no protótipo de alta fidelidade.

Repare em duas coisas que não vieram da pesquisa e entraram porque o produto precisava delas para existir: a validação do ticket de estacionamento e a escolha de como receber o comprovante. E repare no estado de erro do ticket, com o código recusado em vermelho. Num sistema em que não há um funcionário do outro lado do balcão, a tela que dá errado é tão parte do produto quanto a que dá certo.

O teste, e o que ele mudou

O teste de usabilidade foi presencial, com o protótipo em média fidelidade num tablet, para chegar perto da situação real de fazer uma compra e pagar no próprio aparelho.

Duas mudanças saíram dali.

A validação de idade mudou de lugar. Era feita quando o produto entrava no carrinho, e passou a ser feita uma vez só, no pagamento. Foi o que os participantes preferiram, e é a decisão descrita acima.

A busca virou o centro da tela. A barra de pesquisa aumentou, os resultados passaram a aparecer em tempo real com o setor onde o produto está, a rota até ele ficou visível a partir de onde a pessoa está, e o "Avise-me" ganhou a notificação de proximidade. O que existia antes era informação demais, e parte dela duplicada.

Aqui preciso ser claro sobre uma lacuna deste case: eu não tenho registro visual do teste. Ele foi feito pessoalmente, com as pessoas usando o tablet, e eu não guardei a comparação entre a tela testada e a tela ajustada. As mudanças acima estão descritas porque aconteceram e orientaram a versão final, mas o case não consegue mostrá-las lado a lado, e eu não vou montar depois uma comparação que não existiu na época.

O que eu faria diferente

O aprendizado que eu tirei do projeto na época foi sobre negócio: entender o problema junto de quem decide, em vez de resolver a interface e apresentar depois. Ele continua valendo, e o canvas feito sem stakeholder é a evidência disso dentro do próprio material.

Revisitando agora, acrescento um segundo, e é mais desconfortável. Eu recebi um briefing que dizia autonomia total e passei meses construindo em cima dele, mesmo depois de as entrevistas dizerem outra coisa. As decisões acabaram certas, porque a tela de ajuda e o mapa da loja existem justamente por causa do que as pessoas disseram. Mas eu nunca voltei ao briefing para corrigir o enunciado, e continuei chamando de autonomia uma coisa que a pesquisa já tinha redefinido.

É esse o aprendizado que eu levo: quando a pesquisa contraria o briefing, atualizar as telas não basta. É o briefing que precisa ser reescrito, senão a decisão seguinte sai da premissa velha de novo.