BuildEnergy
Contexto
O caos da colcha de retalhos
Veja o caos. Por motivos de dados sensíveis, as interfaces acima estão borradas.
A pergunta que ficou depois daquela primeira percepção era: onde, exatamente, a jornada começava a se perder?
Como o projeto surgiu no contexto da minha mentoria de Design de Produto e eu não tinha acesso direto aos usuários finais, tive uma ideia para adaptar a investigação ao cenário que estava disponível.
Comecei pela própria operação em que observei minha própria rotina de acompanhamento. Depois, conversei com pessoas envolvidas no processo para compreender os trâmites e comportamentos que influenciavam a continuidade das solicitações.
Também mapeei a esteira de ponta a ponta e analisei os sistemas, registros e interfaces utilizados ao longo do processo, buscando entender as regras, burocracias e dependências que estruturavam aquela jornada.
Ao cruzar essas diferentes perspectivas, alguns padrões começaram a aparecer:
Aqui formulei uma pergunta guia para o projeto
Como seria tornar essa jornada mais rastreável para quem solicita e para quem acompanha?
Ao mapear a jornada através da construção do fluxo AS-IS, percebi que o fluxo principal se dividia em dois caminhos, com obra e sem obra para a conexão do serviço de rede.
Essa bifurcação ampliava a complexidade e mostrou que não seria viável resolver toda a jornada de uma vez.
Por isso, priorizei o fluxo sem obra. Isso permitiu estruturar a solução e preparar sua expansão para os demais cenários.
Imagem Fluxo AS-IS: reconstrução da jornada atual, evidenciando os dois caminhos e os diferentes pontos de intervenção.
A experiência do solicitante precisava resolver um problema específico. A informação certa precisava ser capturada de uma vez, sem depender de trocas informais até a aprovação para análise. Foi esse recorte que guiou o desenho dessa frente. Ela cobre da abertura do formulário até o encaminhamento do pedido.
A proposta era criar uma solução de protótipo web e mobile com duas frentes integradas.
No fluxo TO-BE, essas duas frentes se conectam: o que o solicitante preenche alimenta direto o acompanhamento e a execução do lado interno, sem precisar de retrabalho entre uma etapa e outra.
A meta era trazer rastreabilidade para essa jornada, mas nem tudo chegou no mesmo ritmo. Do lado interno, a proposta organiza a solicitação para que analista e técnico tenham uma visão compartilhada do andamento. Do lado do solicitante, essa visibilidade ainda não existe, a próxima versão trata isso
Imagem Fluxo TO-BE: nova lógica da jornada da solução, conectando a experiência do solicitante ao acompanhamento e à execução interna..
Processo: escolhendo em qual oportunidade focar energia
Nada disso saiu pronto na primeira tentativa.
Com o escopo da solução definido, a próxima questão não era simplesmente "o que podemos digitalizar?", mas "onde o produto realmente precisa intervir?"
Organizei os principais desafios encontrados e defini onde o produto deveria concentrar energia.
A partir disso, redesenhei o fluxo no formato TO-BE, considerando uma jornada contínua entre solicitação, análise, execução e confirmação.
Me guiei pelo princípio de que a proposta não era apenas substituir e-mails, planilhas e mensagens por telas.
O foco era organizar a informação para que cada pessoa soubesse o que precisava fazer, em que momento e por quê.
Para transformar essa lógica em experiência, precisei entender não só o que cada sistema fazia, mas o que acontecia quando a informação passava de um sistema, pessoa ou etapa pra outra. Salesforce e SAP registravam partes diferentes da solicitação, mas nenhum dos dois avisava quando a jornada parava de avançar. Isso ficava por conta de planilhas, alertas internos e comunicação entre analistas, gestores de conta e solicitantes.
Daí nasceram quatro módulos. O módulo de solicitação organiza a entrada de informação para viabilizar o rastreamento; os três módulos internos compartilham essa mesma lógica de rastreabilidade, como vemos a seguir:
Passei por diferentes versões de wireframes antes da alta fidelidade. Usei IA generativa nas primeiras explorações e recorri a rascunhos no papel pra testar alternativas de formulário e layout rapidamente. A partir daí, conduzi o refinamento visual e o desenvolvimento dos protótipos, trabalhando hierarquia, componentes, estados, responsividade. Pensando desde o início em web e mobile, considerando o contexto de uso dos técnicos durante a execução em campo.
Três princípios orientaram o design
Esses princípios orientaram as decisões de interface ao longo dos quatro módulos e também o refinamento visual do protótipo.
Como parte do meu processo de aprendizado contínuo, também documentei as quatro funcionalidades com histórias de usuário e critérios de aceitação, mesmo sendo um projeto que não chegou à etapa de desenvolvimento.
A documentação me ajudou a exercitar a tradução das decisões de design para uma linguagem mais próxima de produto e desenvolvimento, deixando mais claro o que a experiência deveria permitir, em quais condições e com qual comportamento esperado.
Formulário de solicitação, Kanban da fila de solicitação, etapas de análise, telas responsivas, biblioteca de componentes criada, wireframes com uso de IA.
Deseja explorar os protótipos?
Ao pensar em métricas, o que essa solução poderia mudar
O valor da proposta estava modificar dentro da interface, retirar a rastreabilidade da dependência de pessoas e colocá-la na própria experiência do produto.
Hipóteses
Indicador
O projeto foi desenvolvido como uma proposta de solução em protótipo. Não chegou à implementação em produção, então esses impactos são hipóteses a serem validadas. O que o projeto permitiu demonstrar foi a lógica da mudança na estrutura do fluxo da experiência, reduzindo os principais pontos de fricção encontrados no discovery.
Para Marcela, isso significa um pedido mais previsível do outro lado, que foi desenhado com essa intenção. A próxima etapa, em um cenário real, seria implementar, testar e medir se essas hipóteses se confirmariam.
Principais aprendizados
No início deste case, Marcela precisava entrar em contato para descobrir em que etapa estava sua solicitação. Na proposta que construí, para Marcela, isso significaria acompanhar o próprio pedido com mais clareza. Ainda está sem uma tela própria pra consultar status, mas já dentro de um fluxo pensado pra chegar lá.
Este foi um dos projetos em que mais precisei aprender fazendo. Não havia um processo pronto para seguir, nem acesso direto a todos os usuários ou dados que eu teria em um produto real. Precisei adaptar a descoberta, reconstruir a jornada, entender restrições de sistemas e transformar tudo isso em decisões de produto.
A mentoria esteve presente como suporte pontual. Os caminhos, explorações e decisões do projeto foram conduzidos por mim.
Mais do que chegar a uma solução visual, o projeto me ensinou a trabalhar com complexidade, restrições e informação fragmentada, buscando transformar tudo isso em uma experiência mais clara.