De Fricção a Fluxo

Este estudo de caso detalha a jornada de transformação do módulo de Conectividade da Digibee, evoluindo de um processo totalmente manual e dependente de suporte para uma experiência totalmente automatizada e self-service. O projeto, que se estendeu de setembro de 2023 a janeiro de 2025, representou muito mais do que uma melhoria incremental de produto; foi uma iniciativa fundamental para sustentar a ambiciosa expansão da empresa no mercado norte-americano.

Como o Product Designer líder desta iniciativa, fui responsável por conduzir o projeto desde a descoberta inicial e alinhamento estratégico até a arquitetura final e a entrega. Minha função envolveu a tradução de objetivos de negócios de alto nível em problemas de usuário acionáveis, a condução da pesquisa, a facilitação de workshops com stakeholders e a definição da arquitetura da informação que serviu como base para a nova experiência.

Este estudo de caso demonstrará como um processo de design centrado no usuário, fundamentado em uma profunda compreensão do negócio, não apenas resolveu um ponto de dor crítico para o cliente, mas, ao fazê-lo, apoiou diretamente a expansão multimilionária da Digibee nos EUA, reforçando sua proposta de valor principal contra concorrentes legados. A narrativa a seguir irá desconstruir o desafio, detalhar o processo de design e quantificar o impacto transformador que uma experiência de usuário bem executada pode ter nos resultados estratégicos de uma empresa.

Para compreender a importância crítica deste projeto, é essencial primeiro entender o contexto de negócios em que a Digibee operava. A empresa estava em um ponto de inflexão, com um capital significativo e um mandato claro para crescer. No entanto, um componente fundamental de sua plataforma estava em desacordo direto com essa missão, criando um gargalo que ameaçava minar todo o seu ímpeto.

O período de 2023 marcou uma fase de crescimento agressivo para a Digibee. Em meados do ano, a empresa garantiu uma rodada de financiamento Série B de 60 milhões de dólares, liderada pela Goldman Sachs Asset Management. Este capital não era apenas para a continuidade das operações; foi explicitamente destinado a alimentar a expansão para os Estados Unidos e Europa, os mercados mais competitivos e lucrativos do mundo para plataformas de integração como serviço (iPaaS).

A missão estratégica da Digibee era clara e ambiciosa: deslocar plataformas de integração legadas, mais caras e menos ágeis. Nascida no Brasil, a empresa estava determinada a provar que poderia ser uma "fornecedora global viável", e o sucesso no mercado americano era o teste decisivo.

A proposta de valor central da Digibee era sua identidade como uma plataforma iPaaS moderna, low-code e nativa da nuvem, projetada para ser "dez vezes mais rápida que outros sistemas". A empresa se posicionava como "Integração para o resto de nós", oferecendo o poder das marcas de "luxo" do setor a um custo total de propriedade significativamente menor. Essa promessa de velocidade, agilidade e, crucialmente, empoderamento do desenvolvedor, era o cerne de sua identidade e de sua estratégia de entrada no mercado.

Antes de iniciar o projeto, realizei uma análise comparativa para entender o cenário da experiência de conectividade no mercado de iPaaS. A conclusão foi alarmante: o autoatendimento não era um diferencial, era o padrão mínimo esperado. A competição não era sobre se você oferecia self-service, mas como.

Essa análise deixou claro que o processo manual da Digibee não era apenas um ponto de atrito; era uma desvantagem competitiva crítica. Enquanto os concorrentes debatiam a melhor abordagem de self-service (IDE vs. Web UI), a Digibee estava completamente fora da conversa, parecendo uma plataforma legada justamente no primeiro ponto de contato técnico com o cliente.

Aqui residia o conflito central que deu origem a este projeto. Enquanto o marketing e as vendas da Digibee prometiam uma experiência moderna e sem atritos, o processo fundamental de estabelecer a conectividade com a plataforma — o primeiro passo prático para qualquer novo cliente — era inteiramente manual. Isso criava uma desconexão gritante e prejudicial entre a promessa da marca e a realidade do usuário.

A evidência desse problema não era anedótica; estava claramente articulada em nossa pesquisa interna e na ferramenta de mapeamento estratégico, a Opportunity Solution Tree. As descobertas iniciais pintaram um quadro preocupante:

• "A insatisfação dos clientes tem grande impacto no churn": Este era o sinal de alerta mais claro. A insatisfação do cliente resultante desse processo manual não era um incômodo menor; era uma questão de negócios crítica que afetava diretamente a receita e a retenção de clientes.

