Role 
UX/UI Designer
The team involved in this task was composed of:
1 PO, 1 BA, 1 Designer (me), 10+ devs

Methods and Tools
CSD Matrix, Interviews, High fidelity prototypes, Usability Studies, Design system
Design Toolkit
Project Overview
The project was estimated to about 3 years and had a multidisciplinary and large team, composed of internal employees and contractors. We were approximately 60 people, divided into Business analysts, Front-end developers, Back-end developers, Software architectures, Product owners, Agile coaches, and UI/UX Designers. Every module had its own team, the MVP was composed of the 3 core modules of the application.  
The biggest challenges were how extensive was the legacy software, the need to complete remaking the code, some cultural gaps, and the unclear scope.
Context
This case is focused on showing the design process of only one feature, the eSocial Panel, part of the Software modernization's MVP, the most important feature of the Payroll module.
The new product is called ONVIO it is an accountability software from Thomson Reuters, as the Brazilian company Dominio Sistemas, one of the most used accountability software in the country, with +200k users was bought by them, they decided to modernize and make it on the cloud.
As this product has many technical terminologies and involves Brazilian legislation, it can be hard to translate with accuracy so to make things a little more clear from the beginning I will explain the key concept.
The eSocial events are 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
The main role of the eSocial Panel is to give feedback about each event. They can be waiting to be submitted to the government platform for a number of reasons, then they will wait for an answer and finally will be validated, validated with a warning, or invalidated. In every moment of the process and according to each answer there are specific actions that could or should be made. All this information needs to be organized in a user-friendly way, but considering the legislation and the limitations to be connected to an external platform.

Legacy eSocial Panel

Research
At this point in the project we already had many Design patterns to follow, to create a consistent platform even having multiple designers, each one working on a different feature at the same time, but the panel had specific needs to address and the stakeholder shared the desire to innovate, also they told me that this is a key feature and their clients used it all the time and they liked it the way it was in the legacy.
CSD Matrix
With the stakeholders and Business Analyst (BA), I conducted this workshop to organize all the information we already had, the hypothesis, and the questions we needed to search for answers.
Survey
We classified what was appropriate to be searched using a survey and I created a form using Microsoft Forms.
Considering the population size extracted from their own website I used the Survey Monkey calculator the find the ideal sample size, coming to the conclusion we needed 384 participants. 
I submitted the form and the sample size for approval by the client. However, for strategic reasons, they opted not to use a quantitative methodology.
At that time, all the accounting offices were required to sign a confidentiality agreement to participate. Unfortunately, this process could not be completed in time for my deadline since it required involvement from their CX and Legal teams. Moreover, we had not yet officially communicated with all their clients about the software migration and modernization. We were concerned that such communication could cause anxiety in their clients and increase the workload for their CX team since this migration would directly impact the offices' work routines. 
As a viable alternative to the survey, I conducted 10 interviews - 5 with the CX team and 5 with clients - following the stakeholder's decision.
CX interviews
We didn't have access to data, the legacy application could not collect any and the NPS was the only metric the CX team collected from users, nothing specific about the eSocial could be found, which is why talking to the CX team was so important.
Compilation
1. Non-processed events on the panel: Some clients do not even access this tab and those who do usually do not understand why an event is there. Events do not remain in this tab for long if everything is working fine.
2. The difference between an error and a validation with a warning: When an event is invalidated, users know they have to solve the problem and resend it. They typically do this without having to contact the CX team for help. However, when an event is validated with a warning, they usually do not solve it until it causes problems, which tends to happen during the period closing event. In this scenario, they often call the CX team, and we have to look at all events with invalidations and warnings to find the cause of the problem and provide guidance on how to solve it.
3. Invalid events for monthly closing: Yes.
4. Difference between inclusion and amendment: It does not make a big difference to the users; they always need to consider the last valid event. It is not something they ever call us about for help.

