eu soujornalistapesquisadoradesignerestrategistaa Fer
montando a mesa
clique pra pular
Fernanda Magalhães

oi

Eu sou
a Fer

Clique pra me conhecer um pouco melhor

o que eu faço

Desenho
produtoPenso negócio

Gosto de trabalhar perto da estratégia, entendendo o problema pra além da interface. Pra mim, uma boa solução precisa fazer sentido pra quem usa e pro negócio.

de onde eu venho

Do jornalismo
ao designDo design ao negócio

Passei por comunicação, pesquisa, produto e liderança. Em cada experiência, fui ampliando o olhar sobre os problemas que o design pode ajudar a resolver.

como eu trabalho

Prefiro
perguntas boasa briefings fechados

Gosto de ter autonomia pra propor caminhos, construir com outras pessoas e validar decisões. Quando ainda não temos evidências, começamos com hipóteses e testamos.

Ver o case da ElevifyVamos conversar

oi, eu sou a Fer

Designer de produtoEstrategista de negócio

HojeLead Product & Design B2B · ElevifyAntesStaff Product Designer · Deel

Conecto design, produto e estratégia para transformar problemas em soluções que façam sentido para as pessoas e gerem valor para o negócio.

Vamos conversar
clique ouespaçotoque pra continuar
Fernanda Magalhães de perfil, retrato em preto e branco com retícula

elevify · b2b

Do catálogo individuala um negócio para empresas

A Elevify já tinha cursos, tráfego orgânico e clientes em diferentes países. Meu desafio foi transformar essa estrutura em uma oferta para empresas.

Assumi a estratégia do negócio, defini ofertas e preços, desenhei a experiência de compra e realizei as primeiras vendas.

Meu papel
Estratégia de produto e de negócio, precificação, design, prototipação e QATime
Um engenheiro front-end dedicado, apoio de engenharia B2C, SEO e CEOPeríodo
Maio a agosto de 2026
Desafio

Adaptar uma experiência individual para quem compra e gerencia treinamentos de equipes.

Decisão

Criar uma oferta B2B aproveitando o catálogo e a infraestrutura existentes.

Resultado

67 registros de empresas compradoras, 28 países e 452 alunos atendidos.

01

As empresas já chegavam.Faltava uma oferta para elas.

Encontrei mais de 200 domínios corporativos na base da Elevify. Era um sinal de oportunidade, mas não comprovava compras para as equipes.

Conversei com potenciais compradores para entender suas necessidades e decidi validar a demanda com base no catálogo existente.

Hipótese

Se apresentássemos uma oferta corporativa em que as empresas já encontrassem os cursos, poderíamos converter parte dessa demanda em vendas B2B.

Página de curso original da Elevify, versão desktop
Página de curso original da Elevify, versão mobile
A experiência original atendia quem estudava individualmente, não quem comprava para uma equipe.
02

O mesmo conteúdoprecisava de outra proposta de valor

Nas primeiras vendas, identifiquei dois problemas: o Pro custava mais que no B2C e o Flex personalizado tinha o mesmo preço de um curso pronto.

Pro · reduzir a barreira de compra

Igualei inicialmente o preço ao B2C e acrescentei relatórios de desempenho para gestores.

Entrega manual. Na validação, produzi os relatórios manualmente para testar seu valor antes de automatizar.

Flex · valorizar a personalização

Propus cobrar o dobro do Pro para diferenciar a oferta personalizada e melhorar sua margem.

Aprender antes de automatizar

As vendas mostraram como preço, certificação, relatórios e personalização tinham pesos diferentes para cada comprador.

03

Da oferta àexperiência de compra

Desenhei a landing B2B e adaptei o catálogo para apresentar os cursos como treinamentos para equipes.

Reaproveitei a infraestrutura B2C para lançar mais rápido e aprender com compradores reais, sem testes prévios de usabilidade.

O mesmo curso, duas decisões: estudar individualmente ou treinar uma equipe.

04

A iniciativa começou a gerar vendas.E novas perguntas.

Estruturei a iniciativa entre maio e agosto. Os resultados refletem a operação de junho ao início de outubro.

452Alunos atendidos.
28Países com compras.
67Registros de empresas compradoras, antes da deduplicação.

Outros indicadores · 1.760 contatos e 64 negócios ganhos no CRM, aproximadamente 26% dos negócios registrados.

Resultados da iniciativa B2B como um todo, sem atribuição isolada às mudanças de interface.

