O que usuários de Mac me ensinaram sobre software confiável

Quando o Mole saiu de um comando de shell e virou um app de Mac, eu esperava que a parte difícil fosse a interface. O trabalho surpreendente foi desaprender as minhas próprias suposições. Uma pessoa comprou o app duas vezes por engano e recusou a minha oferta de reembolsar a segunda compra. Outra corrigiu a unidade de temperatura que eu tinha escolhido para a região dela. Alguém não conseguia usar o app de jeito nenhum porque a interface escura era difícil de ler. Uma objeção direta ao preço me fez reconsiderar o que um app pago precisa merecer quando já existem ferramentas gratuitas.

Nada disso chegou como um pedido de recurso arrumado. Cada conversa expôs uma lacuna diferente entre a pessoa que eu imaginava e a pessoa que de fato usava o produto. Essa lacuna me ensinou mais do que outra tabela comparativa ou um gráfico de análise conseguiria.

Confiança faz parte do recurso

A compra duplicada ficou comigo porque a resposta prática era simples: eu podia devolver o dinheiro. O que tornava difícil era a confiança por trás do engano. A pessoa já tinha pago uma vez, cometeu um erro e ainda queria que a segunda compra apoiasse o trabalho. Isso é generoso, mas também cria uma obrigação de tornar o produto mais fácil de entender e mais seguro de usar.

Um utilitário que apaga arquivos tem uma lacuna de confiança maior que a da maioria dos programas. Ele pede que alguém acredite que uma varredura atribuiu os arquivos corretamente, que um item incerto não será selecionado e que um erro pode ser recuperado. Uma tela polida não carrega essa promessa sozinha. O produto tem de mostrar o plano, explicar por que algo foi pulado, proteger dados compartilhados e usar o Lixo quando a recuperação importa. Esses detalhes não são trabalho de suporte em volta do recurso. Eles são o recurso.

Isso também mudou como eu leio elogios. Um elogio é agradável, mas a pergunta útil é o que a pessoa confiou que o produto faria. Se a resposta for “remover arquivos sem me deixar ansioso”, a próxima versão deve reforçar a revisão e a recuperação antes de acrescentar outra categoria à varredura.

Localidade não é um perfil de preferência

Eu já supus que um Mac localizado para os EUA deveria mostrar temperaturas de hardware em Fahrenheit. Um usuário explicou que temperaturas técnicas em geral se leem em Celsius mesmo quando o clima e a temperatura do corpo usam Fahrenheit. Ver um chip a 110 graus sem a unidade esperada parecia alarmante, não familiar.

O Mole agora usa Celsius como padrão para temperaturas de hardware em toda região e mantém Fahrenheit como escolha explícita. A mudança no código foi pequena. A correção por trás dela foi maior: uma localidade me diz como formatar idioma, datas e números. Ela não me diz como alguém entende cada domínio técnico.

A regra mais segura do produto é começar pela convenção da coisa que está sendo medida, conferir com pessoas que usam essa convenção e preservar uma escolha explícita quando as duas formas são úteis. Adivinhar automaticamente mais preferências a partir de um país pode parecer personalizado e deixar o produto menos familiar.

Acessibilidade começa com “não consigo usar isto”

O Mole investiu em rótulos do VoiceOver, ordem de foco, movimento reduzido e contraste aumentado. Eu tinha começado a pensar em acessibilidade como um corpo de trabalho que o produto já levava a sério. Aí uma pessoa com baixa visão explicou que texto branco na interface escura fixa era difícil de ler e que ela só usava apps que seguiam a aparência clara do sistema.

Esse retorno mudou a categoria do problema. A aparência clara deixou de ser uma preferência estética ou um pedido de mais um ajuste. Para essa pessoa, era a diferença entre usar o app e deixá-lo instalado. O Mole ainda força uma aparência escura hoje, então isto continua uma lacuna real, não uma história de sucesso encerrada.

