← Voltar aos projetos

PIWI / PORTAL RH / PRODUCT DESIGN

Piwi
Benefícios complexos.
Uma experiência mais clara.

Redesenhar o portal RH para que pessoas sem especialização em benefícios consigam abrir, acompanhar e resolver solicitações sem perder o fio de nenhuma delas.

Em piloto · lançamento previsto para 29/10/2026
Home do portal RH: visão da operação, pendências prioritárias, solicitações recentes e contratos em um só lugar.
Meu papel

Senior Product Designer · único designer do time de produto

Escopo

Discovery, jornadas, UI, UX writing, design system e QA de UI

Colaboração

PM, desenvolvimento sênior, lideranças de produto e operação e coordenação de operações

01 / Contexto

Abrir um pedido era possível.
Acompanhar era o problema.

A Piwi é uma corretora digital de benefícios de saúde. O portal atende RHs de empresas clientes, muitas sem uma pessoa especialista em benefícios. Incluir um colaborador envolve mais do que preencher um cadastro: operadoras, documentos, vínculos e datas de corte mudam de acordo com o contexto.

No portal anterior, o acompanhamento dependia de uma tag na tabela, um histórico em popup e notificações por e-mail. O RH precisava descobrir o que havia acontecido e o que ainda dependia dele.

Como ajudar o RH a pedir a coisa certa, com os documentos certos, e saber sempre o que depende dele?
8

operadoras, com processos e documentos próprios

10+

jornadas desenhadas sobre uma estrutura comum

1

designer conectando descoberta, interface e sistema

A TELA PRINCIPAL / HOME

O ponto de partida
para a rotina do RH.

A Home concentra a leitura da operação e o acesso às ações mais frequentes. Em vez de obrigar o RH a procurar o que está acontecendo, ela reúne o que precisa de atenção, o andamento das solicitações e os contratos da empresa.

Pendências antes de tudo

O alerta no topo destaca o que aguarda resposta e explica por que agir antes da data de corte.

Gestão sem perder o contexto

Indicadores mostram solicitações, inclusões, exclusões e beneficiários ativos. Ações frequentes ficam à mão.

Acompanhamento na entrada

Solicitações recentes mostram etapas e status. Os contratos ficam ao lado, com vigência, corte e acesso aos beneficiários.

02 / Discovery

Entender a operação
antes de desenhar a tela.

O discovery combinou entrevistas em profundidade com 6 clientes, testes de usabilidade e dinâmicas com o time. A exploração das descobertas ajudou a conectar as dificuldades da rotina do RH às regras da operação, antes de definir as jornadas e as telas.

06

Entrevistas em profundidade

Conversas com 6 clientes para compreender o contexto de uso, as dificuldades e as necessidades por trás das solicitações.

↗

Testes de usabilidade

Observação do uso para explorar a compreensão dos fluxos e identificar pontos de dúvida na interação.

✳

Dinâmicas com o time

Construção coletiva de uma matriz de certezas, suposições e dúvidas para explicitar o que sabíamos e o que ainda precisava ser investigado.

→

Exploração das descobertas

Organização dos aprendizados para discutir oportunidades e orientar decisões de arquitetura, acompanhamento e comunicação.

Matriz CSD construída nas dinâmicas com o time: certezas, suposições e dúvidas para organizar a exploração do problema.

Da escuta à decisão: os insights abaixo conectam as descobertas às escolhas de design apresentadas no case.

INSIGHT

Pendência escondida vira trabalho parado.

Status e histórico eram difíceis de consultar.

DECISÃO DE DESIGN

Trazer pendências para a home, a lista e o detalhe do ticket, com uma ação explícita.

INSIGHT

Uma data não explica toda a operação.

A data informada pelo RH não determina sozinha o fim da cobertura.

DECISÃO DE DESIGN

Mostrar o corte por benefício e explicar a diferença entre pedido, processamento e vigência.

INSIGHT

Mais campos não significam mais clareza.

Algumas verificações pertenciam à operação, não ao usuário.

DECISÃO DE DESIGN

Retirar tarefas indevidas do RH e pedir documentos pelo nome, conforme o contexto.

03 / Jornadas

Separar o que parecia igual.
Orientar cada decisão.

Fluxos que antes estavam unidos foram separados em jornadas com objetivos claros. A central torna essa escolha explícita antes do formulário: o RH identifica o que precisa fazer e segue um caminho próprio. A consistência vem da estrutura compartilhada entre as jornadas, sem misturar regras e consequências diferentes.

Central de movimentações: ações separadas para orientar a escolha antes de começar uma jornada.
  1. 01Empresa & vínculo
  2. 02Benefícios & produtos
  3. 03Dados pessoais
  4. 04Documentos
  5. 05Dependentes
  6. 06Revisão & envio

01 / CONTEXT

O vínculo orienta o caminho.

Empresa, tipo de vínculo e admissão aparecem no início para dar contexto às decisões seguintes. Transferência e mudança de vínculo foram separadas após revisão com a operação.

