Mais jardineiros que arquitetos. Um produto não é um lançamento — é uma relação que se mantém

Há umas semanas ouvi uma entrevista de Ezra Klein a Stewart Brand. Brand, uma figura central da contracultura americana dos anos 60, que inspirou Steve Jobs, acaba de escrever um livro. Mas que não é sobre tecnologia nem inovação. É sobre manutenção.

Ouvi, pausei, rebobinei, voltei a ouvir. Era uma mensagem familiar. Brand estava a dar um nome a uma frustração que tenho há anos sem saber o que lhe chamar.

‍

O nome é maintenance. E perceber que existe uma comunidade de pensamento por trás do que eu sinto, fez-me parar.

‍

Veio-me à cabeça um projeto passado. O “Frankenstein” como lhe chamava a equipa (não era um elogio). Estávamos a melhorar a interface aos poucos, há mais de um ano, de forma cirúrgica. Não houve um grande lançamento. Nenhum case study. Só menos fricção para quem usava o produto todos os dias.

É um dos projetos de que tenho mais orgulho.

‍

‍

Uma civilização que não vê os maintainers

‍

Tudo o que está vivo passa grande parte do tempo a manter-se vivo: Os castores mantêm barragens. As plantas o solo à sua volta. Nós mantemos os nossos corpos, carros, amizades.

Mas cuidamos pouco dos produtos e serviços que construímos.

‍

“Obcecadas com a inovação, as sociedades modernas são cegas ao trabalho de manutenção. Quem cria é celebrado, mas quem mantém é invisível.”

Afirma Brand no livro Maintenance: Of Everything.

‍

É um padrão cultural amplo.

Há dezenas de séries sobre médicos e quase nenhuma sobre enfermeiros. Os médicos, como salvam, são os heróis. Já os enfermeiros, presentes 24 horas, mantendo o doente estável, raramente são os protagonistas. Os médicos de família, como também fazem manutenção, não usufruem do glamour do especialista de urgência.

‍

É exatamente como a diferença entre o redesign e a melhoria contínua.

‍

No mundo do design, os awards celebram lançamentos. Os portfólios destacam redesigns. Os case studies têm sempre a narrativa antes/depois.

Toda a gente quer ser disruptiva.

Toda a gente quer transformar indústrias.

‍

O que nunca aparece são as pequenas melhorias graduais de usabilidade, as correções de bugs, o trabalho silencioso de quem vai cuidando e afinando. Mas quando se analisa o que realmente sustenta o mundo, as redes de água, os hospitais, a internet. É manutenção.

‍

‍

Os exemplos de negligenciadas infraestruturas americanas — como o caso da ponte I-35W em Minneapolis que colapsou em 2007 e matou 13 pessoas — dão peso empírico ao argumento.

O subinvestimento em manutenção resultou em custos de reparação exponencialmente maiores do que teria custado a manutenção contínua. E a conta chegou mais tarde, muito mais alta.

‍

Há uma frase de Russell e Vinsel, no ensaio Hail the Maintainers, que resume tudo:

‍

“We talk constantly about innovation, but most of what we actually need is care.”

‍

‍

Contextualizando para o design:

‍

O feature creep domina as empresas. A app para telemóvel, a que os utilizadores usam todos os dias, tem problemas e precisa de atenção. Mas o investimento vai para a versão inovadora para smartwatch que ninguém vai usar. Ou para a integração do novo chatbot inteligente (que também não vai funcionar bem).

‍

Não é hipótese. Em 2024, a Air Canada foi condenada a indemnizar um passageiro porque o seu chatbot prometeu uma tarifa que já não existia. A IA respondia a partir de uma política antiga. A novidade não falhou por ser nova — falhou por também não ser mantida.

‍

‍

Já nas agências, o modelo de negócio é o redesign, é o novo produto, é criar outro touchpoint. A manutenção não tem entregável, não precisa de um workshop. E por isso, não acontece.

E, em instituições públicas, raramente existe uma equipa interna com capacidade para diagnosticar e mandato para fazer pequenas correções, ligeiras melhorias. É preciso um caderno de encargos, aguardar orçamento.