• "O processo não é transparente e a falta de clareza... prejudica a sua experiência": A falta de automação foi explicitamente identificada como a causa raiz de uma experiência do usuário deficiente. Os clientes sentiam a fricção em cada etapa e, crucialmente, ficavam completamente no escuro sobre o status de suas solicitações.

• "Há frustração com problemas de conectividade relacionados à velocidade e confiabilidade": O processo manual não era apenas inconveniente; era lento e propenso a erros, gerando frustração e minando a confiança na plataforma desde o início do relacionamento com o cliente.

• "Os clientes possuem a necessidade de ter autonomia na configuração das conexões": Nossos usuários, principalmente desenvolvedores e equipes de TI, explicitamente queriam e precisavam de capacidades de autoatendimento. Ser forçado a depender de um processo de suporte para uma tarefa técnica fundamental ia contra suas expectativas e seu modo de trabalhar, o que estava em conflito direto com o objetivo da Digibee de ser a "escolha do desenvolvedor".

O processo de conectividade manual não era apenas uma falha de produto; era uma vulnerabilidade estratégica. Ele minava diretamente o principal diferencial competitivo da Digibee contra players legados como a MuleSoft, um concorrente explicitamente nomeado em nossa Opportunity Solution Tree e um alvo-chave em nossa estratégia de mercado. No ambiente de alto risco do mercado americano, onde as primeiras impressões são cruciais para a aquisição de novos clientes, essa fricção inicial tinha o potencial de envenenar todo o relacionamento e comprometer o retorno sobre o investimento de 60 milhões de dólares.

Com o problema estratégico claramente definido, a próxima fase foi desconstruí-lo em componentes gerenciáveis. Era crucial evitar saltar para soluções e, em vez disso, empregar um processo de design metódico para passar de um problema de negócios de alto nível para uma oportunidade de produto bem definida. Esta seção detalha as ferramentas e métodos que usei para trazer clareza e foco ao desafio.

Antes mesmo de traçarmos nosso mapa estratégico, mergulhei em uma vasta fase de descoberta qualitativa. Conduzi uma série de entrevistas aprofundadas com um espectro diversificado de stakeholders, tanto internos (engenheiros de suporte, arquitetos de solução, vendas) quanto externos (clientes recém-integrados e de longa data). Foi a partir da riqueza de insights e aprendizados destas conversas que a Opportunity Solution Tree nasceu. Ela não foi um exercício teórico; foi a destilação e a visualização de dores e oportunidades reais, que beberam diretamente da fonte de quem vivia o problema no dia a dia.

Este artefato serviu como nosso mapa estratégico, garantindo que cada atividade de design, cada decisão e cada linha de pesquisa estivessem diretamente conectadas aos objetivos de negócios centrais. O poder da árvore de oportunidades estava em sua capacidade de criar uma linha de visão clara desde o topo da estratégia de negócios até os problemas específicos do usuário que precisávamos resolver. Começamos com o objetivo de negócios mais alto, derivado diretamente da missão da empresa: "Aumentar nossa vantagem competitiva contra a Mulesoft no mercado dos EUA". A partir daí, traduzimos esse objetivo em oportunidades tangíveis e focadas no usuário, como:

• "Como podemos melhorar a satisfação dos clientes?"

• "Como podemos proporcionar autonomia para os clientes configurarem as suas conexões?"

• "Como podemos melhorar a nossa comunicação, tornando as informações mais claras e acessíveis?"

Este exercício garantiu que não estávamos resolvendo problemas de usuário em um vácuo. Cada oportunidade que exploramos estava intrinsecamente ligada ao objetivo maior de vencer no mercado americano. Isso me permitiu, como designer, articular o "porquê" por trás de cada decisão de design em termos que ressoavam com os stakeholders de negócios, engenharia e liderança. O alinhamento que essa ferramenta proporcionou foi fundamental para garantir o apoio e os recursos necessários para um projeto desta magnitude.

Com as oportunidades estratégicas mapeadas, o próximo passo foi gerenciar a incerteza. Em qualquer projeto complexo, há uma mistura do que sabemos, do que achamos que sabemos e do que não sabemos. Para organizar isso, utilizamos a Matriz CSD (Certezas, Suposições, Dúvidas) como nossa principal ferramenta para priorizar os esforços de pesquisa.

