O dado que abre o diagnóstico é conhecido: o StatCounter, serviço de analytics de tráfego web global, reporta que dispositivos móveis respondem por cerca de 64% do tráfego global em 2025, com desktop próximo de 36% e tablets residuais. O número costuma ser tratado como encerramento de debate, como se a distribuição global determinasse, sozinha, o ponto de partida de qualquer projeto. A observação mais útil, no entanto, é que esse agregado esconde a variância que de fato importa. O mesmo relatório mostra África acima de 79% móvel, Japão em torno de 37%, Alemanha próxima de 42% e Estados Unidos na casa dos 54%. Dentro de um único produto, a variância por tela, por horário e por perfil de usuário costuma ser ainda maior do que a variância entre países.
Mobile-first foi formulado por Luke Wroblewski, designer de produto e ex-VP do Google, em 2009 e consolidado no livro Mobile First de 2011, como restrição produtiva. A ideia operacional era usar a tela menor como forçadora de prioridade: se tudo precisa caber em 320 pixels, o time é obrigado a decidir o que é essencial antes de decidir o que é desejável. Era uma heurística de design contra o inchaço de interfaces desktop que, na época, eram adaptadas pra celular por compressão. O método funcionou porque atacava um problema específico de um momento específico, em que a web estava migrando de uma distribuição majoritariamente desktop pra uma majoritariamente móvel, e em que os navegadores móveis ainda eram imaturos.
Quinze anos depois, a heurística virou dogma e o dogma virou cerimônia. Times começam wireframes no frame de 375 pixels por inércia, independentemente do produto. Um ERP interno usado oito horas por dia por operadores em estações de trabalho é prototipado primeiro no celular. Um painel de BI consumido por analistas em telas de 27 polegadas tem seu grid dimensionado a partir do mobile e depois expandido, o que produz densidade insuficiente onde densidade é o requisito central. O efeito observado é uma interface que serve mal o contexto dominante de uso porque foi otimizada pra um contexto marginal.
Pra mim, o ponto de partida correto reside no contexto de uso. Context-first significa que o processo de design começa pela caracterização da situação de uso: posição do usuário, tarefa em jogo, tempo disponível, custo de erro, densidade informacional necessária, dispositivo em que a tarefa é efetivamente executada. A distribuição de dispositivos passa a ser saída dessa análise, não entrada. Produtos B2B de uso intensivo tendem a concentrar uso em desktop porque a tarefa exige janelas amplas, múltiplos monitores, teclado e precisão de cursor. Produtos de consumo com sessões curtas que nascem geolocalizadas e são acionadas por notificação concentram uso em mobile pela mesma razão mecânica: a tarefa, ancorada em uma situação concreta, é o que seleciona o dispositivo.
Os trade-offs aparecem quando o time confunde context-first com desktop-first disfarçado. Começar pelo desktop sem disciplina de prioridade reintroduz o problema que o mobile-first resolveu: interfaces que acumulam elementos porque há espaço, e que degradam de forma imprevisível quando reduzidas. A resposta passa por adotar a restrição de prioridade independentemente do ponto de partida. A pergunta operacional é qual é o conjunto mínimo de elementos que torna a tarefa executável, e essa pergunta não depende de largura de viewport pra ser respondida.
Um caso recente ilustra a consequência. Um cliente operava uma plataforma de gestão documental cuja analytics indicava 91% de uso em desktop, em sessões médias de 42 minutos, com usuários manipulando múltiplos documentos em paralelo. O time de design havia adotado mobile-first como padrão de processo e entregou uma interface cujo grid, tipografia e densidade haviam sido definidos no frame de 390 pixels. No desktop, o resultado era uma tela com áreas vazias extensas, cards superdimensionados e uma lista de documentos que exibia quatro itens onde caberiam dezoito. A taxa de conclusão de tarefas em menos de três cliques estava em 47%. A refatoração começou pela caracterização do contexto real de uso, redefiniu a densidade a partir da resolução dominante e tratou o mobile como degradação controlada da experiência desktop. A mesma taxa subiu pra 78% em seis semanas, sem alteração de funcionalidade.
Responsive design, como técnica, é neutro em relação ao ponto de partida. O que deixou de ser neutro foi a cultura em volta dele. Na minha avaliação, mobile-first passou a carregar uma carga normativa que o método original não pretendia ter, e passou a ser aplicado como política em lugar de como hipótese. A hipótese, quando testada, frequentemente se confirma em produtos de consumo e falha em produtos operacionais. A política, por não ser testada, falha silenciosamente em ambos os casos, produzindo interfaces que servem mal o contexto majoritário e degradam pior ainda pra todo o resto.
O que morreu foi o automatismo, não a técnica. A decisão de ponto de partida precisa voltar a ser decisão, tomada por projeto, com base na distribuição real de uso e na natureza da tarefa. A distribuição global de dispositivos informa o cenário macro, mas não substitui a analytics do produto específico nem a caracterização do contexto em que a tarefa acontece. Design começa onde o trabalho acontece, e o trabalho raramente se concentra em um único dispositivo de forma homogênea o suficiente pra justificar uma regra universal.