• Entretanto os problemas acumulam-se, visíveis para quem usa o sistema ou para quem passa pelo processo, mas invisíveis a quem tem poder de os resolver.
• Quando se avança, o projeto já escalou para um novo site completo, para uma nova medida política. É mais fácil de justificar. É melhor para mostrar trabalho e aparecer nas notícias.

‍

A burocracia não é inimiga da manutenção por acidente.

‍

‍

Redesign, o diagnóstico frequentemente errado

‍

Há um padrão que se repete com alguma regularidade. Um cliente chega a nós com um problema específico:

‍

“Os nossos utilizadores queixam-se que é difícil achar a informação na intranet.”

‍

Mas também já traz consigo a solução estrutural. Um redesign completo:

• Nova identidade visual.
• Nova homepage.
• Nova arquitetura.
• Novo tudo.

Apesar do problema ser apenas navegação, information scent e hierarquia de conteúdo. Coisas que se resolvem de forma cirúrgica, sem demolir o que existe.

‍

Outro caso: A administração de uma empresa decide que é altura de um rebranding. Porque há um reposicionamento estratégico, porque a tendência agora é o “neo-minimalismo quente e texturizado”, porque o concorrente também tem um logotipo novo.

Um rebranding implica, obviamente, um redesign porque“Temos de ser consistentes.”.

‍

E, de repente, uma simplificação do logotipo transforma-se numa reconstrução completa de um produto que, na sua maioria, funcionava.

Já que vamos mexer, adicionamos também outra funcionalidade, atualizamos os conteúdos. O projeto cresce, planeamento estica e o tempo para cada atividade encolhe. O projeto ainda não começou, mas já está atrasado.

‍

‍

O que podia ter sido uma intervenção focada transforma-se num projeto em escala. Pressão constante. Toda a gente a fazer tudo ao mesmo tempo, sem atenção para nada.

‍

O detalhe da interação, a necessidade do utilizador, resolver problemas, não é isso o foco. O foco é entregar, fechar, happy paths. De story em story, de sprint em sprint, rumo ao epic. Epic… fail.

‍

‍

Consistência

‍

Se os UX Designers, ou os Product Owners ou os Developers, fossem arquitetos, todas as divisões de uma casa tinham uma sanita. Porquê?

“Para manter a consistência”.

‍

Consistência é o princípio de design mais mal compreendido.

• É sinónimo de uma obsessão desmedida com a homogeneização das interfaces — visual, estrutural, horizontal.
• Uma procura que ofusca e se sobrepõe, a todos os outros princípios como minimalismo, poka-yoke ou affordance.

‍

A consistência deixou de ser um meio e passou a ser um fim.

‍

Mas, um utilizador real:

1. Navega verticalmente uma interface, não horizontalmente.
2. Não é designer. Não nota muitas destas ditas “inconsistências”. É a piada da mulher que cortou o cabelo e o marido não reparou.
3. Não veio para contemplar a interface, com todos os ecrãs à sua frente em simultâneo. Está, imaginem só, focado a tentar realizar uma tarefa específica, um ecrã de cada vez.

‍

‍

E o paradoxo é cruel porque redesigns completos produzem uma gigante inconsistência, essa sim com impacto real no utilizador. Vai ter de reaprender o que já sabia fazer porque a nova interface é inconsistente com a anterior. Tem novos padrões de interação, informação em novos locais,…

Em 2018, o redesign da Snapchat apagou mais de $1000 milhões em valor de mercado, só por obrigar as pessoas a reaprender o que já sabiam.

‍

Junta-se ao redesign uma interface hiper “consistente”, onde a estrutura dos ecrãs, os blocos de informação, os formulários não são ajustados nem às necessidades do utilizador nem ao contexto. Mas sim ajustados ao template, ao componente que já existe (é a nova roupagem do velho System-Centered Design).

No final do dia, temos uma experiência tão “consistente” quanto ineficiente.

‍

‍

A filosofia que já tínhamos

‍

Voltando ao maintenance. A nossa disciplina já tinha construído respostas a este problema do fazer sempre tudo de novo.