A coluna "Dúvidas" foi a mais crítica, pois continha as questões que precisavam ser respondidas para que pudéssemos projetar uma solução eficaz. Algumas das dúvidas mais impactantes que moldaram nossa fase de descoberta incluíram:

• "Quais dados e informações precisamos mostrar para o cliente?": Esta questão fundamental nos impediu de sobrecarregar a interface com informações desnecessárias. Ela nos forçou a descobrir, através da pesquisa com usuários, quais pontos de dados eram essenciais para a tomada de decisão e quais eram apenas ruído. Isso informou diretamente os requisitos de dados para a nova interface do usuário.

• "Como o cliente espera conseguir monitorar o status de conectividade?": Essa dúvida foi crucial porque expandiu o escopo do projeto para além da simples configuração inicial. Revelou uma necessidade latente de gerenciamento e monitoramento contínuo, um aspecto que o processo manual anterior negligenciava completamente.

• "A exposição via self-service será suficiente para o ZTNA ou para o VPN?": Esta questão demonstrou uma profunda consideração pelas restrições técnicas e pelos diferentes tipos de conexão que a plataforma suportava. Ela garantiu que nossa solução de design fosse tecnicamente viável e abrangesse os casos de uso mais importantes, como ZTNA (Zero Trust Network Access) e VPN, que também estão presentes na Arquitetura da Informação final.

Nosso processo foi sistemático. Usamos a matriz CSD como um roteiro para a pesquisa. Realizamos entrevistas com usuários, conduzimos sessões de descoberta técnica com engenheiros e analisamos centenas de tickets de suporte relacionados à conectividade. A cada nova evidência, movíamos itens das colunas "Dúvidas" e "Suposições" para a coluna "Certezas". Este processo rigoroso e baseado em evidências garantiu que não estávamos projetando com base em achismos, mas sim em um entendimento profundo e validado das necessidades do usuário e das realidades técnicas.

Para entender verdadeiramente a profundidade da dor do usuário, era essencial visualizar o estado "antes" da nossa solução. O diagrama de "User Activities and Tasks in Connectivity" serviu a esse propósito, pintando um quadro claro da jornada do usuário através do labirinto do processo manual.

Ao narrar as cinco colunas do diagrama, a fricção se tornava palpável. A coluna "Requesting Support or Assistance" não era um passo opcional para casos de exceção; era um passo obrigatório e central em todo o fluxo de trabalho. Tarefas que deveriam ser simples, como "New Connection" ou "Configuring an Existing Connection", inevitavelmente envolviam um longo processo de ida e volta por meio de tickets de suporte, e-mails e chamadas telefônicas. Isso criava atrasos, dependências e uma enorme sobrecarga de comunicação.

No entanto, a análise mais profunda revelou um problema mais sutil e talvez mais prejudicial. O processo antigo forçava uma transformação de papel no usuário. Ele pegava desenvolvedores altamente qualificados, pessoas acostumadas à autonomia, ao controle e à resolução de problemas, e os transformava em solicitantes passivos, forçados a esperar em uma fila. Isso não era apenas ineficiente; era desempoderador e profundamente frustrante.

A cadeia de eventos era clara: nosso público-alvo valoriza a eficiência e a autossuficiência. O processo manual os forçava a interromper seu trabalho, documentar um pedido e esperar que outra pessoa realizasse uma tarefa técnica que eles mesmos eram perfeitamente capazes de executar. Essa dependência forçada não apenas criava um gargalo no trabalho deles, mas, mais importante, minava seu senso de agência e expertise. O impacto emocional do processo antigo — a frustração, a sensação de estar bloqueado — era tão significativo quanto o impacto prático dos atrasos. Portanto, ficou claro que nossa solução precisava fazer mais do que apenas automatizar tarefas; ela precisava restaurar esse senso de agência e controle para o desenvolvedor, cumprindo a promessa da empresa de "capacitar os desenvolvedores a acelerar a inovação".

Com um entendimento profundo e multifacetado do problema, a equipe estava pronta para passar da análise à síntese. A fase de arquitetura da solução foi focada em traduzir os insights da pesquisa em um design tangível e funcional. O objetivo não era apenas criar uma interface, mas projetar um sistema que incorporasse os princípios de autonomia, clareza e eficiência que os usuários tanto desejavam.

