O redesign da InstaCarro que ajudei a construir enquanto o time de design deles ainda estava se formando The InstaCarro redesign I helped build while their design team was still taking shape

Entre 2019 e 2022, enquanto eu tocava projetos pela WA Project Consultoria, um dos clientes que caiu na minha mesa foi a InstaCarro. Diferente de outros projetos da época, não era um produto do zero: a InstaCarro já tinha um app rodando, com um fluxo de venda de carro no ar. O pedido era reformular essa experiência inteira, do primeiro contato até o carro vendido.

O app existente não era fácil o suficiente de usar. Esse era o motivo real por trás do pedido de redesign: tornar a experiência mais amigável pro usuário final, do primeiro contato até o carro vendido. Pedia repensar a arquitetura da informação do fluxo inteiro (onboarding, cadastro, login, cotação do veículo, agendamento de vistoria, acompanhamento até a venda), de um jeito que fizesse sentido pra quem tava chegando ali pela primeira vez.

Atuei pela WA Project como a ponte de design desse projeto, em interação direta com o time de design interno que a InstaCarro estava estruturando na época. Esse time ainda estava se formando enquanto o projeto acontecia, então parte do que entreguei também serviu de referência de processo pra quem ia crescer ali depois de mim.

Comecei pelo wireframe: uma passada de baixa fidelidade cobrindo o app inteiro, sem cor nem marca, só caixa e texto. Onboarding, cadastro, login, início, cotação do veículo por marca, modelo, ano e versão, agendamento de vistoria, acompanhamento do carro em cada etapa (vistoriador indicado, inspeção em andamento, proposta, leilão, venda), perfil, central de dúvidas, lojas físicas. A ideia era fechar a estrutura inteira antes de gastar tempo com visual.

O ponto de partida: a arquitetura da informação do app inteiro em baixa fidelidade, sem gastar um segundo com cor antes de validar a estrutura.

Com a IA validada, entrei na primeira fase de alta fidelidade. Construí o sistema visual que o app usa até hoje: o walkthrough de onboarding com ilustração de carro sobre fundo verde de marca, a tela de início com foto real de veículo e CTA de "ver preço", o módulo de "passo a passo pra vender seu carro", e o fluxo de agendamento com cada estado desenhado (agendado, vistoriador indicado, inspeção em andamento, inspeção concluída com leilão rolando).

Com a IA validada, veio o sistema visual que o app usa até hoje: onboarding, tela de início e agendamento com cada estado desenhado.

Na segunda fase, estendi esse mesmo sistema pro resto da jornada: cadastro e login completos com os estados de erro (e-mail inválido, código não recebido, confirmação falhada), estimativa de valor passo a passo por marca, modelo, ano e versão, as duas modalidades de agendamento (a InstaCarro vai até o vendedor ou o vendedor vai até a InstaCarro), perfil e contato. Também revisei o onboarding nessa fase, simplificando de 5 pra 4 passos.

A segunda fase estendeu o mesmo sistema pro resto da jornada: cadastro, login, estimativa de valor e as duas modalidades de agendamento.

O trabalho foi implementado e, depois que saí do projeto, o time interno de design da InstaCarro deu sequência. Parte das telas que desenhei nessa fase segue em uso no app hoje.

O time interno ter conseguido pegar esse trabalho e continuar construindo em cima dele, em vez de recomeçar do zero, diz mais sobre a consistência da estrutura do que qualquer coisa que eu possa afirmar sozinho. E tem uma camada extra aqui: esse time ainda estava se formando quando eu entrei, então o trabalho que ficou carregava também uma forma de organizar o processo, junto com as telas em si. Anos depois, formalizei essa mesma lógica de handoff e continuidade no DS.Sensei, no KaBuM!.

Redesenhar não é desenhar do zero. Tinha usuário real e dado real rodando naquele fluxo. A liberdade de propor uma reformulação inteira vem com a responsabilidade de não quebrar o que já funcionava.

Ensinar processo também é entregar design. Trabalhar com um time que ainda estava se formando mudou como eu estruturei as decisões: documentar o porquê importava tanto quanto o resultado visual, porque esse time ia precisar continuar sem mim.

Design que sobrevive à sua saída do projeto é o teste real de consistência. Quem validou isso foi o time que herdou o trabalho e conseguiu seguir construindo sem precisar recomeçar.

Between 2019 and 2022, while running projects through WA Project Consultoria, one of the clients that landed on my desk was InstaCarro. Unlike most projects I took on back then, this wasn't a blank slate: InstaCarro already had an app in production, with a live car-selling flow. The ask was to rework that entire experience, from first contact to a sold car.

The existing app wasn't easy enough to use. That was the real reason behind the redesign request: make the experience friendlier for the end user, from first contact to a sold car. It meant rethinking the information architecture of the whole flow (onboarding, sign-up, login, vehicle quote, inspection scheduling, tracking through to the sale) in a way that made sense to someone showing up for the first time.

I worked through WA Project as the design bridge on this project, interacting directly with the in-house design team InstaCarro was building at the time. That team was still forming while the project was underway, so part of what I delivered also doubled as a process reference for whoever would grow into that team after me.

I started with wireframes: a low-fidelity pass covering the entire app, no color, no branding, just boxes and text. Onboarding, sign-up, login, home, vehicle quote by make, model, year and version, inspection scheduling, order tracking at every stage (inspector assigned, inspection in progress, offer, auction, sale), profile, help center, physical stores. The goal was to lock the whole structure before spending any time on visuals.

The starting point: the information architecture for the whole app in low fidelity, before spending a second on color.

With the IA validated, I moved into the first high-fidelity phase. I built the visual system the app still runs on today: the onboarding walkthrough with a car illustration over the brand green, the home screen with a real vehicle photo and a "see price" CTA, the "steps to sell your car" module, and the scheduling flow with every state designed (scheduled, inspector assigned, inspection in progress, inspection complete with an active auction).

With the IA validated, this became the visual system the app still runs on today: onboarding, home, and scheduling with every state designed.

In the second phase, I extended that same system to the rest of the journey: full sign-up and login with error states (invalid email, code not received, failed confirmation), a step-by-step value estimate by make, model, year and version, both scheduling modes (InstaCarro comes to the seller, or the seller comes to InstaCarro), profile and contact. I also revisited onboarding in this phase, trimming it from 5 steps to 4.

The second phase extended the same system to the rest of the journey: sign-up, login, value estimate, and both scheduling modes.

The work shipped, and after I rolled off the project, InstaCarro's in-house design team picked it up. Some of the screens I designed in that phase are still running in the app today.

The fact that the in-house team could take this work and keep building on it, instead of starting over, says more about the structure's consistency than anything I could claim on my own. There's an extra layer here too: that team was still forming when I joined, so what stayed behind carried a way of organizing the process, not just the screens themselves. Years later, I formalized that same handoff-and-continuity logic in DS.Sensei, at KaBuM!.

Redesigning isn't designing from scratch. There were real users and real data running through that flow. The freedom to propose a full rework comes with the responsibility of not breaking what already worked.

Teaching process is also delivering design. Working with a team that was still forming changed how I structured decisions: documenting the why mattered as much as the visual outcome, because that team would need to keep going without me.

Design that survives you leaving the project is the real test of consistency. The team that inherited the work and kept building without starting over is the one who proved that, not me.