← Back to projects

UX Case Study / 02

Onvio.

Modernizing a complex accounting platform.

A closer look at the redesign of the eSocial Panel, a key feature of the Payroll module within Onvio's cloud modernization project.

Onvio accounting software by Thomson Reuters

Client

Thomson Reuters

My Role

UX/UI Designer

Featured Component

eSocial Panel

Project Focus

Legacy Modernization

Design Toolkit

The tools behind the process.

Onvio design toolkit: Figma, Office 365, Google Meet and SurveyMonkey

Project Overview

A large-scale modernization challenge.

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

Working through complexity.

The biggest challenges were the extensive legacy software, the need to completely rewrite the code, cultural gaps, and an unclear project scope.

Context

Understanding the eSocial Panel.

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?

A Brazilian government system for employment, tax, and social security information.

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

Understanding the starting point.

Legacy eSocial Panel

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

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.

02 / Available Actions

Actions depend on the event's status

Each stage and government response may require different actions, which must be presented clearly while respecting legal and technical constraints.

Original Interface

The legacy application.

The original eSocial Panel, before the cloud modernization.

Original legacy eSocial Panel showing event records, validation statuses, and available actions in a desktop application.
Legacy eSocial Panel — original desktop interface.
View full image

Research

Balancing innovation with familiarity.

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

CSD Matrix.

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.

Onvio CSD Matrix containing green certainties, yellow suppositions, and pink doubts related to eSocial event processing, XML files, validation and user needs.
CSD Matrix — workshop with stakeholders and the Business Analyst to organize existing knowledge, hypotheses and research questions.
View full image

Research Methodology

Adapting the research approach.

Survey planning

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

Selected suppositions and doubts from the Onvio CSD Matrix used to plan the survey.
CSD Matrix — questions selected for the survey
View full image ↗
Flowchart showing the structure, branches and questions of the planned Onvio survey.
Survey flow and questionnaire planning
View full image ↗

Sample Size

Defining the sample.

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.

SurveyMonkey sample size calculator showing a population of 200,000, a 95% confidence level, a 5% margin of error, and a sample size of 384.
SurveyMonkey — sample size calculation
View full image ↗

Methodology Change

From survey to interviews.

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

10 qualitative interviews

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

Learning from those closest to the users.

Customer Experience 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

Questions from the CSD Matrix.

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

What we learned from the CX team.

The interviews helped clarify how users deal with event statuses, warnings, invalidations, and monthly closing.

Finding 01

Non-processed events

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

Errors vs. warnings

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

Invalid events and monthly closing

Yes. Knowing which period invalid events belong to is relevant to the monthly closing process.

Finding 04

Inclusion vs. amendment

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

Revisiting the planned survey.

The following questions were originally prepared for the survey and could be adapted for discussions with the CX team.

Finding 05

Deleting an event in processing

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

Numeric code for events sent in a batch

The CX team uses this code internally to help users when they contact support.

User Interviews

Understanding the users' perspective.

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

Revisiting our hypotheses and doubts.

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.

CSD Matrix selection for Onvio user interviews, including three suppositions and six doubts.
Suppositions and doubts selected to guide the client interviews.
View full image ↗

Interview Compilation

What the users revealed.

The interviews provided direct feedback on processing events, information organization, system reliability, and how users interpreted event statuses.

Finding 01

Deleting events during processing

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

Return periods for periodic events

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

Consistency with the government portal

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

Use of the agent

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

Everyday use of the panel

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

Numeric batch codes

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

Periods of invalid events

Users were familiar with how to verify which period an invalid event belonged to.

Finding 08

Inclusion vs. amendment

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

Errors vs. warnings

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

Designing through collaboration.

Checkpoints

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

A continuous cycle of alignment and feedback.

01 / Collaboration

Throughout ideation

Checkpoint meetings

Aligning our understanding, discussing interface decisions, asking technical questions, and receiving feedback and suggestions.

02 / Collaboration

Daily

Business Analyst collaboration

Clarifying Brazilian legislation, business requirements, and questions related to the eSocial Panel.

03 / Collaboration

Twice a week

Design critiques

Aligning the design team, maintaining consistency across features, and exchanging feedback.

04 / Collaboration

Once a week

Product team reviews

Discussing and approving new concepts and patterns to document in the Design Manual.

Process Documentation

Inside an eSocial checkpoint.

A visual record of a checkpoint session discussing the eSocial Panel interface during the modernization process.

Screenshot of a checkpoint session showing the Onvio eSocial Panel prototype with event status tabs and a data table.
eSocial Panel — checkpoint session during the design and alignment process.
View full image ↗

Usability Testing

Evaluating the experience.

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

The usability test script.

Each activity presented participants with a realistic scenario related to their accounting workflows.

  1. Activity 01

    Finding pending eSocial issues

    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?

  2. Activity 02

    Resolving an invalid event

    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.

  3. Activity 03

    Accessing employee information

    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?

  4. Activity 04

    Filtering events by company

    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?

  5. Activity 05

    Handling an event with a warning

    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?

  6. Activity 06

    Correcting a validated event

    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

What the tests revealed.

The following results describe participants' experiences with each activity, including successful interactions, difficulties, and suggestions reported during testing.

Activity 01

Finding pending eSocial issues

Starting screen for usability test activity 01: Finding pending eSocial issues
Activity 01 — Starting point
View full image

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

Resolving an invalid event

Starting screen for usability test activity 02: Resolving an invalid event
Activity 02 — Starting point
View full image

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

Accessing employee information

Starting screen for usability test activity 03: Accessing employee information
Activity 03 — Starting point
View full image

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

Filtering events by company

Starting screen for usability test activity 04: Filtering events by company
Activity 04 — Starting point
View full image

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

Handling an event with a warning

Starting screen for usability test activity 05: Handling an event with a warning
Activity 05 — Starting point
View full image

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

Correcting a validated event

Starting screen for usability test activity 06: Correcting a validated event
Activity 06 — Starting point
View full image

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

Consistency at scale.

Bento 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

Consistency

Bento provides a unified design system that creates a consistent experience across all products and platforms.

02 / Principle

Efficiency

Bento aims to improve product development efficiency by providing reusable design components and patterns.

03 / Principle

Scalability

Bento is designed to be scalable, allowing it to grow and evolve with the needs of the product.

04 / Principle

Accessibility

Bento prioritizes accessibility by providing a framework for creating products that are usable by all people, regardless of ability.

Component Documentation

A shared library of patterns.

The Bento documentation provides examples of reusable interface components and patterns. Below are two examples from the original design system.

Original Bento NG documentation showing button styles, variants, sizes and states.

Buttons

Bento NG — button component documentation.

View full image ↗
Original Bento NG documentation showing validation patterns and form components.

Form Validation

Bento NG — form validation documentation.

View full image ↗

Bento NG — Design System used in Onvio products.

Prototype

Bringing the design to life.

A high-fidelity prototype demonstrating the redesigned eSocial Panel and its interface interactions.

Animated Onvio eSocial Panel prototype demonstrating the redesigned interface.
High-fidelity prototype — eSocial Panel.
View full animation

Conclusion

Looking back at the journey.

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