StopCar - 1º lugar no Hackathon

Este case começou como um projeto de fim de semana e virou outra coisa um ano depois. Vale contar nessa ordem, porque a segunda passada mudou o que eu entendia da primeira.

O ponto de partida

O tema do hackathon era Vertical Smart Cities. Éramos oito equipes no começo e metade chegou ao fim. Trabalhei com mais duas pessoas, e cuidei da pesquisa, dos fluxos, da interface e da apresentação ao júri.

Era o meu primeiro hackathon. Tinha vontade de participar de um havia tempo e nunca tinha aparecido a oportunidade.

Escolhemos estacionamento porque é um problema urbano que todo mundo na sala já tinha vivido. Essa é uma boa razão para escolher um tema e uma péssima razão para achar que já se conhece o problema. Foi o que a pesquisa mostrou.

O conceito nasceu com dois lados. De um, o motorista que procura vaga. De outro, o dono do estacionamento, que precisa preencher as vagas que tem, e para quem o segundo objetivo declarado do projeto era maximizar a ocupação e a receita. No prazo do fim de semana só o lado do motorista foi desenhado, e é dele que este case trata.

O caminho também não foi linear, e o projeto registra isso de um jeito que eu não quis perder ao trazer para cá.

O botão acima existe porque a versão limpa é sempre a que se conta depois. Nem tudo o que está previsto ali foi concluído no prazo, e é disso que trata o fim deste case.

A pesquisa

Montei duas frentes, com propósitos diferentes.

Entrevistas em profundidade, com roteiro de dez perguntas organizadas em cinco eixos: comportamento e hábitos, dores e frustrações, percepções e necessidades, experiência com tecnologia, sugestões e melhorias. Feitas presencialmente e por videochamada.

Antes de cada conversa eu lia um script de abertura pedindo autorização para gravar o áudio, e explicava por quê: gravando, eu não precisava escrever durante a fala e não interrompia o raciocínio da pessoa. Parece burocracia. Não é. É o que permite ouvir de verdade, em vez de anotar.

Um survey estruturado, com onze participantes e oito perguntas, tabulado numa matriz de participante por pergunta. As entrevistas serviam para entender como as pessoas decidem; o survey, para saber quantas pensam parecido.

Onze pessoas num fim de semana não é amostra para generalizar, e nada aqui deve ser lido como estatística. É amostra para achar direção, que era o que o prazo permitia e o que a decisão exigia.

Todas as contagens deste case saem daqui. Nada foi arredondado para soar melhor.

O que os dados disseram

Estacionar é rotina diária, e a dificuldade também. Sete dos onze participantes estacionam todos os dias. E nenhum respondeu que nunca tem dificuldade para achar vaga: dois disseram "sempre", cinco "frequentemente" e quatro "às vezes". Não era um transtorno ocasional de fim de semana.

A dor mais forte não era a vaga. Era a insegurança. Foi o achado que mais mudou o projeto, porque não era o que eu esperava encontrar. Oito das onze respostas à pergunta aberta sobre frustração falam de medo, roubo ou falta de segurança, e de formas muito concretas:

"Falta de vaga ou 'flanelinha' cobrando pra olhar seu carro."

"Pagar zona azul pro carro ficar desprotegido na rua."

"Perigo de voltar e não encontrar o veículo."

Eu tinha entrado achando que o problema era tempo perdido. Tempo aparece nos dados, mas perde para o medo de deixar o carro em algum lugar e não achar depois.

O comportamento muda conforme se conhece o lugar. Duas pessoas descreveram a mesma estratégia sem combinar:

"Se é um lugar conhecido, já sei onde tem uma área maior para estacionar e já sei o caminho. Quando não é, daí eu dou uma pesquisada."

As pessoas já descreviam o produto sozinhas. Perguntado sobre o que gostaria de ver num aplicativo, um participante respondeu com um modelo pronto:

"Preço, local, agendar. Igual ao Uber: local e horário."

Mas o recurso mais pedido no survey não foi reservar. Foi ver a disponibilidade em tempo real: nove dos onze marcaram essa opção, contra seis que marcaram reservar com antecedência. Antes de garantir a vaga, as pessoas queriam saber se havia vaga.

Os dois achados mais fortes foram parar na mesma tela. A home abre com o mapa mostrando quantas vagas cada estacionamento tem livres naquele momento, que era o recurso mais pedido, e a linha acima da busca diz "vamos achar uma vaga segura", porque segurança era a palavra que mais se repetia nas respostas.

Disponibilidade em tempo real e a palavra segurança, os dois achados da pesquisa, na primeira tela do app.

E ninguém conhecia a categoria. "Nunca usei." "Nunca usei, não conheço nenhum." "Nunca vi nenhum app que faça isso." Não se tratava de melhorar algo que já existia na cabeça das pessoas. Era introduzir uma ideia.

Havia um teto de preço, e era baixo. Nenhum participante aceitou pagar mais de dez reais por reserva, e quatro esperavam que fosse gratuito. Qualquer modelo de negócio teria que caber nisso.

E apareceu uma dor que o produto não resolve. Duas pessoas trouxeram, sem serem perguntadas, que a dificuldade delas era manobrar:

"Fazer baliza é uma dificuldade."

Não estava no survey, então não sei o tamanho disso. Fica registrado como pista, e não como achado: o StopCar ajuda a encontrar e reservar, mas estacionar o carro continua sendo com a pessoa.

As decisões

Separar quem precisa agora de quem está planejando

A fala sobre lugar conhecido e lugar desconhecido descreve duas situações que parecem a mesma e não são. Quem já está na rua procurando quer resolver em segundos. Quem vai sair de casa daqui a três horas quer escolher com calma.

Um fluxo único obrigaria os dois a percorrer o mesmo caminho, e o caminho bom para um é ruim para o outro: filtro demais atrapalha quem tem pressa, e pressa demais atrapalha quem quer comparar.

Por isso a entrada se divide logo no começo, em reservar para agora e planejar sua reserva. As telas seguintes convergem, porque a escolha de duração, veículo e adicionais é a mesma nos dois casos. O que muda é a porta.

Quem planeja começa procurando um lugar. Quem tem pressa já começa com o lugar resolvido.

Mostrar o suficiente para decidir sem ir até o lugar

Como ninguém conhecia a categoria, a barreira não era usar o aplicativo. Era confiar nele. Reservar às cegas um lugar onde você vai deixar seu carro é exatamente o medo que a pesquisa revelou.

A tela de detalhes reúne localização, disponibilidade, preço, horário e informações do estacionamento antes de qualquer confirmação. E a escolha desce até o andar e a vaga específica, o que responde ao tema do hackathon por um caminho concreto: estacionamento vertical, com a vaga identificada em altura, e não um endereço genérico.

A vaga tem andar e número. O mesmo dado reaparece na confirmação, porque é ele que a pessoa vai procurar quando chegar.

Não terminar no pagamento

A reserva confirmada não é o fim da tarefa. A pessoa ainda precisa chegar ao local, entrar, e às vezes ficar mais tempo do que planejou.

O fluxo continua depois do pagamento: navegação até o estacionamento com tempo e distância, início da reserva, extensão de período e histórico. Se o produto existia para reduzir a insegurança, abandonar a pessoa no momento em que ela ainda está longe do carro seria contradizer a própria premissa.

O botão de ir depois existe porque nem toda reserva é para agora. A tela precisava servir aos dois começos.

Do fluxo à tela

Antes de desenhar tela, desenhei caminho.

O fluxograma cobre a entrada no produto e os pontos em que a pessoa decide: ativar ou não a localização, entrar por telefone, Apple, Facebook ou Google, e o que muda quando o usuário é novo. Cada saída de losango tem destino, inclusive as que não levam adiante.