• As 10 heurísticas de Nielsen são diagnóstico. Observas, identificas, intervéns cirurgicamente. A sua discount usability é manutenção. Testes simples e rápidos, feitos cedo e com frequência. Nielsen não estava a criar apenas métodos, mas a propor uma filosofia diferente de design.
• Em Rocket Surgery Made Easy, Krug vai mais longe. Faz o teste mais acessível possível, identifica o problema mais importante, corrige apenas isso, sem perfecionismos. E repete para o mês que vem. Não resolvas tudo.

‍

‍

A engenharia de fiabilidade prática esta filosofia em sistemas críticos. É o minimal intervention — quando algo falha, mexe-se no mínimo necessário para restaurar o funcionamento.

Porque intervir demasiado num sistema complexo introduz novos riscos. E, se pararmos para pensar bem, muitos dos sites e apps que redesenhamos, são sistemas complexos.

‍

Mas, enquanto designers, enquanto agências:

1. Usamos regularmente os métodos do Nielsen para justificar redesigns, quando a sua intenção original era precisamente evitá-los.
2. Não menos frequente, em projetos de redesign completo, as equipas de UX acham que não faz sentido diagnosticar. E nem testam a interface atual com utilizadores.

‍

A consequência? O novo design perpetua problemas específicos que já existiam e que ninguém conhecia, e que destrói detalhes que funcionavam bem.

‍

‍

O que se perde quando se reconstrói tudo

‍

Há uns anos, fomos chamados por uma seguradora. Tinham feito um rebranding e, com ele, um redesign completo do site. Com a pressão dos prazos, a equipa de UX interna não conseguiu testar com utilizadores.

Pouco depois do lançamento, os pedidos de seguro não só não aumentaram, como caíram significativamente.

‍

O processo online era a principal fonte de receita e aquilo que distinguia a marca das outras. E decorria, ao mesmo tempo, uma campanha de marketing a promover a nova marca. Ou seja: estavam a pagar para atrair mais gente para um funil pior do que o anterior.

E não é um caso isolado.

‍

Quando a Marks & Spencer relançou o site em 2014, depois de 150 milhões de libras e 2 anos de trabalho, as vendas caíram 8% e seis milhões de clientes foram obrigados a recriar a conta do zero. Anos a conhecer utilizadores, deitados fora num lançamento.

‍

A pressão de timings, a imensidão de ecrãs, as reuniões alongadas — tudo isto faz com que se perca atenção ao detalhe do design, dos conteúdos, do código.

‍

Então, é comum acabarmos com algo bonito à primeira vista, mas que esconde uma pilha de pequenos problemas debaixo da pele:

‍

Pior. Não é raro mudanças bombásticas como estas serem introduzidas a ferros. Sem período de transição nem aviso prévio, e muito menos ajuda em contexto. Num dia a interface está assim, no dia seguinte o utilizador é surpreendido com algo assado. E agora? Leia o manual (se estiver atualizado).

O que vale é que o novo logotipo está fixe.

‍

Ao contrário, a manutenção cirúrgica toca apenas no que está partido. Não introduz risco onde não havia. Não destrói o que funcionava. É mais rápida, mais barata e menos stressante para toda a gente.

‍

‍

Porque se perpetua o problema?

‍

É fácil culpar os clientes. Mas a falha é igualmente nossa.

‍

O modelo de negócio das agências é construído em torno de projetos, não de relações contínuas:

1. O cliente sente segurança no fixed-cost.
2. Entregamos, lançamos, saímos.
3. O cliente não volta a chamar. Não porque o trabalho foi mau, mas porque não existe estrutura para isso.
4. Daqui a três anos, quando a fricção acumulada for insuportável, decide que é hora de um novo redesign.

‍

E o ciclo, expectavelmente repete-se. Como dizia Charlie Munger:

‍

“Show me the incentive and I’ll show you the outcome.”

‍

Em equipas internas, a situação é frequentemente idêntica: entrega-se a feature, passa-se à seguinte. O UX debt cresce no fundo dos backlogs, invisível, até ao dia em que não dá para ignorar mais.