A nova Arquitetura da Informação foi a resposta direta aos problemas descobertos. Ela foi construída sobre dois pilares fundamentais:

1. Autonomia: Dar aos usuários o poder de agir.

2. Visibilidade: Dar aos usuários a clareza para entender o estado do sistema em tempo real.

O maior ganho do projeto foi a combinação desses dois pilares. A visibilidade em tempo real do status das conexões foi um divisor de águas. Antes, os usuários enviavam uma solicitação para um "buraco negro" e não tinham ideia do que estava acontecendo. Agora, eles tinham um painel de controle vivo.

Cada elemento da nova Arquitetura da Informação foi uma decisão de design deliberada para servir a esses pilares:

• Por que "Status" é um item de nível superior? Isso aborda diretamente a necessidade de monitoramento ("Como o cliente espera conseguir monitorar o status?") identificada na Matriz CSD e na coluna "Monitoring Connection Status" do diagrama de atividades do usuário. Os status detalhados — como "Registered", "Up/down", "Pending" e "Expired" — fornecem a clareza e a visibilidade que os usuários não tinham. Como visto nas telas do MVP, esses status foram traduzidos em indicadores visuais coloridos (Online, Offline, Pending), permitindo que os usuários diagnosticassem a saúde de suas conexões em segundos.

• Por que "Actions" como "Recreate key" e "Delete" são proeminentes? Essas ações fornecem a autonomia para "configurarem as suas conexões" que foi identificada como uma oportunidade chave na Opportunity Solution Tree. Em vez de solicitar que o suporte execute essas tarefas, os usuários agora estão capacitados a gerenciar o ciclo de vida de suas conexões de forma independente.

O design final não surgiu do nada; foi o resultado de um processo estruturado de geração e validação de hipóteses. Ao revisitar a Opportunity Solution Tree, podemos conectar explicitamente a Arquitetura da Informação final às "Hipóteses de soluções" e ao "Experimento" escolhido.

Várias hipóteses foram consideradas, mas o experimento que selecionamos para prosseguir foi claro: "Automação do processo de solicitação (self-service) para melhorar a satisfação dos clientes". Esta foi a aposta de maior impacto. Acreditávamos que dar aos usuários controle total através de uma interface de autoatendimento resolveria a maioria dos pontos de dor identificados. O sucesso do design final e seu impacto positivo subsequente serviram como a validação definitiva dessa hipótese central.

Para comunicar a magnitude dessa transformação aos stakeholders e à equipe de desenvolvimento, uma narrativa visual de "antes e depois" foi extremamente eficaz.

Fluxo de Trabalho "Antes" (Processo Manual):

1. O usuário percebe a necessidade de uma nova conexão.

2. O usuário sai da plataforma Digibee.

3. O usuário abre seu cliente de e-mail ou sistema de tickets.

4. O usuário redige uma solicitação detalhada.

5. O usuário envia e aguarda.

6. A equipe de suporte da Digibee recebe, analisa e processa a solicitação.

7. A comunicação ocorre por e-mail se houverem dúvidas.

8. A conexão é finalmente configurada.

9. O usuário é notificado. (Tempo total: 2-5 dias úteis)

Fluxo de Trabalho "Depois" (Processo Self-Service via IA):

1. O usuário percebe a necessidade de uma nova conexão.

2. O usuário permanece na plataforma Digibee e navega até o módulo de Conexões.

3. O usuário preenche um formulário simples e intuitivo.

4. O usuário clica em "Criar".

5. A conexão é provisionada automaticamente. (Tempo total: < 5 minutos)

Essa comparação lado a lado tornou o valor da solução inegável. Ela transformou um processo fragmentado, lento e multicanal em uma experiência integrada, instantânea e totalmente contida na plataforma, alinhando finalmente a realidade do produto com a promessa da marca Digibee.

Interface construida seguindo o padrão já estabelecido da plataforma através de um Design System.

A entrega de uma solução de design bem arquitetada é apenas metade da história. O verdadeiro teste de sucesso reside no seu impacto tangível e mensurável. Esta seção final fecha o ciclo, conectando a solução de conectividade self-service de volta aos objetivos estratégicos de alto nível delineados na seção 1. O objetivo aqui é traduzir as melhorias na experiência do usuário em valor de negócio quantificável, demonstrando como o design serviu como um catalisador para o crescimento e a vantagem competitiva.

