Você já entrou numa sala de reunião e viu uma parede inteira coberta de post-its coloridos, setas em todas as direções e diagramas que parecem mais complexos que o mapa do metrô de Tóquio? Parabéns, você testemunhou o momento exato em que o service design virou religião corporativa.
O culto da complexidade
Não me entenda mal: service blueprints são ferramentas poderosas. Mas em algum momento entre 2015 e hoje, eles se transformaram de instrumentos práticos em altares sagrados onde sacrificamos clareza em nome da "completude".
Já vi empresas gastarem 3 meses documentando cada micro-interação de um serviço que poderia ser melhorado com uma conversa de 30 minutos com o atendente do balcão. É como usar um microscópio eletrônico para encontrar as chaves do carro (spoiler: estavam no bolso).
A síndrome do "quanto mais, melhor"
Existe uma pressão não-dita no mundo do design: se seu blueprint não tem pelo menos 15 swim lanes, 47 touchpoints e uma legenda com 23 símbolos diferentes, você não está fazendo service design "de verdade".
Mentira.
Um blueprint eficaz é aquele que responde a pergunta que você precisa responder. Ponto. Se isso significa rabiscar num guardanapo as 3 etapas principais do seu serviço, esse guardanapo vale mais que 100 templates do Miro.
Como saber quanto é suficiente?
Aqui vai um framework simples (e sem post-its):
Pergunte-se: qual decisão este blueprint vai ajudar a tomar?
Melhorar o tempo de espera? Foque nos momentos de espera e nos processos de bastidor relacionados
Reduzir reclamações? Mapeie apenas os pontos de maior fricção
Integrar um novo sistema? Documente só as integrações críticas
Se você não consegue explicar como cada elemento do seu blueprint vai influenciar uma decisão real, delete. Sim, delete. Seu blueprint vai agradecer.
Exemplos do mundo real (nomes mudados para proteger os envergonhados)
Caso 1: A startup que quase morreu de documentação Uma fintech gastou 2 meses criando um service blueprint "completo" do seu app. Enquanto isso, 40% dos usuários abandonavam o cadastro no terceiro campo. Bastaria testar a tela de onboarding, mas estavam ocupados demais escolhendo se o ícone do backend deveria ser um servidor ou uma nuvem.
Caso 2: O guardanapo de 2 milhões Um restaurante melhorou seu delivery redesenhando o processo em 3 linhas num guardanapo: cozinha → motoboy → cliente. Identificaram que o problema era a comunicação entre cozinha e entregadores. Solução: um sino. Aumento de 30% na satisfação. Tempo gasto: 1 tarde.
O minimalismo aplicado ao service design
Comece sempre com o mínimo viável:
Quem faz o quê
Onde estão os problemas
O que podemos testar amanhã
Só adicione complexidade quando a simplicidade não responder mais suas perguntas. É como temperar comida: você sempre pode adicionar mais sal, mas não pode tirar.
A provocação do dia
Pegue aquele blueprint super complexo que você fez no último projeto. Agora responda: quantas decisões foram realmente tomadas baseadas nele? Quantas dessas decisões precisavam de toda aquela complexidade?
Se a resposta te deixou desconfortável, bem-vindo ao clube. A boa notícia é que no próximo projeto você pode escolher diferente.
Lembre-se: service blueprint é ferramenta, não arte. E a melhor ferramenta é aquela que você realmente usa.
P.S.: Se você chegou até aqui e está se sentindo pessoalmente atacado, respira. Todos nós já fizemos blueprints desnecessariamente complexos. O importante é aprender a dose certa para cada situação. E sim, às vezes a dose certa é zero.