Transformar soluções técnicas em escolhas compreensíveis.
Uma empresa que procura uma solução low-code precisa entender o que ela faz, avaliar se atende à sua necessidade e saber como começar a usar. Do outro lado, quem desenvolve precisa apresentar, publicar e gerenciar seu produto. Na Run2Biz, trabalhei na construção da experiência que conectava esses interesses.
O desafio atravessava páginas públicas, catálogo, aquisição, publicação e gestão. Em colaboração com o Product Manager e tecnologia, estruturei fluxos, interfaces e uma base compartilhada de componentes a partir da identidade visual existente.
Minha atuação envolveu Product Design, arquitetura da informação, UX/UI, UX Writing, prototipação, Design System e documentação. O trabalho conectava decisões de negócio às informações e ações necessárias em cada momento da jornada.
Minha contribuição: dar forma ao marketplace como um produto com caminhos claros para descobrir, avaliar, adquirir, publicar e acompanhar soluções.
O marketplace precisava funcionar para quem vende e para quem escolhe.
A Run2Biz já tinha uma identidade visual e a proposta de conectar desenvolvedores de soluções low-code a empresas e usuários. Faltava construir a experiência digital dessa relação: como os produtos seriam apresentados, avaliados, adquiridos e administrados.
O trabalho considerou quatro perfis de referência. Desenvolvedores precisavam publicar e acompanhar suas soluções. Compradores técnicos buscavam documentação e confiança para decidir. Usuários menos técnicos precisavam compreender os benefícios. Administradores necessitavam de informações e critérios para revisar o catálogo.
Essas necessidades influenciavam tanto a estrutura quanto a linguagem. Uma descrição útil para o desenvolvedor poderia ser insuficiente para quem queria entender o benefício; uma página comercial, por sua vez, precisava oferecer profundidade para a avaliação técnica.
O desafio era organizar essa diferença: permitir que cada pessoa encontrasse a informação e o próximo passo adequados à sua tarefa.
Entender as perguntas antes de desenhar as respostas.
Nas conversas com stakeholders e na análise das necessidades do produto, trabalhamos a definição dos públicos e das tarefas que a plataforma deveria atender. Isso ajudou a transformar a proposta ampla de marketplace em problemas de experiência mais específicos.
Tarefas e responsabilidades
Para quem publicava, importava reunir as informações e conseguir avançar. Para quem comprava, era necessário compreender a solução e avaliar requisitos. Para a administração, o conteúdo enviado precisava permitir uma análise consistente. A linguagem técnica excessiva também exigia atenção ao público menos especializado.
Profundidade da informação
Organizar esses perfis ajudou a definir a profundidade de informação em cada área. Benefícios e exemplos apoiavam o entendimento inicial; documentação e detalhes sustentavam a avaliação; campos estruturados e estados apoiavam publicação e revisão.
O efeito sobre o projeto foi direto: deixamos de tratar o marketplace como uma única jornada e passamos a conectar tarefas com responsabilidades diferentes.
Escolher o essencial para a primeira experiência funcionar.
O benchmark registrado no case reuniu referências como Shopify, GitHub e Notion para analisar descoberta, sinais de confiança, detalhamento e conclusão da compra. O interesse estava na função de cada recurso: ajudar a encontrar, oferecer segurança para avaliar e orientar a continuidade.
Com o Product Manager, trabalhei a priorização dos fluxos essenciais. A organização registrada em MoSCoW colocou publicação, busca e checkout entre as necessidades centrais, com evolução da revisão administrativa e dos sinais de confiança como frentes complementares.
Essa definição ajudava a distribuir o esforço. Antes de multiplicar funcionalidades, a experiência precisava conectar um produto publicado a alguém capaz de encontrá-lo, compreendê-lo e adquiri-lo. Documentação e revisão também faziam parte dessa relação.
A prioridade era construir continuidade: cada etapa precisava oferecer informação suficiente para que a próxima pudesse acontecer.
Separar descoberta, avaliação e gestão deu função a cada área.
Estruturei a arquitetura conectando Home, marketplace, detalhe de produto, carrinho, checkout, dashboards e suporte. A Home apresentava a proposta; o catálogo apoiava exploração e busca; o detalhe aprofundava a avaliação; a compra organizava a conclusão.
Os ambientes de conta davam continuidade ao uso. Quem comprava precisava consultar produtos e atividades. Quem publicava precisava gerenciar suas soluções. A administração precisava revisar submissões e acompanhar o catálogo. Essa divisão orientava navegação, conteúdo e permissões.
A arquitetura também estabelecia relações entre áreas: os dados da publicação alimentavam a apresentação do produto e apoiavam a revisão; a aquisição levava a um ambiente de acompanhamento; suporte e documentação permaneciam acessíveis ao longo do uso.
A estrutura conectava o que antes era uma proposta de negócio: páginas, informações e tarefas passaram a compor percursos que podiam ser discutidos e detalhados.
Discutir a estrutura antes de aprofundar o visual.
Desenvolvi wireframes para explorar hierarquia, organização e navegação antes da UI final. Home, catálogo, detalhe, carrinho, checkout e dashboards eram tratados como partes de percursos relacionados, para avaliar como a pessoa passaria de uma tarefa à outra.
As conversas com o Product Manager, stakeholders e tecnologia ajudavam a ajustar etapas e considerar viabilidade. O desenho incluía regras, permissões e estados de interação, além da posição dos elementos na tela.
No fluxo de compra, por exemplo, a escolha precisava se conectar à revisão do item, ao preenchimento dos dados, ao pagamento e à confirmação. No de publicação, a sequência precisava organizar o envio e a revisão administrativa. Os wireframes permitiam discutir essas diferenças antes do acabamento.
Essa etapa deu clareza ao trabalho coletivo: a equipe podia avaliar caminhos e dependências olhando para a experiência inteira.
Publicar um produto era também preparar sua avaliação.
Uma publicação pronta para avaliação
A publicação exigia reunir conteúdo de naturezas diferentes. Trabalhei a organização dos formulários em uma sequência que passava por identificação e descrição, materiais visuais, condições comerciais, documentação e revisão antes do envio.
Orientar o preenchimento
Essa divisão tinha uma função: tornar compreensível o que era solicitado e permitir que o desenvolvedor reunisse o necessário para apresentar sua solução. Os estados de validação e as mensagens faziam parte do caminho, orientando o preenchimento e a continuidade.
Conectar publicação e revisão
O fluxo se estendia à administração. Depois da submissão, as informações precisavam apoiar a análise e a comunicação do resultado. A revisão era, portanto, uma responsabilidade conectada à publicação: o que se pedia no formulário deveria ser útil para quem avaliaria depois.
O cuidado estava na passagem entre pessoas: organizar o envio para que o produto pudesse ser compreendido, revisado e apresentado no marketplace.
A escolha do produto precisava levar a um ambiente de uso.
Organizei a aquisição como parte de uma jornada que continuava depois da compra. A avaliação no detalhe se conectava ao carrinho e ao checkout; os ambientes de conta reuniam o que a pessoa precisaria consultar e gerenciar em seguida.
As telas de dashboard mostram essa continuidade em tarefas concretas: acompanhar compras e produtos, consultar informações, acessar mensagens e solicitar suporte. Os formulários, os estados e os textos precisavam orientar tanto a conclusão da aquisição quanto o retorno ao ambiente.
A documentação pública do My Desk descreve essa conexão entre marketplace, cadastro, confirmação de e-mail, pagamento e painel de aplicações. Apresenta ainda áreas de assinaturas, suporte e documentação. É uma referência pública do papel do marketplace como entrada para o ecossistema.
O fluxo de aquisição tinha um destino: permitir que a pessoa chegasse ao produto e tivesse meios para continuar sua relação com ele.
Uma base comum para sustentar páginas e tarefas diferentes.
Criei uma base de componentes e padrões para dar consistência ao conjunto. O trabalho contemplou tipografia, cores, espaçamentos, iconografia, ilustrações e elementos reutilizáveis, com Bootstrap Grid como referência de estrutura.
Campos, botões, cards, tabelas e mensagens precisavam manter uma lógica compartilhada entre catálogo, formulários e dashboards. Isso permitia que a identidade existente se tornasse um sistema de produto, com regras para composição e interação.
Considerei responsividade, acessibilidade e documentação para apoiar desenvolvimento. O detalhamento incluía estados de foco, erro e carregamento, além dos textos que explicavam o preenchimento e a continuidade das ações.
A consistência vinha do comportamento, além da aparência: tarefas diferentes podiam compartilhar padrões reconhecíveis, enquanto cada área preservava a informação necessária ao seu público.
O valor da entrega está na conexão entre os caminhos.
O material do projeto reporta passagem de 12 para 7 etapas de publicação e de 52% para 81% na conversão em protótipo. Esses números pertencem à avaliação descrita no case original; a conversão em protótipo não representa vendas do marketplace em produção.
A contribuição do trabalho de design foi estruturar os fluxos de publicação, aquisição e aprovação, conectando páginas públicas, dashboards e suporte. A base de componentes e a documentação ofereciam uma referência compartilhada para discutir, implementar e evoluir essa experiência.
O resultado de design foi dar forma ao produto: a proposta de marketplace passou a contar com jornadas, interfaces e padrões relacionados entre si, considerando as responsabilidades de quem publica, compra e administra.
Uma estrutura para descobrir, adquirir e continuar.
fluxos críticos conectados: publicação, aquisição e aprovação
As entregas conectaram quatro perfis de referência e três fluxos críticos - publicação, aquisição e aprovação - em uma base compartilhada de experiência. Minha atuação atravessou arquitetura, formulários, interfaces, mensagens e componentes, em colaboração com produto e tecnologia.
uma experiência com responsabilidades diferentes
Desenvolvedores, compradores técnicos, usuários finais e administradores orientaram profundidade de informação, linguagem e tarefas.
uma estrutura de trabalho conectada
Publicar, adquirir e aprovar exigiam caminhos próprios e informações que se complementavam entre as etapas.
Continuidade pública do produto
Em outubro de 2026, o site da Run2Biz apresenta o marketplace 4biz One como acesso a soluções do ecossistema. A documentação pública conecta contratação, acesso às aplicações e gestão de assinaturas. Esses registros contextualizam a continuidade do produto ao longo de sua evolução.
O projeto ampliou minha prática na relação entre arquitetura, interface e regras de negócio. Simplificar uma plataforma com diferentes públicos exige decidir o que cada pessoa precisa compreender em cada momento. Foi nessa articulação que consegui transformar uma proposta ampla em fluxos e componentes capazes de orientar a construção do produto.