The following questions were originally from the survey and could be adapted for the CX team:
5. Deletion of an event in processing: This should not be allowed, as it can cause problems and is not necessary. Users can send an amendment if they made a mistake or delete the event after validation. We would not have control to delete an event that is already being processed by the government, and this is the part that could take longer. If something goes wrong from our side, some CX members said they use a workaround to delete the event, but it should not be done for users, and it is an exception to "reset" the system.
6. The numeric code for events sent in a batch: We use it internally to help them when they call.
User interviews
Compilation
1. Deletion of an event during processing: This request was usually related to resetting the system when it became very slow or stopped working altogether. For example, one user once made a mistake and wanted to delete the event immediately to avoid waiting for the system to correct it.
2. Location of return periods on periodic events in the display:  They were very used to the panel, but a pain they brought is how decentralized things are, they got too many tabs to check.
3. Ensure that the information we provide is consistent with the government portal to facilitate locating an employee in the panel. Currently, it is difficult to identify individuals using the information we provide. Being able to view document numbers rather than just names would prevent issues with homonyms.
4. Use of the agent: They were not satisfied with the agent, it cause them the impression every time the processing was slow or stopped that our system was down even when actually the problem was in the government system. Other users did not use the agent and were unclear about its purpose.
5. Working with the panel: While some users kept the panel open at all times, most found the system reliable and only checked it when necessary to take action on an invalidation event.
6. Numeric code for events sent in a batch: All users were unaware of the numeric code's purpose and had not noticed its presence.
7. Period of invalid events: Users are familiar with how to verify this information.
8. Difference between inclusion and amendment: They know the difference but is not relevant to them, it is only important to know if it is invalidated or validated.
9. The difference between an error and a validation with a warning:  Users understand that errors need to be resolved, but the warning is not always clear to them. Some users check it out, but most assume that it is already okay since warnings often do not require action.
Checkpoints
During the ideation process, I participated often in checkpoint meetings where we could align the understanding, discuss the decisions made on the interface, ask technical questions, and receive feedback and suggestions.
Daily I was in contact with the BA responsible for this feature, so she could tell me all I needed to know about the legislation, and business point of view and clarify my doubts.
Twice a week I and the design team had an alignment meeting, absolutely necessary to keep consistency and to receive feedback through Design Critiques sessions.
Once a week the entire Product team had a meeting to discuss and approve new concepts and patterns so we could document that in our Design Manual.
Usability tests
Script
1. 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. 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. 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. Imagine that you have decided to work only on the invalidations of Thomson Reuters, as the client requested urgency in the submission of the payment tax form (DARF) and it would be easier to visualize only the events of the current company. How would you do that?
5. In the closing event of the period 03/2022 (which was validated with a warning), it was analyzed on the eSocial Portal that the worker without a link João Pedro Santos has already been dismissed, so it will not be necessary to send his remuneration. What would you do with this event?
6. 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?
Results
Activity 1

Activity 1 starting point

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 2

Activity 2 starting point

Users easily found the cause of invalidation as expected, but since the action column had more than 3 actions, they had to explore it before accessing the solutions central to find suggestions for correcting and resubmitting the event. They affirmed that they liked the presence of this action because it was very helpful.
Activity 3

Activity 3 starting point

In this activity, our objective was to test whether users could find the tooltip containing additional information about the user. 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 some complements and the ability to copy and paste, which would make it even easier to use for Portal searches.
Activity 4

Activity 4 starting point

The users were able to find and use the lateral 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 5

Activity 5 starting point

This activity presented some challenges as users are not accustomed to warnings being separated from validations, which is a project requirement to reduce errors but still needed to be resolved in a different way. Some users ignored the event and created a new one, while others struggled to complete the task. Some users found a solution by pushing the event to the validated tab, deleting it, and creating a new one.
Activity 6

Activity 6 starting point

The users had difficulty understanding the distinction between the two types of exclusion.
Design system
"Bento" is a design system used for Onvio products by Thomson Reuters.
According to the Thomson Reuters website, Bento was created with the following principles in mind:
Consistency: Bento provides a unified design system that creates a consistent experience across all products and platforms.
Efficiency: Bento aims to improve the efficiency of product development by providing reusable design components and patterns.
Scalability: Bento is designed to be scalable, allowing it to grow and evolve with the needs of the product.
Accessibility: Bento prioritizes accessibility by providing a framework for creating products that are usable by all people, regardless of ability.

Bento NG - ONVIO's products DS

Prototype
Conclusion
When I designed the eSocial panel for Onvio, I had been working on the project for over two years and had a good understanding of the users and the business. I believe it's essential to participate in technical and strategic meetings, which I did throughout the project. I worked on over 20 features during the MVP building process and was the only designer involved from the beginning to the completion of the first MVP. I chose the eSocial panel as the feature to showcase because it allowed me to conduct several discovery processes. This isn't always possible when dealing with tight deadlines, UX cultural barriers, and especially when the project is confidential.​​​​​​​
I am grateful to the ONVIO Brazil team for giving me the opportunity to grow as a designer. Additionally, I appreciate their authorization to publish this case in my portfolio

You may also like

Back to Top