O comprador era mais diverso do que parecia

Cerca de 75% dos contatos não tinham empresa identificável pelo domínio. A mediana era de 2,5 pedidos por empresa.

Isso mostrou a importância de atender também equipes pequenas e compradores com e-mails pessoais.

05

Das primeiras vendasà próxima decisão de produto

Os aprendizados comerciais ajudaram a identificar quatro perfis de compradores e orientar a evolução do produto.

Conformidade

Precisa cumprir exigências de qualificação ou certificação.

Padrão de serviço

Quer padronizar o treinamento da equipe.

Método específico

Quer transformar processos internos em cursos.

Escala operacional

Precisa distribuir acessos e acompanhar treinamentos com autonomia.

Próxima etapa · compra e gestão autônomas

Priorizei um fluxo para comprar cursos, distribuir acessos e acompanhar equipes sem depender da operação comercial.

Transformei uma oportunidade identificada na base de usuários em uma oferta comercial, uma experiência de compra e aprendizados para orientar a evolução do produto.

Mudança de prioridade

Antes do lançamento, o B2B foi despriorizado em favor do B2C. O fluxo permaneceu em desenvolvimento, sem resultados de lançamento.

zé delivery · 2020

O endereço
estava erradoMas o problema não era tão simples

No final de 2020, os cancelamentos feitos por entregadores começaram a aumentar, e um dos motivos mais críticos era o endereço informado incorretamente. Parecia um problema de cadastro. Antes de mudar a interface, precisávamos entender o que acontecia entre a escolha do endereço e a tentativa de entrega.

Papel
Product designer: investigação, priorização e desenho da soluçãoCom
PM, engenharia e stakeholders da operaçãoTema
Onboarding, endereço, operação de entregas
Problema

Cancelamentos por "endereço errado" cresciam. Um pedido cancelado mobilizava a operação de entrega sem concluir a venda, e o motivo genérico escondia situações diferentes.

Hipótese escolhida

Ajudar a pessoa a confirmar o endereço quando estivesse num lugar diferente do endereço salvo. Uma intervenção pequena, que dava pra testar e medir.

Resultado

No teste A/B, 22% menos cancelamentos por entregadores por endereço errado e 32% menos por usuários. R$ 4,3 mi de GMV anual adicional, conforme o material original.

01

Contexto

A partir de um trabalho de organização das métricas do time com o framework HEART, identificamos que os cancelamentos por endereço errado estavam entre os problemas que precisávamos investigar.

O objetivo era entender por que esses cancelamentos aconteciam e encontrar uma maneira de reduzi-los. O impacto não era só na experiência de quem comprava: um pedido cancelado também mobilizava a operação de entrega sem concluir a venda.

Entregador de moto, de capacete amarelo, numa estrada
Cada cancelamento por endereço errado era uma entrega que saiu e voltou sem venda.
02

Descoberta

"O dado mostrava o problema. Não explicava tudo."

Cruzei eventos e métricas do produto, histórico de pedidos e cancelamentos, entrevistas com usuários e stakeholders, contatos de entregadores e comentários sobre pedidos. Apareceram padrões: gente que repetia o pedido em outro endereço depois de um cancelamento, gente que conseguia receber no mesmo endereço numa tentativa posterior, endereços sem histórico de entrega bem-sucedida. "Endereço errado" não descrevia uma situação só. Uma das hipóteses mais promissoras: algumas pessoas esqueciam de trocar o endereço quando estavam em outro lugar.