Inclusão: a primeira etapa identifica a relação do colaborador com a empresa.

02 / DOCUMENTS

Documentos, não um upload genérico.

A operadora e o vínculo orientam os documentos necessários. Cada item tem nome, obrigatoriedade e ação própria; quando há um modelo, ele fica no mesmo contexto do envio.

Upload organizado por documento, com indicação do que é obrigatório ou opcional.

03 / FEEDBACK

Envio não é ativação.

A tela de conclusão confirma o recebimento e explica o que acontece depois. O fluxo diferencia cadastro enviado, análise pela operadora e benefício ativado, sem prometer uma conclusão imediata.

Conclusão da inclusão: resumo do envio e próximos passos.

UX WRITING / ORIENTAÇÃO CONTEXTUAL

Explicar no momento
em que a dúvida aparece.

Os steps não organizam apenas o preenchimento. Alertas, textos de apoio e explicações educam o usuário sobre o processo enquanto ele avança: por que uma informação é pedida, o que é obrigatório e o que acontece depois de enviar.

01 / Contexto antes da escolha
“O vínculo define os documentos e as regras para inclusão nos benefícios.”

Na etapa de empresa e vínculo, o texto explica a consequência da escolha.

02 / Expectativa sobre a data
“Data preferencial. Sujeita ao contrato, operadora e data de corte.”

A data desejada é apresentada como preferência, evitando tratá-la como garantia.

03 / Documentos com instrução
“Utilize o modelo exigido pela operadora.”

O apoio fica junto ao documento e à ação, em vez de depender de uma explicação fora do fluxo.

04 / Próximos passos visíveis
“Os dados e documentos foram encaminhados para análise da operadora.”

A confirmação explica que houve envio e orienta sobre a análise que ainda vai acontecer.

04 / Acompanhamento

O pedido continua visível
depois do envio.

O acompanhamento foi pensado como parte da jornada. A proposta combina lista expansível, linha do tempo, mensagens e uma fila de pendências organizada por prazo.

ESQUEMA DO ACOMPANHAMENTO · NÃO É UMA TELA DO PRODUTO
  1. ✓Recebida
  2. ✓Análise Piwi
  3. 3Análise operadora
  4. 4Concluída

Quatro marcos, validados com o backoffice para que cada mudança pudesse ser atualizada pela operação.

O que depende de você?

Pendências têm destaque e uma ação clara para o RH retomar o processo.

Qual é o contexto?

Tipo de movimentação, benefício e histórico ficam próximos do andamento.

O que acontece agora?

O corte aparece por benefício; avisos deixam explícita a relação entre prazo e ação.

05 / Sistema

Consistência que sustenta
mais de dez jornadas.

O design system v2 foi desenvolvido junto com o produto. Um shell comum, padrões de revisão e sucesso e uma linguagem direta ajudaram a manter as jornadas coerentes com um único designer no time.

01

Primitivos

Famílias forest, mint, sage e grey

02

Semânticos

Cor e estado com significado de uso

03

Componentes

Padrões aplicados à interface

Contraste de vozes, unidade de experiência.

Source Serif 4 nos títulos de página. Public Sans nos controles e no conteúdo de interface. Documentação no Zeroheight e um DESIGN.md para orientar criação e revisão.

01Calor no cuidado

02Sobriedade no dado

03Clareza acima de charme

04Sem jargão

06 / Resultados

Do protótipo ao piloto.

Além das telas no Figma, usei protótipos HTML navegáveis para validar fluxos e iterar em rodadas curtas. A entrega incluiu handoff, documentação de ajustes de UI e UX e comunicação de convite ao piloto e de lançamento.

Piloto: 16 a 29/10/2026. Lançamento geral previsto: 29/10/2026. Situação registrada em 27/10/2026.

O que medir depois
do lançamento.

Ainda não há indicadores consolidados de impacto. O plano é acompanhar os primeiros 30 a 60 dias e acrescentar evidências quantitativas e feedback dos clientes ao case.

Tickets devolvidos por falta de informação

Avaliar a completude das solicitações.

A medir

Tempo para resolver pendências

Avaliar se o RH identifica e resolve o próximo passo.

A medir

Contatos perguntando status

Avaliar a clareza do acompanhamento.

A medir

Feedback dos participantes do piloto

Entender o que funcionou e onde ainda há fricção.

A medir

Regra de negócio também é design.

As decisões que mais simplificaram o portal nasceram da operação: retirar verificações do RH, explicitar cortes por benefício e manter um padrão entre jornadas. Projetar essa experiência exigiu tanto entender o processo quanto desenhar a interface.

Explorar os outros projetos ↗

VAMOS CONVERSAR

Vamos conversar sobre
o seu próximo desafio?

Me conte um pouco sobre o seu projeto. Vou receber sua mensagem por e-mail para continuarmos a conversa.

Prefere outro caminho?LinkedIn ↗

Conte sobre sua ideia.Todos os campos são obrigatórios.

Seus dados serão usados para responder a este contato.