Uma ferramenta de colaboração para equipes remotas tinha um campo de perfil para fuso horário que quase ninguém preenchia corretamente, já que exigia que a pessoa selecionasse manualmente o próprio fuso horário em uma longa lista suspensa durante o onboarding, uma etapa fácil de pular ou de errar, principalmente para quem tinha acabado de se mudar ou estava viajando quando criou a conta. O resultado era um diretório da equipe cheio de dados de fuso horário desatualizados ou ausentes, nos quais ninguém confiava o suficiente para usar na hora de decidir se mandava ou não uma mensagem a um colega.
A empresa substituiu o campo manual por um automático. Em vez de pedir ao usuário que selecionasse o fuso horário, o app o resolvia diretamente a partir da conexão que fazia a requisição. /v1/ip recebia o endereço IP do usuário no login e retornava o país e as coordenadas, e essas coordenadas alimentavam /v1/timezone, que retornava o nome de fuso horário IANA daquela localização, mantido atualizado por meio de novas resoluções periódicas, em vez de fixar para sempre a localização em que o usuário por acaso estava na única vez em que preencheu um formulário.
O resultado visível no produto foi um pequeno acréscimo ao perfil de cada colega de equipe: um indicador de país e um horário local ao vivo, atualizado automaticamente, ao lado do nome no diretório da equipe e em qualquer conversa por mensagem direta. Um colega decidindo se mandava uma mensagem ou esperava até a manhã podia ver, de relance, se era um horário razoável onde a outra pessoa estava, sem precisar lembrar em que país ela morava nem fazer nenhuma conta de fuso horário.
A empresa manteve isso ajustável, em vez de totalmente automático e imutável, já que ocasionalmente um usuário queria substituir a localização detectada, por exemplo alguém trabalhando temporariamente de outro país que não o habitual e que preferia que o perfil mostrasse o seu fuso horário usual, e não o lugar de onde estava se conectando no momento. A detecção automática definia um padrão sensato que se atualizava sozinho no caso comum, enquanto uma substituição manual continuava disponível para a exceção.
Foi um recurso realmente pequeno em termos de esforço de engenharia, basicamente duas consultas encadeadas no login e uma pequena mudança de exibição no diretório da equipe, mas eliminou um atrito que vinha custando discretamente à equipe pequenas doses de sobrecarga de coordenação durante anos, o custo constante de não saber se aquele era um bom momento para falar com alguém sem perguntar antes ou simplesmente chutar.
O volume acompanhava as sessões de login, e não cada mensagem ou visualização de página, já que os dados de localização e de fuso horário eram atualizados periodicamente e não a cada requisição, o que manteve a carga de trabalho bem dentro da cota diária gratuita, mesmo para uma ferramenta de colaboração com uma base de usuários consideravelmente grande fazendo login ao longo do dia.
Padrões pequenos e discretos como este costumam importar mais, no acumulado, do que qualquer recurso chamativo isolado, já que eliminam um pouquinho de atrito de algo que acontece o tempo todo, em vez de resolver um problema que só aparece de vez em quando. A documentação dos dois endpoints está em /docs/ipv4-lookup/ e /docs/timezone-lookup/.