Cancelamento do pedido por motivo de endereçoExplorar por que distribuidor, entregador e usuário cancelavam o pedido por endereço errado
ExperimentosNós fizemos isso…
Análise dos dados da pesquisa sobre cancelamento
Cancelamento do pedido por motivo de endereçoExplorar por que distribuidor, entregador e usuário cancelavam o pedido por endereço errado
ExperimentosNós fizemos isso…
Análise dos dados da pesquisa sobre cancelamento
Fatos…e descobrimos isso…
Quem recebe um cancelamento repete o pedido em um endereço novo
Cancelamento do pedido por motivo de endereçoExplorar por que distribuidor, entregador e usuário cancelavam o pedido por endereço errado
ExperimentosNós fizemos isso…
Análise dos dados da pesquisa sobre cancelamento
Fatos…e descobrimos isso…
Quem recebe um cancelamento repete o pedido em um endereço novo
Insights…o que nos faz pensar isso…
As pessoas esquecem de alterar o endereço depois de um pedido, quando mudam de lugar
Cancelamento do pedido por motivo de endereçoExplorar por que distribuidor, entregador e usuário cancelavam o pedido por endereço errado
ExperimentosNós fizemos isso…
Análise dos dados da pesquisa sobre cancelamento
Fatos…e descobrimos isso…
Quem recebe um cancelamento repete o pedido em um endereço novo
Insights…o que nos faz pensar isso…
As pessoas esquecem de alterar o endereço depois de um pedido, quando mudam de lugar
Conclusões…então, faremos isso.
Lembrar as pessoas do endereço em que estão pode ajudar a reduzir a taxa de cancelamento
Cancelamento do pedido por motivo de endereçoExplorar por que distribuidor, entregador e usuário cancelavam o pedido por endereço errado
ExperimentosNós fizemos isso…
Análise dos dados da pesquisa sobre cancelamento
Fatos…e descobrimos isso…
Quem recebe um cancelamento repete o pedido em um endereço novo
Insights…o que nos faz pensar isso…
As pessoas esquecem de alterar o endereço depois de um pedido, quando mudam de lugar
Conclusões…então, faremos isso.
Lembrar as pessoas do endereço em que estão pode ajudar a reduzir a taxa de cancelamento
Próximos passosQuais as oportunidades pro futuro?
Ideação sobre “lembrar as pessoas do endereço”
Começa pelo que a gente fez: o método, o estudo ou a fonte de dados.
03

Priorização

Organizei os achados com uma adaptação de Atomic Research: evidências viravam insights, e os insights ajudavam a formular hipóteses de solução. Agrupamos as hipóteses por afinidade, ligamos cada uma às evidências de origem e usamos uma pontuação de confiança pra apoiar a priorização.

A hipótese escolhida foi ajudar a pessoa a confirmar o endereço quando estivesse num local diferente do salvo. Não era resolver todas as causas de uma vez; era começar por um comportamento identificado na pesquisa, com uma intervenção que a gente podia testar.

Tema 01→ H1
Tema 02→ H2
Tema 03→ H3
Tema 04→ H4
Tema 05→ H5
Tema 06→ H6
Tema 07→ H7
Tema 08→ H8
Peso de confiança por fonte
Banco de dados3CX3Benchmark1Review de usuários1Entrevista com usuários1Hotjar0,5Análise heurística0,4Aspectos técnicos0,2Desk research0,1
Reduzir pedidos cancelados por endereço errado pela pessoa entregadora
I1 · Garantir confirmação de endereço
P1 · Hipótese priorizadaConfirmar o endereço de quem geralmente esquece de alterar quando muda o local onde está
Agrupei os insights por afinidade. Apareceram oito temas, e cada um virou uma hipótese.
04

Solução

A pergunta que guiou a ideação: como ajudar alguém a lembrar de mudar o endereço quando estiver em outro lugar? Fizemos sessões de ideação com o time e stakeholders, olhamos referências de outros apps e desenhamos alternativas em wireframes. A proposta: identificar quando a localização atual estivesse distante do endereço selecionado e pedir uma confirmação antes de a pessoa avançar. Como mexia com localização, detalhei os critérios de aceite com a engenharia. Três alternativas de interface foram pra teste.

Wireframes desenhados à mão no papel com alternativas para a confirmação de endereço
A. Alternativas. Maneiras diferentes de chamar atenção pro endereço antes de seguir, primeiro no papel.
Tela do app com o modal Confirmar endereço e os botões Sim, o endereço tá certo e Editar endereço
B. Variante selecionada. Um modal com a opção de confirmar ou alterar o endereço.
05

Validação

Primeiro entender a interação, depois medir o impacto. Nos testes de usabilidade, observamos se as pessoas percebiam a confirmação, entendiam por que ela aparecia e conseguiam manter ou corrigir o endereço. A terceira variante foi selecionada.

Em seguida, estruturamos um teste A/B: o modal aparecia quando a pessoa estivesse fora de um determinado raio do endereço informado. A métrica principal foi a taxa de cancelamento por entregadores por esse motivo; também acompanhamos mudanças de endereço e cancelamentos feitos pelos próprios usuários.

Protótipo usado nos testes de usabilidade, com as variantes de confirmação.
06

Resultado

Uma mudança pequena na tela. Um impacto grande na operação.