Fluxo de entrada com as decisões explícitas. Cada saída tem destino, inclusive as que não seguem.

O blueprint de serviço foi mais longe do que a tela. Para cada etapa ele separa o que a pessoa faz, o que ela vê acontecer, o que o sistema faz por baixo e de que ferramenta aquilo depende. É ali que fica registrado que "vaga disponível" não é informação de interface: é consulta a um banco de dados que ainda precisa bloquear a vaga temporariamente enquanto a reserva não confirma.

O que a pessoa vê, o que o sistema faz e de que ferramenta aquilo depende, etapa por etapa.

E o mapa de telas mostra o tamanho real do que foi desenhado, muito além das telas que este case consegue mostrar uma a uma.

O produto inteiro, tela a tela. As deste case são um recorte.

O sistema por trás

Antes das telas veio o mapa. Cada área do produto com o que cabe dentro dela, das mais óbvias, como buscar e reservar, às que só aparecem depois, como veículos cadastrados, favoritos e histórico.

O produto inteiro numa página. É aqui que fica claro que a reserva era só uma parte dele.

A marca veio do mesmo lugar. O símbolo é um pin de localização ocupando o lugar do "a" de StopCar, o que resolve nome e ícone com um desenho só, e continua legível invertido sobre fundo escuro.

Um desenho que serve de logotipo e de ícone do app, sem precisar de duas soluções.

Além dos fluxos, montei a base visual: paleta com os contrastes anotados, escala tipográfica e biblioteca de ícones.

As marcas AAA e AA em cada tom não são enfeite: era a checagem de contraste feita antes de usar a cor, não depois.

E, sobre essa base, uma folha de componentes reaproveitados entre as telas.

Num hackathon isso parece luxo, e é o contrário: com o tempo curto, ter componente pronto foi o que permitiu redesenhar fluxo sem redesenhar tela.

Cada peça aqui aparece em mais de uma tela. Foi isso que deixou o fluxo ser refeito sem refazer a interface.

O produto rodando

O case até aqui mostra decisão. Esta seção mostra o resultado delas em movimento: as gravações do protótipo de alta fidelidade.

Repare no que aparece aqui e não veio da pesquisa. Veículos cadastrados e histórico saíram do mapa de arquitetura, não de um achado com usuário. São o que o produto precisava ter para existir, não o que ele precisava resolver. Num hackathon não sobra tempo de validar essa parte, e ela entrou assim mesmo.

O que aconteceu

O StopCar ficou em primeiro lugar. Os jurados apontaram a inovação da proposta como o motivo.

A peça que reúne marca, produto e posicionamento numa composição só.

Vale dizer o que isso não é. Hackathon premia proposta, não produto em uso: o StopCar nunca foi lançado, nunca teve usuário de verdade e não tem número de adoção para mostrar. O que este case comprova é o raciocínio até a decisão, e não o efeito dela no mundo.

O que eu faria diferente

Voltei ao projeto em 2024, e a coisa mais reveladora não foi uma tela: foi descobrir que eu tinha coletado a pesquisa e nunca a sintetizado.

O quadro de 2023 tem objetivo, roteiro, transcrições e a matriz de resultados tabulada. Tem também duas colunas, insights e "how might we", com os post-its em branco, ainda com o texto padrão da ferramenta. No ritmo do fim de semana, os dados viraram decisão direto, sem passar pela etapa que transforma resposta em conclusão.

As decisões acabaram certas. Mas estavam certas por intuição bem informada, e não por um raciocínio que eu pudesse mostrar a alguém. A síntese que sustenta este case foi feita depois, relendo o material original, e foi só aí que o achado sobre insegurança ficou visível para mim. Ele estava nos dados desde 2023.

É esse o aprendizado que eu levo, e ele não é sobre estacionamento: pesquisa que não é sintetizada vira memória, e memória não se audita.