‍

Foi o que aconteceu à Southwest em 2022. Um sistema de gestão de tripulações dos anos 90, cuja modernização foi adiada ano após ano, colapsou e cancelou perto de 17 mil voos numa semana. A dívida não desaparece quando se ignora — só vence juros. Neste caso: $1,1 mil milhões em receita perdida, multa de $140 milhões pelo Departamento de Transportes e mais de $600 milhões em reembolsos a passageiros.

‍

‍

Brand diz que possuir algo verdadeiramente não é só ter pagado por isso, é conhecer como funciona, saber diagnosticar e conseguir arranjar ou melhorar.

• Mas nas agências, entregamos produtos que os clientes possuem, mas não conseguem manter sozinhos.
• E nas equipas internas, o problema é o mesmo, apenas com outra cara. O produto existe, a equipa existe, mas a relação entre ambos termina no sprint.

‍

Ninguém possui verdadeiramente o que foi construído porque ninguém tem tempo, mandato ou incentivo.

‍

‍

O Frankenstein como ideal

‍

Voltando ao meu Frankenstein.

‍

O positivo daquela iniciativa era que cada intervenção estava motivada por um problema real, identificado com dados, e era resolvida de forma circunscrita.

Na verdade, era um redesign, mas era um redesign partido às postas. Um formulário, uma lista, uma funcionalidade de cada vez. Melhorar, testar, lançar. Inconsistente, mas mais funcional.

‍

E aos poucos emergiram rituais como:

• Design critiques com toda a equipa.
• O dia de visitar utilizadores nos seus escritórios e fábricas.

‍

Os rituais criaram motivação nos developers e na product owner. Despertaram atenção ao detalhe, vontade de ler reclamações e ouvir chamadas de apoio ao cliente. Não estávamos a desenhar nem a construir nada novo, apenas a manter. E era tão frustrante e desafiante quanto gratificante.

‍

‍

Brand descreve maintenance como uma prática contemplativa. Tarefas repetitivas de manutenção tratadas como rituais ganham impacto emocional. Catalizam a atenção ao que existe, ao invês de excitação para com o novo. Como o Kintsugi — reparar cerâmica partida com ouro. A fratura é celebrada. O objeto é agora mais valioso do que o original, porque é mais bonito e porque carrega uma história.

‍

Brand diz que:

‍

“O bom maintainer é um pessimista funcional, sempre à espera que algo falhe, em vez de assumir que está tudo bem.“

‍

Uma atitude muito diferente da que domina a nossa sociedade que celebra o otimismo do lançamento, mas que ignora o realismo do dia seguinte.

‍

‍

Cuidar como filosofia

‍

“Maintenance is what we call care when it is applied to things as opposed to people.”

apercebe-se Ezra Klein a certa altura na entrevista.

‍

O que me recordou uma fotografia que usávamos no onboarding de novos colaboradores da Tangível. De uma idosa com um saco de rodinhas, num passeio de calçada completamente estragado.

A foto exemplifica que, na base de um bom designer, há esta atenção com os pequenos problemas das pessoas. E há compaixão — o mobilizar para promover uma mudança positiva. Quando tiramos a foto, fizemo-lo precisamente para expor o problema à junta de freguesia.

‍

‍

Podemos decompor esta ideia do cuidar em quatro gestos, segundo Shaowen Bardzell. Naquela fotografia estão todos:

• Sensibilidade — reparar que o passeio estragado é um problema para alguém.
• Responsabilidade — decidir que não passamos ao lado, que aquilo é connosco.
• Competência — saber a quem expor e como resolver.
• Reatividade — voltar, semanas depois, para ver se a junta o arranjou.

O modelo atual costuma ter o primeiro mas tropeça frequentemente nos seguintes.

‍

Mas infelizmente, quando não cuidamos um produto, não é só o produto que se degrada. É também a nossa relação com as pessoas que o usam.

‍

Não será por acaso que “contínuo” está no nome de:

• Continuous Discovery — research com utilizadores não como um evento, mas um hábito contínuo.
• E Continuous Delivery — lançar software em pequenos lotes e com alta frequência, em detrimento das grandes releases.