−22%na taxa de cancelamento por entregadores por endereço errado
−32%na taxa de cancelamento por usuários por endereço errado
R$ 4,3 mide GMV anual adicional, conforme reportado no material original
−12%na taxa geral de cancelamento por entregadores
−7,4%na taxa geral de cancelamento por usuários

Os números são do estudo original; período do teste e método do cálculo do GMV precisam ser confirmados antes de publicar como resultado final.
O que eu levo · A parte mais importante não foi desenhar um modal. Foi sair de um motivo genérico de cancelamento, investigar os comportamentos por trás dele e escolher uma intervenção simples, que desse pra validar e medir.

deel · eor · 2025

De cinco dias de esperaa cartas de emprego com IA

Pessoas contratadas pela Deel via EOR precisam de cartas de emprego pra abrir conta em banco, alugar um imóvel ou tirar visto. Uma carta personalizada dependia do time de HRX e podia levar até cinco dias.

Desenhei uma experiência com IA pra que a própria pessoa pedisse e gerasse a carta, usando os dados de emprego que a Deel já tinha.

Meu papel
Product design, design de interação com IA, mapeamento da jornada, UX writing e prototipaçãoTime
EOR Active Contracts & Terminations, com PM e engenhariaPeríodo
Discovery e design em 2025 · lançado em 27/11/2025
Desafio

Agilizar o pedido de cartas que variam por país e por instituição, sem perder precisão nem confiança.

Decisão

Combinar o pedido em linguagem natural com dados estruturados de emprego e uma etapa de revisão, em vez de deixar a IA escrever livremente.

Resultado

Lançado pra todas as pessoas em EOR. 915 cartas geradas nos primeiros meses.

01

Um pedido simplesainda era um processo manual

Cartas de verificação de emprego resolvem tarefas do dia a dia. Só que os pedidos personalizados dependiam do HRX pra preparar e enviar o documento certo, e o processo podia levar até cinco dias.

Ao mesmo tempo, verificação de emprego e de salário representava cerca de 60% dos pedidos de documentos: um volume operacional recorrente.

Hipótese

Se as pessoas pudessem descrever o que precisam e revisar uma carta montada com dados confiáveis, muitos pedidos deixariam de exigir preparo manual do RH.

Antes · pedido de carta personalizada
  1. Pessoapede a carta
  2. HRXrecebe o pedido
  3. Preparomanual
  4. Entregado documento
até 5 dias
~60%dos pedidos de documentos eram de verificação de emprego e salário
1–3dados extras, além do que a Deel já tinha, bastavam na maioria dos pedidos
  • 01

    A informação já existia. O que faltava era pouco e específico.

  • 02

    As pessoas sabiam o que precisavam. Conseguiam descrever o que o banco ou o consulado pedia, mesmo sem saber o nome interno do campo.

  • 03

    O contexto mudava a carta. Instituição, país, idioma, salário e assinatura mudavam o que tornava o documento útil.

02

A IA podia entender o pedidomas os dados precisavam continuar confiáveis

Um campo de texto aberto deixava a experiência flexível, mas a pessoa podia não saber o que escrever nem se o resultado estava certo. Um formulário fechado era confiável, mas não dava conta da variedade de cartas reais. Explorei um meio-termo.

Só texto aberto

Flexível, difícil de confiar. Nada impedia a IA de trocar ou inventar um dado de emprego.

Só formulário

Confiável, rígido demais. Não cobria o banco que pede o número do passaporte nem o consulado que exige outro formato.

IA + dados + revisão

O caminho escolhido. A IA traduz a intenção da pessoa em campos suportados, preenchidos com dados da Deel. Ela não inventa fatos sobre o emprego.

01 · Usar as palavras da pessoa

Pedido em linguagem natural ao lado de tipos de carta e campos reconhecíveis. A pessoa descreve o resultado; o produto interpreta o que é preciso.

02 · Dados verificados no centro

Preencher emprego e salário com o que a Deel já tem, em vez de pedir que a pessoa reconstrua registros oficiais.

03 · Resultado revisável

Mostrar o conteúdo da carta antes de gerar, com espaço pra conferir ou ajustar os dados suportados.

04 · Uma saída pras exceções

Prever pedidos que exigem documentação local, formato especial, assinatura ou revisão humana, sem prometer que a IA resolve tudo.

03

Do pedidoa um documento que dá pra revisar

