Pending actions first
The top alert highlights what needs a response and explains why acting before the cut-off matters.
← Back to workPiwi
PIWI / HR PORTAL / PRODUCT DESIGN
Piwi
Complex benefits.
A clearer experience.
Redesigning the HR portal so people without specialist benefits knowledge can submit, track and resolve requests without losing the thread.
In pilot · launch planned for October 29, 2026
My role
Senior Product Designer · sole designer on the product team
Scope
Discovery, journey architecture, UI, UX writing, design system and UI QA
Collaboration
PM, senior engineering, product and operations leadership, and operations coordination
01 / Context
Submitting was possible.
Tracking was the problem.
Piwi is a digital health-benefits broker. The portal serves HR teams at client companies, many without a benefits specialist. Adding an employee involves more than a form: insurers, documents, employment relationships and cut-off dates vary with the context.
Previously, tracking relied on a table status tag, a history popup and email notifications. HR teams had to work out what had happened and what still required their action.
How can HR submit the right request, with the right documents, and always know what depends on them?
8
insurers, each with its own documents and processes
10+
journeys designed around a shared structure
1
designer connecting discovery, interface and system
THE MAIN SCREEN / HOME
The starting point
for HR’s daily work.
The home brings operational visibility and frequent actions together. Rather than making HR search for what is happening, it combines what needs attention, request progress and company contracts.
Management with context
Indicators show requests, enrollments, removals and active members. Frequent actions remain close at hand.
Progress at the entry point
Recent requests show stages and status. Contracts appear alongside them, with validity, cut-offs and access to members.
02 / Discovery
Understand operations
before designing the screen.
Discovery combined in-depth interviews with 6 clients, usability testing and team workshops. Exploring the findings helped connect difficulties in HR’s daily work with operational rules before defining journeys and screens.
In-depth interviews
Conversations with 6 clients to understand usage context, difficulties and the needs behind requests.
Usability testing
Observing use to explore flow comprehension and identify points of uncertainty during interaction.
Team workshops
Collaboratively building a matrix of certainties, assumptions and questions to make knowledge and open issues explicit.
Exploring findings
Organizing learning to discuss opportunities and inform architecture, tracking and communication decisions.
From listening to decisions: the insights below connect findings with the design choices presented in this case.
Hidden issues leave work stalled.
Status and history were hard to consult.
DESIGN DECISION
Surface pending actions on the home, list and ticket detail, with an explicit next step.
One date cannot explain the whole process.
The date entered by HR does not determine when coverage ends.
DESIGN DECISION
Show the cut-off per benefit and distinguish the request, processing and coverage dates.
More fields do not mean more clarity.
Some checks belonged to operations rather than users.
DESIGN DECISION
Remove unnecessary HR tasks and request named documents according to context.
03 / Journeys
Separate what looked alike.
Guide every decision.
Previously combined flows were separated into journeys with clear goals. The center makes that choice explicit before the form: HR identifies the task and follows its own path. Consistency comes from a shared structure, without mixing different rules and consequences.
- 01Company & relationship
- 02Benefits & products
- 03Personal details
- 04Documents
- 05Dependents
- 06Review & submit
01 / CONTEXT
The relationship guides the journey.
Company, employment relationship and admission date appear first to inform subsequent choices. Transfers and relationship changes became separate journeys after review with operations.
02 / DOCUMENTS
Documents, not a generic upload.
The insurer and relationship inform the documents required. Each item has a name, requirement label and action. When a template exists, it appears alongside the upload.
03 / FEEDBACK
Submission is not activation.
The completion screen confirms receipt and explains what happens next. It separates submission, insurer review and benefit activation, without promising instant completion.
UX WRITING / CONTEXTUAL GUIDANCE
Explain at the moment
a question arises.
The steps do more than organize form completion. Alerts, supporting text and explanations educate users as they move forward: why information is requested, what is required and what happens after submission.
“The relationship defines the documents and rules for enrollment.”
At the company and relationship step, the supporting text explains the consequence of the choice.
“Preferred date. Subject to the contract, insurer and cut-off date.”
The requested date is framed as a preference rather than a guarantee.
“Use the template required by the insurer.”
Guidance stays next to the document and action instead of relying on instructions outside the flow.
“Data and documents have been sent for insurer review.”
Confirmation explains that submission happened and clarifies the review still to come.
04 / Tracking
A request stays visible
after submission.
Tracking was designed as part of the journey. The proposal combines expandable lists, a timeline, messages and pending actions organized by deadline.
TRACKING SCHEMATIC · NOT A PRODUCT SCREENSHOT
- ✓Received
- ✓Piwi review
- 3Insurer review
- 4Completed
Four milestones, validated with backoffice so operations could update each transition.
What needs your action?
Pending issues stand out with a clear action for HR to resume the process.
What is the context?
Movement type, benefit and history stay close to progress information.
What happens next?
Cut-offs appear per benefit; notices connect deadlines with actions.
05 / System
Consistency supporting
more than ten journeys.
Design system v2 evolved alongside the product. A shared shell, review and success patterns and direct language kept journeys coherent with a single designer on the team.
01
Primitives
Forest, mint, sage and grey families
02
Semantic
Color and states mapped to purpose
03
Components
Patterns applied to interfaces
Different voices. One coherent experience.
Source Serif 4 for page titles. Public Sans for interface controls and content. Zeroheight documentation and a DESIGN.md guided creation and review.
01Warmth in care
02Restraint in data
03Clarity before charm
04No jargon
06 / Outcomes
From prototype to pilot.
Alongside Figma screens, I used navigable HTML prototypes to validate flows and iterate in short rounds. Delivery included handoff, UI and UX adjustment documentation, and pilot and launch communications.
Pilot: October 16–29, 2026. General launch planned: October 29, 2026. Status recorded on October 27, 2026.
What to measure
after launch.
There are no consolidated impact metrics yet. The plan is to track the first 30–60 days, adding quantitative evidence and client feedback to this case.
Requests returned for missing information
Evaluate submission completeness.
To measureTime to resolve pending issues
Evaluate whether HR identifies and completes the next step.
To measureContacts asking for request status
Evaluate tracking clarity.
To measurePilot participant feedback
Understand what works and where friction remains.
To measureExplore the other projects ↗Business rules are design, too.
The decisions that simplified the portal most came from operations: removing checks from HR, explaining cut-offs per benefit and maintaining shared journey patterns. Designing this experience required understanding the process as much as crafting the interface.
VAMOS CONVERSAR
Let’s talk about
your next challenge.
Me conte um pouco sobre o seu projeto. Vou receber sua mensagem por e-mail para continuarmos a conversa.
Prefere outro caminho?LinkedIn ↗