01 / Event Status
Different stages of validation
Users need to understand whether an event is waiting for submission, awaiting a response, validated, validated with a warning, or invalidated.
UX Case Study / 02
A closer look at the redesign of the eSocial Panel, a key feature of the Payroll module within Onvio's cloud modernization project.

Client
Thomson Reuters
My Role
UX/UI Designer
Featured Component
eSocial Panel
Project Focus
Legacy Modernization
Design Toolkit

Project Overview
The project was estimated to take approximately three years and involved a large, multidisciplinary team of internal employees and contractors.
We were approximately 60 people, including Business Analysts, Front-end and Back-end Developers, Software Architects, Product Owners, Agile Coaches, and UI/UX Designers.
Each module had its own team, and the MVP was composed of the application's three core modules.
~3 years
Estimated project duration
~60
Multidisciplinary team members
3
Core modules in the MVP
Main Challenges
The biggest challenges were the extensive legacy software, the need to completely rewrite the code, cultural gaps, and an unclear project scope.
Context
This case study focuses on the design process of just one feature: the eSocial Panel.
Part of the software modernization MVP, it was the most important feature of the Payroll module.
The new product is called Onvio, an accounting software platform from Thomson Reuters.
The Brazilian company Domínio Sistemas, one of the most widely used accounting software providers in the country, with more than 200,000 users, was acquired by Thomson Reuters. The decision was made to modernize the software and move it to the cloud.
Since this product involves many technical terms and Brazilian legislation, explaining some key concepts upfront helps make the case study easier to understand.
What is eSocial?
eSocial events contain labor, tax, and social security information that companies must submit electronically to the federal government.
These events can include information such as hirings, dismissals, salary changes, vacations, and absences, among others.
The purpose of eSocial is to simplify and unify the provision of information by employers, reducing bureaucracy and ensuring greater transparency and control by the government.
Legacy System
The main role of the eSocial Panel is to provide feedback about each event throughout its submission and validation process.
Events may be waiting to be submitted to the government platform for different reasons, awaiting a response, successfully validated, validated with a warning, or invalidated.
At each stage of the process, and depending on the response received, there are specific actions that can or should be taken.
All this information needs to be organized in a user-friendly way, while considering Brazilian legislation and the limitations of connecting to an external government platform.
01 / Event Status
Users need to understand whether an event is waiting for submission, awaiting a response, validated, validated with a warning, or invalidated.
02 / Available Actions
Each stage and government response may require different actions, which must be presented clearly while respecting legal and technical constraints.
Original Interface
The original eSocial Panel, before the cloud modernization.

Research
At this stage of the project, we already had several design patterns to follow to ensure consistency across the platform, even with multiple designers working on different features simultaneously.
However, the eSocial Panel had specific needs that needed to be addressed. Stakeholders also expressed a desire to innovate, while emphasizing that this was a key feature used frequently by clients, who appreciated the way it worked in the legacy system.
Research Workshop
Together with the stakeholders and the Business Analyst (BA), I conducted a workshop to organize the information we already had, our hypotheses, and the questions we needed to investigate.

Research Methodology
We classified which questions were appropriate to investigate through a survey, and I created a questionnaire using Microsoft Forms.


Sample Size
Using the population size reported on the company's website, I used the SurveyMonkey sample size calculator to estimate the ideal number of participants.
The calculation indicated that 384 participants would be needed.
200,000
Population size
95%
Confidence level
5%
Margin of error
Calculated Sample Size
384
Target survey participants — not responses collected.