Não são metodologias de inovação. São a enfermagem da experiência. A atenção permanente e a melhoria frequente.

‍

Por fim, se adicionarmos também à conversa o impacto ambiental do digital, exemplarmente documentado no livro World Wide Waste, temos um conjunto de perspetivas, todas com a mesma conclusão:

Um produto não é um objeto que se cria e se larga. É uma relação que se mantém.

‍

‍

Acessibilidade, o teste do algodão

‍

Há um domínio onde tudo isto é mais visível e mais consequente: a acessibilidade.

‍

Um produto acessível não é um produto que passou uma auditoria, uma vez. É um que é continuamente testado e corrigido à medida que evolui.Cada nova funcionalidade, cada alteração de conteúdo pode introduzir uma regressão.

‍

As WCAG são como as heurísticas de Nielsen: mais que uma checklist de lançamento são um ritual de cuidado contínuo.

E, quando uma equipa melhora um produto durante anos com atenção à acessibilidade, esse trabalho acumula. Um redesign profundo pode apagá-lo quase por completo. Não por má vontade. Apenas por falta de tempo.

‍

Kat Holmes explica que a exclusão raramente é intencional, mas é sistémica:

• Pessoas com deficiência visual, motora, cognitiva, são também quem têm menos alternativas. São as que mais dependem do site ou uma app.
• O custo da falta de manutenção, não é distribuído igualmente. Cai sobre quem já tem menos poder e menos alternativas.

‍

Sem acessibilidade não há experiência.

Suspeito que o estado da acessibilidade de um produto possa ser um bom indicador para o estado geral da sua manutenção. Produtos bem mantidos tendem a ter melhor acessibilidade.

‍

Quando a acessibilidade está degradada, é sinal de que a manutenção falhou mais amplamente.

‍

‍

Quando o redesign faz mesmo sentido

‍

É desonesto não dizer que há casos onde o redesign é a decisão certa.

• O site não é responsive e o uso mobile é desejado.
• O sistema foi feito em MS-DOS e não tem suporte.
• Precisamos fundir duas apps separadas numa só.
• Há uma mudança de estratégia: um novo mercado, novos utilizadores, novo modelo de negócio.
• A dívida técnica e de design é tão grande que manter é mais caro e mais arriscado do que reconstruir.

Nestes casos, um novo site, uma nova app, não é uma mania.

‍

A nossa casa é uma boa comparação. Enquanto vivo nela, mantenho-a — coloco cortinas, troco o frigorífico por um maior, ajusto o layout dos móveis da sala. Mas se tiver dois filhos e um T1, ou se arranjar emprego numa nova cidade, a manutenção não resolve o problema. Mudar de casa faz sentido.

‍

Então, fechem os olhos. Imaginem como era a vossa casa no primeiro mês em que se mudaram. Imaginem agora que ela estava igual ao original, passado este tempo todo. Zero melhorias. Inconcebível, não é? Mas esta é a realidade de muitos produtos e serviços digitais.

‍

‍

Isto é, manutenção e redesign não são opostos. São momentos diferentes na vida de um produto, de um serviço, de um processo. O problema não é o redesign em si — é o redesign como resposta automática a problemas de manutenção.

‍

E há um círculo virtuoso: um produto bem mantido é um produto mais adequado aos utilizadores. Mais adequado significa mais usado e mais recomendado. E quando um produto tem promotores genuínos — não porque foi relançado com fanfarra — mas porque simplesmente funciona bem:

• A necessidade de rebranding para recuperar interesse diminui.
• Os redesigns tornam-se mais espaçados.
• E quando acontecem, são mais justificados, mais calmos, mais eficazes.

‍

‍

O oposto? Um site ou uma app negligenciados acumulam fricção → A fricção afasta utilizadores, afasta funcionários, afasta cidadãos → As métricas caem → Decide fazer algo novo → Idealizado e construído, sob pressão → O novo produto tem novos problemas → O ciclo repete-se.

‍

