Invepar
UX & Product Design - Role: Design Lead
A software that connects information to the right person at the right time in order to keep the roads safe and well maintened.

Invepar is a company responsible for some of the most important highways in Brazil. The routine of its employees includes actions such as controlling maintenance and answering help requests, keeping toll booths running and ensuring people's safety. They have their own software to keep everything under control, but it needed to be upgraded.
Goal
To deliver an interface organized to provide power of action to the attendants while they need to process a large volume of information to react quickly when there is an event, both to resolve or to address.
Challenges and responsabilities
CLIENTS WERE NOT SATISFIED WITH THE FIRST VERSION
At this point, the software was considered almost done by the company I was working for, but the client was not satisfied. While it was technically working, users couldn’t find what they needed to use it properly. My role was to deliver a good interface guide to be used by the front-end team and to make the clients satisfied with new screens. So I had to be very strategic.
I was one of the most senior UX designers working at my company, a Brazilian IT company. The project was in progress, attended by the Araraquara team (Araraquara is a city located in the state of São Paulo). As I worked for the Brasília clients, they compromised me for 3 days in an immersive process in loco.
The first version screens go below:




TO QUICKLY UNDERSTAND THE CLIENTS, THE INFORMATION ARCHITECTURE AND THE USERS DEMANDS
To start the process, there was a meeting with the stakeholders to know their concerns. Using interview techniques, I discovered the main scenario: different areas with specific needs were covered by the software and there were layers of complexity. For some employees, the software was simple. For others, too complex. So it was important that it worked for everyone and follow different rules keeping the consistency. Therefore, we could provide a good experience across the company, making routines more organized, fast-paced, and productive.
I needed to come up with important information to decide how the interface was supposed to look like for its different usages. Interviews with different user-profiles and collaborative sessions with developers, designers, and information architects uncovered what was known and revealed new information about questions I had. For example:
- What’s more important in each screen?
- Is there something that you have to access or see at the first sight?
- How can we group the information?
- How is the environment where the screen will be?
- What is the user's routine at work? What are they used to and what do they want to keep and to change?
Every piece of information was important to make the right choices, from the smallest to the biggest. From choosing the best color palette, defining the typography, and creating attention points, to which component was needed to be developed and which database would be used. The architecture had to be redone to balance the new requirements and heuristic evaluation was very important to decide what to change and prioritize.

The results
We identified critical points to work at and provide improve. Tasks needed to be done in fewer steps, correlated information needed to be disposed of close to each other in the same screen and, if we improve the forms layouts, the users could fill them more easily.
The screen used to visualize the "events report" was one of the most critical. The users had to be able to see the events, edit them, see their details and sort them considering their risk rating. So we provided two status, one simple and clear with the essential information and the other filled with details:
The "tasks lists" part also represented a challenge. Documents provided by the information architects were analysed and discussed in order to help us group components and define form layouts. The solution for this part was a set of pages held in tabs.


TECHNIQUES USED IN THIS PROJECT:
Interview with stakeholders;
Interview with users;
Interview with the system architect;
Heuristic evaluation of the previous version;
Wireframes/low fidelity prototypes;
High fidelity prototypes;
Usability observation;
Continuous validation of technology with the developers.