Methodology Change
I submitted the questionnaire and calculated sample size to the client for approval. However, for strategic reasons, they decided not to proceed with a quantitative methodology.
At that time, accounting offices were required to sign a confidentiality agreement to participate.
Unfortunately, this process could not be completed within my deadline because it required involvement from the client's CX and Legal teams.
In addition, the company had not yet officially communicated the software migration and modernization to all its clients.
We were concerned that communicating the change at that stage could cause anxiety among clients and increase the workload for the CX team, since the migration would directly affect accounting offices' daily routines.
Alternative Research Method
As a viable alternative to the survey, I conducted 10 interviews following the stakeholder's decision: five with the CX team and five with clients.
5
CX team interviews
5
Client interviews
CX Interviews
We did not have access to usage data, as the legacy application could not collect it. NPS was the only metric gathered from users by the CX team, and there was no specific data available about eSocial.
This made conversations with the Customer Experience team especially important for understanding how clients interacted with the legacy application and the difficulties they encountered.
Research Questions
Four doubts identified during the CSD workshop helped guide our conversations with the CX team.
Question 01
Does the user know what non-processed events are on the panel?
Question 02
Does the user know the difference between an error and a warning in an event?
Question 03
Does the user know which period invalid events belong to (for monthly closing)?
Question 04
Does it make a difference to the user whether an event is an inclusion or an amendment?
Research Synthesis
The interviews helped clarify how users deal with event statuses, warnings, invalidations, and monthly closing.
Finding 01
Some clients do not even access this tab. Those who do usually do not understand why an event appears there.
When everything is working correctly, events do not remain in this tab for long.
Finding 02
When an event is invalidated, users understand that they need to resolve the problem and resend it. They typically do this without contacting the CX team.
However, when an event is validated with a warning, users usually do not address it until it causes problems, often during the monthly closing process.
In these cases, they frequently contact the CX team, which needs to review events with invalidations and warnings to identify the cause and guide users toward a solution.
Finding 03
Yes. Knowing which period invalid events belong to is relevant to the monthly closing process.
Finding 04
The distinction does not make a significant difference to users because they always need to consider the latest valid event.
According to the CX team, this is not something users typically contact them about.
Additional Questions
The following questions were originally prepared for the survey and could be adapted for discussions with the CX team.
Finding 05
This should not be allowed, as it can cause problems and is unnecessary.
If users make a mistake, they can send an amendment or delete the event after validation.
The application cannot control the deletion of an event that is already being processed by the government. This processing stage can take longer.
Some CX team members mentioned using a workaround to delete an event when something goes wrong. However, this should not be available to users, as it is an exceptional procedure used to reset the system.
Finding 06
The CX team uses this code internally to help users when they contact support.
User Interviews
Following the decision to replace the planned survey with qualitative research, I interviewed five clients to better understand their experience with the legacy eSocial Panel.
Research Questions
The interviews explored assumptions and unanswered questions identified during the CSD Matrix workshop, focusing on users' understanding of events, processing statuses, and the information available in the panel.

Interview Compilation
The interviews provided direct feedback on processing events, information organization, system reliability, and how users interpreted event statuses.
Finding 01
Requests to delete events during processing were usually related to resetting the system when it became very slow or stopped working altogether. For example, a user might make a mistake and want to delete an event immediately rather than wait for the system to correct it.
Finding 02
Users were very familiar with the panel. However, one frustration was how decentralized the information was, requiring them to navigate through multiple tabs to check return periods for periodic events.
Finding 03
Users needed the information provided by Onvio to be consistent with the government portal so they could locate employees more easily. At the time, identifying individuals using the available information was difficult. Being able to view document numbers instead of just names would help prevent problems with namesakes.
Finding 04
Users were not satisfied with the agent because it gave them the impression that processing was slow or had stopped due to a problem with the application, even when the issue was actually with the government system. Other users did not use the agent and were unclear about its purpose.
Finding 05
While some users kept the panel open at all times, most considered the system reliable and checked it only when they needed to take action on an invalidated event.
Finding 06
All interviewed users were unaware of the purpose of the numeric code assigned to events sent in a batch and had not noticed its presence.
Finding 07
Users were familiar with how to verify which period an invalid event belonged to.
Finding 08
Users understood the difference between inclusion and amendment, but the distinction was not particularly relevant to them. What mattered was whether the event had been validated or invalidated.
Finding 09
Users understood that errors needed to be resolved, but the meaning of a validation with a warning was not always clear. Some users investigated warnings, while most assumed the event was already acceptable because warnings often did not require further action.
Collaboration
During the ideation process, I frequently participated in checkpoint meetings where we could align our understanding, discuss interface decisions, ask technical questions, and receive feedback and suggestions.
I was in daily contact with the Business Analyst (BA) responsible for this feature. She helped me understand the relevant legislation and business requirements, and clarified my questions.
Twice a week, I attended alignment meetings with the design team. These were essential for maintaining consistency and receiving feedback through Design Critique sessions.
Once a week, the entire Product team met to discuss and approve new concepts and patterns, which could then be documented in our Design Manual.
Working Together
01 / Collaboration
Throughout ideationAligning our understanding, discussing interface decisions, asking technical questions, and receiving feedback and suggestions.
02 / Collaboration
DailyClarifying Brazilian legislation, business requirements, and questions related to the eSocial Panel.
03 / Collaboration
Twice a weekAligning the design team, maintaining consistency across features, and exchanging feedback.
04 / Collaboration
Once a weekDiscussing and approving new concepts and patterns to document in the Design Manual.
Process Documentation
A visual record of a checkpoint session discussing the eSocial Panel interface during the modernization process.