A manutenção não elimina a inovação. Cria as condições para que a inovação seja uma escolha em vez de uma urgência.

‍

E vai mais longe: Manter um produto obriga a um contacto contínuo com quem o usa. Desse contacto nasce conhecimento. É esse conhecimento a verdadeira matéria-prima da inovação.

‍

Quem mantém é quem melhor sabe o que vale a pena inovar.

‍

‍

Quatro gestos, na prática

‍

Estes quatro gestos não são todos o mesmo tipo de trabalho, e perceber isso é meio caminho andado. A sensibilidade e a reatividade são sobretudo operações: a maquinaria — sensores, cadências, continuous discovery e delivery — que torna o cuidado contínuo, e não pontual. A competência é craft: corrigir bem, sem demolir. E a responsabilidade é cultura — a mais difícil das três.

‍

Uma sugestão de como podemos concretizar a adordagem de Bardzell no dia a dia de uma equipa de UX ou de produto:

‍

‍

Sensibilidade — notar que algo precisa de atenção

• Sensores: logs da pesquisa interna, reclamações, tickets, erros de formulário, performance.
• Rituais: ouvir chamadas de apoio, visitar utilizadores, ler reviews, key driver analysis.
• A postura do “pessimista funcional”.

‍

Responsabilidade — assumir o problema e fazer os outros assumi-lo

• Contar a fricção sentida, não a estatística.
• Ligar o problema a receita ou a custos.
• Nutrir a relação com a equipa e as chefias — as “amizades” que criam vontade de cuidar.
• Definir um owner e um modelo de retainer que torne isto estrutural.
• Dizer “não” ao que não é prioritário.

‍

Competência — corrigir bem

• Testar o que existe. Não saltar o diagnóstico.
• Intervenção mínima e cirúrgica.
• Priorizar: red routes, severidade, Kano de atributos atuais.
• Corrigir sem demolir. Ex: saber o suficiente de acessibilidade.
• Introduzir a mudança gradual, com transição suave.

‍

Reatividade — responder aos resultados ao longo do tempo

• Verificar que a correção ficou como desenhado
• Checks de acessibilidade a cada release.
• Cadência fixa de revisão de fricção.
• Voltar a quem reportou e fechar o ciclo com a pessoa
• Continuous Discovery & Delivery.

‍

Adapta e expande este modelo ao contexto da tua equipa, do teu produto, da maturidade da tua organização.

‍

‍

O que precisamos de mudar

‍

Enquanto um dos líderes de uma agência, reconheço-me em tudo o que critiquei: bom a desenhar mas mau a ficar. Mau também a reconhecer e elogiar os researchers, writers e developers maintainers da Tangível.

‍

No design, imaginamo-nos como arquitetos. Precisamos de nos ver mais como jardineiros.

‍

Voltando à fotografia da idosa no passeio estragado. Não a guardámos para falar de empatia, mas para lembrar que o trabalho começa quando alguém repara no que está partido e decide não passar ao lado. É boa vontade. Mas os incentivos não ajudam, empurram para o lado contrário. A falta de boa vontade não é o problema. Depender só dela é.

‍

Premiamos lançamentos, redesigns, portfólios.

‍

Imaginem o contrário…

• Imaginem um prémio para o problema que nunca chegou a existir.
• Imaginem uma linha no currículo: “Ajudei a corrigir e a melhorar este produto durante seis anos, sem o relançar uma única vez.”
• Imaginem o nosso CEO a anunciar que o melhor trabalho que fizemos este ano não foi um redesign — foi convencer um cliente a não o fazer.
• Imaginem um dia especial por ano para celebrarmos os maintainers da nossa empresa.

‍

Não é preciso esperar. Amanhã de manhã, olha para um produto que lançaste e deixaste para trás. Ouve uma chamada do apoio ao cliente. Senta-te meia hora ao lado de quem o usa. Puxa a carroça para a correção do problema mais óbvio. Só esse. E volta daqui a um mês. Não é um projeto. É um hábito.

‍

UX Maintenance é o trabalho que ninguém celebra.

‍

Bora lá começar a celebrá-lo 🙂.

‍