Programação orientada ao usuário: o erro que mata o seu software e o tapa na cara que eu tomei
Quem cria software se apaixona por ele, e apaixonado fica cego. Eu levei o meu sistema de TV indoor pra dois salões de beleza, não expliquei nada, e o primeiro feedback mudou o produto. Nem a minha equipe nem a IA tinham pensado naquilo.
🎧 PREFERE OUVIR? · 16 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 15 minutos no canal @josimarjmv pra série Viver de software, viver de SaaS. Direto, sem corte, como se fosse ao vivo. Assista e leia junto: aqui embaixo eu conto a mesma coisa por escrito e ponho o que eu fui conferir depois.
programação orientada ao usuário é o trocadilho que eu uso pra uma coisa óbvia que muita gente ignora antes de pôr um software ou SaaS pra vender: levar o sistema pro usuário do seu público-alvo, deixar ele usar sozinho e só ouvir. Monte um grupo de teste com gente do mercado que você vai atender, não explique como funciona, não discuta o que ele disser. Se ele não entende sozinho, o software não está resolvendo o problema: está resolvendo só a sua cabeça. Foi assim que dois salões de beleza mudaram o fluxo de vídeo e playlist do meu sistema de TV indoor.
O óbvio que precisa ser dito
Tem um erro grande que se comete na hora de fazer um software, de pôr um software pra vender, de criar um SaaS. Parece óbvio. Mas como eu estou fazendo essa série sobre como viver de software, viver de SaaS, muitas vezes o óbvio tem que ser dito, porque ele é ignorado por uma quantidade absurda de gente.
Eu chamo de programação orientada ao usuário. Trocadilho infame, eu sei. E já aviso: eu nem estou entrando em código, qualidade de código, infraestrutura, nada disso. Aqui é negócio. É usuário, é business.
Serve pra você que é desenvolvedor e quer criar um SaaS, pôr em produção, vender e viver de software. E serve pra você que é empresário, teve uma ideia de software e vai fazer parceria ou vai pro vibe coding pra pôr um site, um aplicativo, um SaaS no ar. É o grande objetivo de muita gente agora, na época do vibe code e do microSaaS.
Dois cenários, a mesma paixão
Vou pegar dois perfis que eu vejo muito.
O primeiro é o empresário de nicho. Pensa no cara da área da saúde. Ele vê um monte de problema naquele monte de software legado horrível com que ele lida. Você entra no software de hospital, de área pública, e é desesperador. Estamos em outubro de 2026 e, eu vou te falar, é muito software ruim na saúde. Porque além de fazer o software você tem que entrar nesse mercado, e entrar no mercado da saúde é difícil. Aí o médico vê aquilo e fala: "Pô, eu gosto de tecnologia, eu sou vibe coder, vou fazer um e pôr pra rodar". Ele está resolvendo a dor dele, a paixão dele.
O segundo é o desenvolvedor. Pensa no cara especializado em back-end. Ele é bom naquilo que faz, mas com front, com negócio, com venda... Cristo. Ele vê um gap de mercado, uma coisa que resolve um problema dele, se apaixona e fala: "Cara, isso aqui é a melhor coisa do mundo". E ele quer ser empresário também, porque um SaaS é uma empresa, não é só pôr um software no ar. Essa diferença eu contei em SaaS ou software house? O atraso que custou R$ 263 mil.
Os dois estão com a mesma paixão. E quando o cara está apaixonado pelo software dele, ele fica cego pras outras coisas.
Apaixonado fica cego: "meu software não tem concorrente"
Você já viu aquela pessoa que tem um namorado, uma namorada, a outra pessoa faz de tudo com ela e ela não larga, não vai procurar coisa melhor pra vida? É quando a pessoa está muito apaixonada. Fica cega pro que acontece. Poder da negação: sabe, mas não quer acreditar. A gente conhece bem isso nas nossas famílias.
Na vida do software acontece igualzinho. O cara se apaixonou, e na cabeça dele o software é o mais perfeito do mundo. "Não tem concorrente." É o que eu mais escuto. E eu também sou desse: muitas vezes eu acho que o meu software não tem concorrente.
Mas e o usuário?
- O que o usuário acha do seu software?
- O usuário acha que o seu software não tem concorrente? Você já educou o usuário sobre isso?
- O seu software já está no ar? Não?
- Você já conversou com o usuário?
Pois é. Você arrumou um grupinho pra testar o seu software de graça, sem cobrar nada, só pra ouvir feedback? É óbvio. Mas a quantidade de gente que não faz isso, que acha que o software dela é o melhor do mundo, que é "I'm the king of the world", é enorme. Falei desse jeito de propósito, só pra dar uma zoada.
Desapaixona, meu amigo. Desapega. Igual na propaganda da OLX: desapega.
Como eu testo: usuário do público-alvo, sem explicar nada
Vai conversar com as pessoas. Encontra usuários que são público-alvo do seu sistema e deixa eles usarem na sua frente, junto contigo, pra você entender a perspectiva deles. Vê como eles usam.
A abordagem é simples: "Olha, eu fiz um aplicativo, um software pra resolver tal problema. Queria que você usasse e me desse um feedback. Vamos tirar um tempinho? A gente almoça, janta, eu vou no seu estabelecimento". Muita gente ajuda, sabe? Leva o notebook. Cria usuário e senha pra ele. Se o aplicativo ainda está em desenvolvimento, pega o e-mail dele e convida, exporta o APK se for Android. Enfim, se vira. Mas leva a sua solução pro usuário.
Não ensine o usuário a usar o seu sistema
Esse é um ponto importante da abordagem. Pelo amor de Deus: você não tem que explicar pro usuário como o seu software funciona. Ele tem que entender sozinho. O sistema tem que ser self-service, autoexplicativo. A pessoa tem que bater o olho na interface e entender. É isso que dá uma boa experiência do usuário.
Se ele não entende sozinho, o seu software não está resolvendo o problema, porque ele está na sua cabeça, na sua lógica. Somos bilhões de pessoas, cada uma com uma criação diferente, uma cabeça diferente. Você criou de um jeito, e na cabeça dele pode não estar claro.
Eu já vi gente fazendo isso errado: chama o usuário, mas fica tentando ensinar como usa. E quando você ensina, tem muito usuário que não quer te contrariar. Ele não vai falar "não entendi". Vai falar "legal, bacana". Ele não vai voltar atrás naquilo que você já falou.
Fui conferir depois e o Jakob Nielsen, uma das referências mundiais em usabilidade, escreve a mesma coisa sobre o teste em que o usuário pensa em voz alta (artigo de 15/01/2012 no Nielsen Norman Group): pergunta e interrupção de quem conduz o teste mudam o comportamento do usuário com muita facilidade, e aí o que você observa não representa o uso real, então você não pode tomar decisão de design em cima disso.
O tapa na cara que eu tomei com o meu sistema de TV indoor
Vou te dar um exemplo meu. Atrás de mim, na gravação, tem uma TV vertical. Ela roda um sistema que eu criei pra TV indoor, o JMV Indoor, que usa aplicativo nativo de Smart TV: Android, Google TV, Roku, Fire Stick, Samsung, LG. A pessoa controla todos os pontos por um painel, via streaming. Como eu tenho plataforma de streaming, pra mim é fácil fazer isso. Ela sobe o vídeo e o vídeo fica ali, tocando como se fosse ao vivo. O vídeo atrás de mim está em loop nesse sistema.
Eu levei o aplicativo pra dois salões de beleza diferentes: uma usuária e um usuário. E fiz rigorosamente o que eu acabei de te falar. Levei e falei: "Testa pra mim".
Foi tanto feedback maravilhoso. O primeiro: a pessoa subiu o vídeo, virou pra mim e perguntou: "Tá, mas por que o vídeo não apareceu aqui?"
Eu respondi: "Porque agora você tem que cadastrar na playlist". Eu vim daquele sistema de web TV que a gente inventou há 12, 13, 14 anos, que sempre teve playlist. É como no Spotify: você monta a playlist. Só que o usuário virou pra mim e falou: "Não. Eu subi o vídeo, eu quero que o vídeo apareça. Se eu não quiser, eu vou lá e deleto". Não quer ter que pôr o vídeo na playlist e depois programar a playlist.
Aí eu não questionei de novo. Porque se você começa a questionar o usuário, ele fica com receio de te contrariar. Você só ouve. Dois ouvidos e uma boca, por isso que é dois pra um. Ouça 20 palavras, fale cinco.
Nem a equipe nem a IA tinham pensado naquilo
Cheguei na empresa e falei: "Gente, a gente tomou um tapa na cara agora". Vim raciocinando no caminho. O feedback fez todo sentido: quem tem 1, 2, 3, 4 pontos e não precisa de programação avançada precisa subir o vídeo e ver o vídeo tocar. A playlist continua lá pra quem tem muitos pontos e programa avançado.
Eu, dono da empresa, o meu suporte, o time de desenvolvimento: ninguém parou pra pensar nisso. A gente tinha pedido ajuda de interface e de experiência do usuário pra IA, pro Claude Code, pro Gemini. Ninguém deu essa ideia. Nem a IA, nem a gente, humano.
Hoje ficou facinho. Você sobe o vídeo e ele processa e já vai pra playlist sozinho. E teve outra preocupação de usabilidade no mesmo pacote: login social, Apple e Google, o básico.
| Como era | Como ficou | |
|---|---|---|
| Subir um vídeo | Sobe o vídeo, cadastra na playlist, programa a playlist | Sobe o vídeo e ele processa e entra na playlist sozinho |
| De onde veio a ideia | Da minha cabeça, do tempo da web TV | De um usuário do público-alvo, no primeiro minuto de uso |
| Programação avançada | Obrigatória pra todo mundo | Continua lá pra quem tem muitos pontos |
Então quem me deu isso? Programação orientada ao usuário. Não foi a IA. Não foi o meu dev de front, nem o de back. Não fui eu, dono da empresa. Não foi a minha equipe de suporte. Não foram outros clientes de outros segmentos. Foi um usuário de um dos públicos-alvo possíveis do meu sistema de TV.
Quantos usuários testar
Eu levei pra dois salões e já saí com o tapa na cara. Fui olhar o que diz quem estuda isso: o Jakob Nielsen defende, num artigo de 18/03/2000, que teste elaborado de usabilidade é desperdício e o melhor resultado vem de testar com no máximo 5 usuários, fazendo quantos testes pequenos você puder pagar. Pelo modelo dele, o primeiro teste com cinco pessoas acha cerca de 85% dos problemas; aí você corrige e testa de novo.
Bate com o que eu vivo: não precisa de pesquisa cara. Precisa de gente do seu público, na sua frente, usando sem ajuda. E de voltar lá depois que corrigiu.
Uma das dezenas de etapas pra viver de SaaS
Isso aqui é muito importante se você quer viver de SaaS, viver de software, pôr software em produção. Só que é uma das dezenas de etapas pra pôr um SaaS em produção, pra testar antes, pra desenvolver.
Se o seu software é feito com vibe code, a checagem técnica antes de subir eu contei em vibe coder: o que eu confiro antes de subir pra produção. Se o seu problema é o cliente que não larga o concorrente, está em ninguém migra pro seu SaaS: as 2 perguntas que eu respondo. E o atendimento, que é a outra metade de ouvir o usuário, em software de sucesso no Brasil: abri suporte até meia-noite.
Aí você tem duas escolhas. A primeira: seguir a série, pausando os vídeos e pedindo pro Claude Code te ajudar em cada item. Dá pra conseguir, batendo muita cabeça e gastando uma semana, um mês, um ano em cada item. Tem item que é jurídico e contábil, e você vai gastar muito em consultoria pra aprender. Marketing, tráfego pago, tráfego orgânico, mesma coisa, e tráfego pago é brabo, porque você torra dinheiro.
A segunda é a Imersão de SaaS, presencial em São Paulo, três dias: pipeline, desenvolvimento, infraestrutura, segurança, marca, suporte, venda, atendimento e essa parte de ouvir o usuário. A gente sai de lá com o mapa completo pra pôr um software em produção. Formato, data e condição são os da página dela, não desta gravação.
Nota de cronologia
O vídeo foi ao ar em 15 de outubro de 2026 e este texto saiu em 16 de outubro de 2026. O teste nos dois salões de beleza e a mudança do fluxo de vídeo e playlist já tinham acontecido quando eu gravei; não cravei a data do teste. A web TV com playlist eu situei na gravação "há 12, 13, 14 anos".
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
O que é programação orientada ao usuário?
É um trocadilho meu pra uma coisa óbvia que muita gente ignora: antes de pôr um software ou SaaS pra vender, você leva ele pro usuário do seu público-alvo, deixa ele usar sozinho e ouve o que ele diz. Não é sobre código nem infraestrutura. É negócio.
Por que tanto software novo fracassa mesmo resolvendo um problema real?
Porque quem criou se apaixonou. O médico que faz um sistema pra dor dele e o desenvolvedor que acha um gap de mercado caem no mesmo lugar: na cabeça deles o software é o melhor do mundo e não tem concorrente. Apaixonado fica cego. A pergunta que falta é: o que o usuário acha do seu software?
Como testar um SaaS com usuário antes de lançar?
Monte um grupo pequeno de gente do mercado que você vai atender e peça pra testarem de graça. Vá até a pessoa, num almoço ou no estabelecimento dela, crie usuário e senha ou instale o aplicativo, e deixe ela usar na sua frente. Você não explica nada, só observa e ouve.
Por que não posso explicar o sistema pro usuário durante o teste?
Porque o sistema tem que ser autoexplicativo: a pessoa bate o olho na interface e entende. Se ela não entende sozinha, o software não está resolvendo o problema, está só na sua cabeça. E quando você ensina, muito usuário não quer te contrariar e passa a dizer que entendeu.
E se o usuário disser algo que eu acho errado?
Não discuta. Se você começa a questionar, ele fica com receio de te contrariar e para de dar feedback. Dois ouvidos e uma boca: ouça 20 palavras, fale cinco. Leve pra equipe e pense depois. No meu caso, o feedback que eu quase rebati foi o que mais melhorou o produto.
A IA não substitui o teste com usuário real?
No meu caso não substituiu. A gente pediu ajuda de interface e experiência do usuário pro Claude Code e pro Gemini, e ninguém, nem a IA nem a gente, deu a ideia que o usuário do salão de beleza deu no primeiro minuto de uso: subiu o vídeo, quer ver o vídeo tocando.
Quantos usuários eu preciso pra um teste desses?
Eu levei pra dois salões e já tomei um tapa na cara. Pra referência, o Jakob Nielsen defende desde 2000 testes pequenos com até 5 usuários, repetidos várias vezes, em vez de um estudo grande e caro. O importante é testar com gente do seu público e repetir depois de corrigir.
Baseado na gravação do canal @josimarjmv publicada em 15/10/2026 (15min42), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: a série viver de software, viver de SaaS e o trocadilho "programação orientada ao usuário"; o recorte de negócio, sem entrar em código ou infraestrutura; os dois cenários, o empresário da área da saúde que vê software legado ruim e faz o dele com vibe code e o desenvolvedor de back-end que acha um gap de mercado; o SaaS como empresa; a comparação com a pessoa apaixonada que fica cega; o "meu software não tem concorrente", que eu também já pensei; o grupo de teste de graça; o "desapega" da OLX; o jeito de chamar o usuário (almoço, janta, ir no estabelecimento, notebook, usuário e senha, APK); não explicar o sistema e não ensinar, porque o usuário não quer contrariar; o sistema de TV indoor com aplicativo nativo de Smart TV e controle via streaming; o teste com uma usuária e um usuário de dois salões de beleza; a pergunta "por que o vídeo não apareceu"; a playlist herdada da web TV de 12 a 14 anos atrás; não questionar o usuário, dois ouvidos e uma boca, ouvir 20 palavras e falar cinco; o "tapa na cara" na empresa; o pedido de ajuda de interface ao Claude Code e ao Gemini sem essa sugestão; o vídeo que hoje vai sozinho pra playlist e o login social com Apple e Google; e o convite para a imersão presencial em São Paulo. Na gravação eu também ofereci teste grátis do sistema de TV indoor e falei de preço, pagamento e live da imersão; isso é produto e condição comercial e ficou fora deste texto. Eu disse "somos 6 bilhões de pessoas"; aqui ficou "bilhões" porque não conferi o número.
Apuração minha (16/10/2026): o artigo "Thinking Aloud: The #1 Usability Tool", de Jakob Nielsen, publicado em 15/01/2012 no site do Nielsen Norman Group, lista entre os riscos do método o de enviesar o comportamento do usuário: perguntas e interrupções de quem conduz o teste mudam o comportamento, e o resultado deixa de representar o uso real. O artigo "Why You Only Need to Test with 5 Users", do mesmo autor, de 18/03/2000, defende testar com no máximo 5 usuários e fazer quantos testes pequenos couber no orçamento, e diz que o primeiro estudo com cinco participantes encontra 85% dos problemas de usabilidade, pelo modelo matemático dele com Landauer (1993). O diagrama dos três passos e a tabela do antes e depois são organização minha, feita depois, em cima do que eu disse. O caso dos salões não foi conferido fora da gravação.