Usability Testing
The usability tests explored how participants interacted with the redesigned eSocial Panel through six realistic activities involving navigation, event management, filtering, and interpreting event information.
Test Planning
Each activity presented participants with a realistic scenario related to their accounting workflows.
Activity 01
Imagine that you started your workday and want to check if there are any pending issues in eSocial for any company in the office. How would you do that?
Activity 02
During the current period, a new item, "code 201," was created for overtime entries. However, this item was invalidated during the periodic events submission. Please check the error and instructions in the Solutions Center to correct the event.
Activity 03
You sent a new admission yesterday for employee Marcio Inácio Junior from Thomson Reuters, and today you found out it was invalidated. How would you solve this?
Activity 04
Imagine that you have decided to work only on the invalidations of Thomson Reuters, as the client requested urgency in submitting the payment tax form (DARF). It would be easier to visualize only the events of the current company. How would you do that?
Activity 05
In the closing event for the 03/2022 period, which was validated with a warning, the eSocial Portal indicated that the worker João Pedro Santos had already been dismissed, so it would not be necessary to send his remuneration. What would you do with this event?
Activity 06
Imagine that you forgot to include some payments in the validated S-1210 Payment event for employee Larissa Miranda Batista, code 76, in the January/2022 period. What would you do to resolve this?
Test Results
The following results describe participants' experiences with each activity, including successful interactions, difficulties, and suggestions reported during testing.
Activity 01

Test Result
Four out of five users were able to access the feature quickly, with some using the menu and others using the shortcut. Only one user expected the feature to be accessed from the dashboard.
Activity 02

Test Result
Users easily found the cause of the invalidation, as expected. However, because the Actions column contained more than three actions, they had to explore it before accessing the Solutions Center to find suggestions for correcting and resubmitting the event. They said they appreciated having this action available because it was very helpful.
Key Observation
The Solutions Center was considered helpful, although discovering the action required some exploration.
Activity 03

Test Result
In this activity, our objective was to test whether users could find the tooltip containing additional information about the employee. Some users had already discovered it during previous activities, while others took more time to locate it. They were pleased to have access to more information about the employee, but suggested that it could be improved by adding complementary information and the ability to copy and paste, making it even easier to use for searches in the government portal.
Key Observation
Participants suggested additional employee information and copy-and-paste functionality.
Activity 04

Test Result
Users were able to find and use the side filters as expected. Some even suggested using the shortcut and selecting the option in the modal as an alternative path, which also worked well.
Activity 05

Test Result
This activity presented some challenges, as users were not accustomed to warnings being separated from validations. This separation was a project requirement intended to reduce errors, but warnings still needed to be resolved differently. Some users ignored the event and created a new one, while others struggled to complete the task. Some found a solution by moving the event to the Validated tab, deleting it, and creating a new one.
Key Observation
Separating warnings from validated events challenged users' existing mental models.
Activity 06

Test Result
Users had difficulty understanding the distinction between the two types of exclusion.
Key Observation
The distinction between the available exclusion actions was unclear to participants.
Design System
Bento is a design system used for Onvio products by Thomson Reuters.
According to Thomson Reuters' documentation, Bento was created with four core principles in mind: consistency, efficiency, scalability, and accessibility.
01 / Principle
Bento provides a unified design system that creates a consistent experience across all products and platforms.
02 / Principle
Bento aims to improve product development efficiency by providing reusable design components and patterns.
03 / Principle
Bento is designed to be scalable, allowing it to grow and evolve with the needs of the product.
04 / Principle
Bento prioritizes accessibility by providing a framework for creating products that are usable by all people, regardless of ability.
Component Documentation
The Bento documentation provides examples of reusable interface components and patterns. Below are two examples from the original design system.

Buttons
Bento NG — button component documentation.

Form Validation
Bento NG — form validation documentation.
Bento NG — Design System used in Onvio products.
Prototype
A high-fidelity prototype demonstrating the redesigned eSocial Panel and its interface interactions.

Conclusion
When I designed the eSocial Panel for Onvio, I had already been working on the project for over two years and had developed a good understanding of the users and the business.
I believe it is essential to participate in technical and strategic meetings, which I did throughout the project.
I worked on more than 20 features during the MVP development process and was the only designer involved from the beginning through the completion of the first MVP.
I chose the eSocial Panel to showcase because it allowed me to conduct several discovery processes. This is not always possible when working with tight deadlines, cultural barriers around UX, and especially when a project is confidential.
Project Contribution
20+
Features I worked on during the Onvio MVP development.
Project Experience
2+ years
Working on the Onvio project before designing the eSocial Panel.
Acknowledgment
I am grateful to the ONVIO Brazil team for giving me the opportunity to grow as a designer.
I also appreciate their authorization to publish this case study in my portfolio.
Next project
Re-Play