Mapeei o serviço entre o que a pessoa faz, os dados que a Deel já tem e as exceções que continuam com o HRX. O objetivo era reduzir o esforço de pedir a carta sem esconder o que ia aparecer nela.

O exemplo usa um certificado de salário pros Emirados Árabes: destinatário, passaporte e detalhamento do salário mostraram o limite de um modelo genérico. Recriação do protótipo de exploração, com textos e cartas do arquivo de design e dados fictícios; a versão lançada pode ser diferente.

04

Uma tarefa recorrente do RHvirou autoatendimento

A funcionalidade foi lançada em 27 de novembro de 2025 pra todas as pessoas contratadas via EOR.

915Cartas geradas nos primeiros meses depois do lançamento.
~30%Dos pedidos manuais ao HRX apontados como oportunidade de autoatendimento no lançamento.
Até 5 diasEra o prazo do processo manual. Nos cenários suportados, a carta passou a ser gerada direto.

Os ~30% são uma estimativa de oportunidade, não uma redução medida de tickets. Ainda não há medição do tempo de ponta a ponta depois do lançamento.

Além da interface

O valor ficou dividido entre dois grupos: quem trabalha ganhou autonomia sobre documentos essenciais, e o HRX passou a gastar menos tempo preparando pedidos repetitivos.

A iniciativa foi reconhecida por lideranças de produto, engenharia e design na discussão do lançamento.

05

O pedido comum resolvidoas exceções mostram por onde evoluir

O projeto apontou uma oportunidade maior: a IA ajuda as pessoas a navegar processos complexos de trabalho quando o que ela produz continua ligado a sistemas confiáveis.

01 · Ampliar a cobertura com cuidado

Identificar os pedidos por país e por instituição que ainda dependem do HRX e priorizar por volume e complexidade.

02 · Medir a conclusão, não só a geração

Ir além das cartas geradas: documentos recusados, correções, pedidos encaminhados ao time, novas tentativas e a redução real da carga do HRX.

03 · Reforçar confiança e clareza

Explicar melhor quais informações estão disponíveis, o que não é suportado e o que a pessoa deve conferir antes de compartilhar o documento.

O que eu levo

O trabalho de design não era fazer a IA escrever uma carta. Era tornar um processo de RH variável e sensível compreensível, revisável e possível de resolver sozinho.

Isso significou dar à IA flexibilidade pra interpretar pedidos humanos, mantendo a pessoa no controle da informação produzida.

Recomendações, não roadmap

Esses três passos são oportunidades que identifiquei a partir do projeto, não um compromisso de roadmap da Deel.

Jornalista
que virou
designere foi parar no negócio

  1. Entrei pra construir a experiência B2B e passei a atuar também na estruturação da operação: oferta, precificação, aquisição e jornada de compra. Além de desenhar soluções, passei a lidar diretamente com as decisões e as consequências do negócio.

  2. Como cofundadora de uma consultoria de design, olhei pra projetos a partir de contextos e necessidades bem diferentes. Também fui mentora de UX/UI na Awari, perto do desenvolvimento de outras pessoas na área.

  3. Produtos de contratação e gestão de profissionais em vários países, passando por Employee of Record e Growth. Problemas que exigiam equilibrar necessidades de usuários, regras operacionais, complexidade de produto e objetivos de negócio.

  4. Evolução do site, etapas do onboarding e experiências de endereço e pagamento. Foi onde aprofundei pesquisa e experimentação, ligando problemas de experiência a métricas operacionais. Um dos projetos reduziu cancelamentos por endereço errado.

  5. Produtos financeiros e soluções B2B: jornadas de maior complexidade e regras de negócio.

  6. No mestrado em Design pela USP, pesquisei a pobreza menstrual e como o design pode contribuir pra enfrentar desigualdades. O design não se limita aos produtos que usamos: ele também participa de como organizamos serviços, relações e acesso.

  7. Minha formação em Jornalismo pela UFRRJ continua no meu jeito de trabalhar: investigar, fazer perguntas, ouvir perspectivas diferentes e entender o contexto antes de propor uma solução.

tem um problema interessante por aí?

Vamos
conversarCom café ou sem

Gosto de conhecer pessoas, trocar ideias e conversar sobre problemas que valem a pena resolver. Se você acha que a gente pode construir alguma coisa junto, me chama.

ferlmagalhaes@gmail.com LinkedIn (abre em nova aba)

São Paulo · Trabalho remoto · PT / EN / ES