Acessibilidade não é um selo que vira verdade depois de rótulos suficientes. Um produto pode funcionar bem com o VoiceOver e ainda excluir alguém pelo contraste, pela cor, pelo movimento, pelo tamanho do alvo ou por uma decisão de aparência. A pergunta útil não é se o app “suporta acessibilidade”. É qual tarefa uma pessoa ainda não consegue concluir, com quais ajustes do sistema, e qual parte da interface impede isso.

Uma objeção de preço pode ser pesquisa de produto

Um usuário me disse com clareza que o preço parecia alto para um trabalho que um app gratuito fazia. As reações fáceis seriam defender o preço, baixá-lo ou acrescentar recursos até uma tabela comparativa parecer mais longa. Nenhuma responderia à parte importante da mensagem.

Ferramentas gratuitas de fato resolvem muitos trabalhos de manutenção do Mac. A Mole CLI de código aberto continua gratuita, e o macOS já inclui o Monitor de Atividade, os ajustes de Armazenamento, o Finder e o Lixo. Um app pago precisa merecer o lugar tornando o trabalho repetido mais seguro, reunindo informação espalhada e ajudando quem nunca vai abrir o Terminal a entender o que vai acontecer antes de acontecer. Se uma ferramenta gratuita já resolve o trabalho de uma pessoa, recomendá-la é mais honesto do que inventar um motivo para vender outro app.

A objeção virou então um teste de posicionamento, não um convite para expandir o produto. Ela pergunta quem se beneficia o bastante do app nativo para pagar por ele, o que essa pessoa teria de montar de outro jeito e se a diferença fica visível durante um teste. Se essas respostas forem fracas, o marketing não as conserta.

Transforme a história numa suposição mudada

O retorno vira ruído quando cada mensagem entra no backlog do jeito que foi escrita. Uma pessoa pede um interruptor, outra pede um preço menor, e uma terceira descreve um erro que talvez nunca se repita. Tratar as três como votos de recurso perde o contexto que as tornava úteis.

Agora eu tento levar quatro fatos de uma conversa. O que a pessoa estava tentando fazer? Qual suposição do produto falhou? A falha afeta uma classe de pessoas ou só esta configuração? Um padrão melhor resolve, precisa de uma correção focada, ou o produto deve explicar por que não vai aceitar o pedido?

Isso é mais lento do que contar pedidos, mas cria menos ajustes e menos meias soluções. A conversa sobre Celsius mudou um padrão. A conversa sobre aparência expôs trabalho de acessibilidade inacabado. A objeção de preço esclareceu a fronteira entre a CLI gratuita e o app pago. A compra duplicada não precisava de recurso nenhum. Ela reforçou o padrão de cuidado esperado de um produto a quem se confiam arquivos pessoais.

Mantenha a conversa longa o bastante

Ainda atendo o suporte diretamente porque as primeiras conversas em geral são bagunçadas demais para resumir na primeira resposta. A pergunta inicial pode ser sobre uma licença enquanto o problema real é uma linguagem confusa sobre aparelhos. Um pedido de reembolso pode revelar uma promessa pouco clara na página do produto. Um pedido de ajuste pode ser evidência de que o padrão está errado para todo mundo.

A automação fica útil depois que a pergunta se repete, a resposta permanece estável e as exceções estão entendidas. Antes desse ponto, encurtar a conversa pode remover exatamente o detalhe que teria melhorado o produto. Escrevi mais sobre essa fronteira em Notas sobre construir um produto quieto.

Ainda erro algumas dessas decisões. O padrão de temperatura foi corrigido. A aparência escura fixa não foi. Parte do retorno vira código, parte vira uma fronteira de produto, e parte continua uma obrigação em aberto. A parte valiosa não é dizer sim a toda pessoa. É sair de cada conversa com uma ideia mais precisa de quem usa o produto e do que essa pessoa precisa para confiar nele.

O caminho mais longo, de um script privado até este app, está em Como o Mole cresceu de script de shell a app de Mac, e as escolhas de segurança por trás da exclusão que revisa primeiro estão em Projetar o Mole para ficar fora do caminho.