Para articular o impacto do projeto de forma clara e concisa, foi criado um scorecard que contrasta o estado "antes" do processo manual com o estado "depois" do novo módulo self-service. Este formato permite que stakeholders, desde executivos a gerentes de produto, compreendam rapidamente a magnitude da transformação.

Cada uma dessas métricas representa uma história de sucesso. A redução no tempo para conexão de dias para minutos não é apenas uma melhoria de eficiência; é uma mudança fundamental na experiência de onboarding. Para os novos clientes no mercado americano, essa primeira interação positiva e instantânea estabelece um tom de agilidade e poder que ressoa durante todo o ciclo de vida do cliente.

A introdução da visibilidade em tempo real abordou diretamente a ameaça de churn identificada no início do projeto. Ao eliminar a incerteza e a frustração de não saber o que estava acontecendo, a empresa não apenas reteve receita, mas também transformou potenciais detratores em promotores, um ativo inestimável em um novo mercado.

A drástica redução na carga da equipe de suporte teve um duplo benefício. Primeiro, reduziu os custos operacionais ao automatizar uma tarefa repetitiva e de baixo valor. Segundo, e talvez mais importante, permitiu que a equipe de suporte se concentrasse em ajudar os clientes com desafios de integração mais complexos e estratégicos, elevando a percepção do suporte de um centro de custos para um parceiro de sucesso do cliente.

Finalmente, o ganho em eficiência do desenvolvedor foi a realização da promessa central da Digibee. Ao devolver o controle aos desenvolvedores, a plataforma deixou de ser um obstáculo e se tornou um verdadeiro acelerador, permitindo que as equipes de clientes inovassem mais rapidamente e extraíssem mais valor da plataforma.

É crucial revisitar o objetivo original que deu início a todo este esforço, conforme articulado na Opportunity Solution Tree: "Aumentar nossa vantagem competitiva contra a Mulesoft no mercado dos EUA."

O projeto de conectividade self-service atingiu este objetivo de frente. Ao automatizar este processo central, entregamos uma experiência de usuário que é tangivelmente mais rápida, mais moderna e mais centrada no desenvolvedor do que a oferecida por plataformas legadas e incumbentes. Transformamos o que era uma vulnerabilidade estratégica — um ponto onde nosso produto se parecia perigosamente com a "velha guarda" — em um ponto de venda chave e um claro diferenciador.

Este projeto armou a equipe de vendas americana, que estava em rápido crescimento, com uma prova poderosa. Em demonstrações para clientes em potencial, eles podiam agora mostrar uma experiência de configuração de conectividade contínua e de autoatendimento em tempo real. Eles podiam contrastar diretamente essa experiência fluida com os pontos de atrito conhecidos dos concorrentes, transformando uma conversa sobre funcionalidades em uma conversa sobre velocidade, autonomia e tempo para obtenção de valor. A nova funcionalidade não era apenas um recurso; era uma personificação da proposta de valor da Digibee.

Conduzir este projeto do conceito à conclusão proporcionou vários aprendizados importantes que continuam a moldar minha abordagem ao design de produtos.

• Além dos Pixels: Meu principal aprendizado foi o profundo impacto que uma única experiência de usuário fundamental pode ter na estratégia de entrada de mercado de uma empresa inteira. Este projeto reforçou que o design de produto, quando executado estrategicamente, não se trata apenas de desenvolver funcionalidades, mas de mitigar riscos de objetivos de negócio. A fricção na conectividade era um risco direto para o sucesso da expansão de 60 milhões de dólares, e o design foi a ferramenta usada para neutralizar esse risco.

• O Poder de uma Visão Compartilhada: A Opportunity Solution Tree provou ser inestimável, não apenas para a equipe de design, mas como uma ferramenta de comunicação para alinhar stakeholders de engenharia, produto e liderança sobre por que este projeto era tão importante. Ela criou uma linguagem compartilhada que conectava o clique de um desenvolvedor na interface do usuário ao valor da empresa e à sua posição no mercado.

• Estabelecendo um Novo Padrão: O sucesso deste módulo self-service criou um modelo para a automação de outros processos manuais dentro da plataforma. Ele estabeleceu um novo padrão para a experiência do usuário na Digibee, elevando as expectativas internas e externas sobre o que significava usar uma plataforma de integração moderna. O projeto não apenas resolveu um problema, mas também iniciou um movimento em direção a uma experiência de produto mais coesa, autônoma e centrada no usuário em toda a suíte.