Redesigning Embraer’s enterprise structure across more than 25,000 records

01 — Overview

From a slow, fragmented tree to a scalable operational foundation.

Embraer relied on a hierarchical structure with more than 25,000 records within a GRC platform, connecting companies, business units, processes, people, technologies, risks, and controls. The tree’s scale and complexity slowed navigation, made entities harder to find, and increased the effort required for support and technical maintenance.

What was happening — The enterprise structure had grown to more than 25,000 records, with multiple entity types, business rules, and fragmented API endpoints. The tree was slow, difficult to navigate, and not scalable enough for users who depended on it to access information every day.
Why it mattered — The tree was a critical operational foundation of the platform. Any friction in this structure affected risk management, compliance, audit, and internal controls, while increasing reliance on support and making the product harder to evolve technically.
What I did — I worked at the intersection of product, design, and engineering to map the current structure, understand entity types, identify performance bottlenecks, and propose a clearer, more scalable experience. The work included information architecture, navigation redesign, entity-logic review, database mapping, and technical alignment with engineering to reduce complexity between the front end and APIs.
What changed — The new approach made rendering 14x faster, reduced the number of API endpoints required to operate the structure by 80%, and improved support resolution speed by 35% for navigation and entity-maintenance requests.
Business impact — The solution reduced operational complexity, improved the user experience, and created a more scalable foundation for product evolution. It also reduced rework, sped up diagnostics and onboarding for new clients using IAM (Identity and Access Management) systems, and strengthened collaboration between design and engineering in a critical part of the platform.

02 — Context

Enterprise B2B SaaS for GRC: Governance, Risk, Compliance, and Audit

Perinity is a GRC SaaS platform used by large enterprises and highly regulated organizations, including banks, public-sector institutions, private companies, and multinational organizations, to map and manage risks, define controls, track audits, and support governance and compliance processes.

The product originated from a legacy Java/JSF architecture and is still undergoing a gradual migration to Angular. My initial work focused on evolving the entity record screens within the corporate tree, as part of a broader effort to reduce legacy dependencies and modernize the system experience.

Within the platform, this tree is one of the most critical structures. It represents each client’s corporate architecture, connecting companies, business units, processes, macro-processes, technologies, key people, and other entities. From this structure, users link risks, controls, tests, audits, evidence, and action plans.

03 — Problem

The bottleneck went beyond the interface

The project scope began with the modernization of entity record screens for entities registered in the corporate tree. The initial goal was to reduce dependencies on the legacy Java/JSF system, improve the entity-management experience, and advance the product’s gradual migration to Angular.

Before that, we had already improved the tree’s visual and usability layer, enhancing navigation, search, and hierarchy. However, as the customer base grew and larger structures were introduced, the initial lazy-loading approach was no longer enough to solve the emerging scalability issue.

The most critical customer in this scenario was Embraer, which was operating with more than 25,000 records in the tree by the end of its onboarding. The structure was continuously expanding with new entities, including hundreds of records per day, updates, and relationships across companies, business units, processes, technologies, people, risks, and controls. At that scale, loading the full tree in the browser created performance loss, slowdowns, freezing, and difficulty locating specific information.

What should have enabled faster operations had become a bottleneck. The root cause was not limited to the UI, but extended to how the structure was organized, loaded, queried, and maintained.

04 — My Role

From a modernization initiative to a structural solution

My initial role was to modernize the entity record screens within the corporate tree, as part of the broader product modernization effort and the reduction of legacy Java/JSF dependencies.

However, as I investigated how the tree behaved in client environments, it became clear that modernizing the record screens alone would not solve the problem. The operation would still be constrained by performance issues, fragmented entity structures, multiple endpoints, and a model that was difficult to scale.

At that point, my role expanded. I worked as a bridge between product, design, engineering, and leadership to distinguish symptoms from root causes, map the existing structure, and propose a more viable path for the business, users, support, and technology teams.

This broader contribution was possible because I had already been leading key design maturity initiatives at Perinity, including the introduction of discovery practices, component standardization, Design System evolution, and closer collaboration between design and engineering. That track record built trust, allowing my contributions to extend beyond the interface into information architecture, componentization, entity modeling, and technical feasibility.

My key responsibilities
- Mapped the current tree structure, including entity types, record forms, relationships, and major friction points.
- Partnered with engineering to understand how the tree was loaded, which endpoints were used, and where the performance bottlenecks were.
- Translated complex business rules into simpler, more scalable flows that were easier for the team to understand and maintain.
- Connected the solution to the broader legacy modernization effort, including the gradual migration from Java/JSF to Angular.
- Supported product decisions that made the platform more self-service and flexible across clients, without overfitting the solution to a single use case.
- Documented decisions, behaviors, states, and rules to reduce ambiguity during engineering handoff.
- Aligned components and patterns with the Design System, considering Tailwind CSS, consistent naming, component architecture, and future scalability.
- Maintained direct communication with product, engineering, and leadership to advocate for a solution that reduced operational complexity without compromising the existing platform.

What differentiated my contribution

Beyond redesigning the experience, I brought technical and systems-thinking expertise to build flexible solutions from design through implementation. At Perinity, I helped establish the Design System and component architecture, introduced technologies and market practices such as Tailwind CSS, BEM conventions, and design methodologies that created a more predictable foundation for engineering, QA, and future automation.

This standardization also became more valuable as AI tooling and MCP-based workflows evolved, making it easier to introduce automated testing and other quality practices over time.

In short, my contribution transformed a request initially focused on modernizing record screens into a broader opportunity: reducing the complexity of the corporate tree and creating a more performant, flexible, and sustainable foundation for product evolution.

05 — Discovery & Insights

When reviewing entity records revealed a problem larger than the interface

The starting point was a review of the entity record screens in the corporate tree. There were seven primary entity types: Company, Business Unit, Process, Technology, Activity, Environment, and Person.

Each entity type had its own record form, with distinct fields, flows, rules, and screens. On average, a single entity could spread its information across up to 14 different screens, requiring extensive clicking before users could review, edit, or validate important data.

The first step was to understand the existing flow and identify points of friction. I began by analyzing the current screens, navigation paths, and support tickets related to the tree. Recurring feedback pointed to a longstanding issue: too many clicks, too many screens, and difficulty finding specific information.

Based on that, I sketched an initial visual and functional reorganization of the record screens. Because I typically create high-fidelity wireframes from the start, I was able to move quickly toward a more concrete version of the solution, reducing information fragmentation and grouping related data into a more direct experience.

In this first iteration, we reduced the number of screens and clicks needed for the main entity review and maintenance flows by approximately 50%.

This progress improved the experience, but it did not address the root cause. When I compared the entity record forms, I noticed that many fields were repeated across different entity types. That raised a key question: were all of these fields actually being completed, and were all entity types truly being used?

To validate that hypothesis, I requested a SQL query from the engineering team across client environments to use actual data to understand which entities were genuinely used and which fields were filled out in practice.

This step was important because, in GRC, each organization can adopt its own methodology for mapping risks, processes, and controls. Conceptually, having seven entity types made sense. In practice, we needed to understand whether clients were actually using that level of separation or whether it was introducing unnecessary complexity.

The results showed that many non-required fields were rarely completed. We also identified entity types with low adoption or highly limited usage, including Technology, Activity, Environment, and Person.

The analysis revealed that the cost of maintaining each entity type separately was high. Each required its own CRUD operations, API endpoints, documentation, specific business rules, maintenance, and separate implementation work. In other words, any change had to be replicated or adapted across multiple structures, even when their behavior was very similar.

That made the opportunity clearer: the issue was not only about reducing screens, but rethinking how entities were modeled, queried, and maintained.

Key insights
1. The UX problem was masking a structural problem.
The number of clicks and screens was the most visible symptom, but the root cause was fragmentation across entities, record forms, and endpoints.
2. The forms looked different in the UI, but were structurally similar.
Many fields were repeated across the seven entity types. This showed that the existing separation increased complexity without necessarily creating proportional value for users.
3. Not every entity type had meaningful adoption across clients.
Usage analysis showed that some entity types were rarely used or only partially completed. This opened the door to discussing a simpler, more flexible model.
4. Technical maintenance scaled with fragmentation.
Each entity had its own CRUD flow, endpoint, and maintenance logic. This increased engineering effort, made product evolution harder, and raised the cost of every change.
5. The solution needed to balance simplification with flexibility.
Reducing the number of entity types would solve part of the problem, but could limit clients with different operating models. The solution needed to simplify the foundation without blocking future customization.

Technical Notes
Entity:
In this context, an entity is a structured record type in the platform, such as a Company, Business Unit, Process, Technology, Activity, Environment, or Person. Each entity has its own fields, rules, and relationships within the system.
CRUD:
An acronym for Create, Read, Update, and Delete. It refers to the core operations used to create, retrieve, update, and remove data in a system.

06 — Product Decisions & Solution

From seven rigid entity types to one flexible, scalable foundation

We had an opportunity not only to redesign the screens, but to address the core issue: a fragmented structure made up of seven different entity types, each with its own record form, rules, CRUD flow, endpoint, documentation, and maintenance requirements.

The question that guided the solution was:

What if we could reduce this to a single entity model?

The inspiration came from my prior experience building flexible forms and custom content types in WordPress. Rather than treating every entity type as a completely separate structure, I introduced the concept of a single, configurable foundation that could adapt to each client’s context.

The proposal was to create one primary entity, a kind of unified entity model, capable of representing companies, business units, processes, technologies, activities, environments, people, and any new entity types a client might need.

In practice, the previous entity types would no longer exist as isolated structures. Instead, they would become categories or classifications applied to a shared base entity.

This would give the system:

– 1 core entity model;
– 1 base CRUD flow;
– 1 primary endpoint;
– simpler maintenance logic;
– a more consistent user experience;
– greater flexibility for different GRC methodologies.

Decision 1 — Unify the entity foundation
Problem:
The seven entity types had similar structures but were treated as separate objects across both product and engineering.
Decision:
Propose one shared base entity, with the existing types becoming categories or classifications.
Trade-off:
The change required careful planning for migration, compatibility with existing data, and impact on legacy integrations.
Expected impact:
Reduce technical fragmentation, simplify maintenance, decrease endpoint count, and make the experience more predictable.

Decision 2 — Separate the core structure from each client’s methodology
Problem:
Each client could use a different methodology to map risks, processes, business units, and controls. Reducing entity types too rigidly could limit clients with specialized structures.
Decision:
Create a pre-configuration step in the platform’s administration area, primarily handled during onboarding with the Customer Success team. At this stage, each client could define which entity types they would use in their daily operations.
Trade-off:
The solution shifted part of the configuration to the implementation stage, requiring a clear onboarding process and strong documentation.
Expected impact:
Make the product more self-service and adaptable without building custom solutions for every client.

Decision 3 — Handle specialized fields through configurable templates
Problem:
Some entity types included specialized fields that could not simply disappear during consolidation.
Decision:
Apply a flexible form-template model. Clients could define which fields appear, update labels, control required fields, and adapt fields by language, context, or entity type.
To support this, we proposed a context tab where additional fields could be linked to a specific entity type or category.
Trade-off:
The configuration needed to remain simple enough for users to manage while being robust enough to support different operating models.
Expected impact:
Reduce unnecessary fields, avoid excessive configuration, and support specialized use cases without duplicating structures.

The proposed solution

This was not just a new interface for entity record forms. It was a change in how the product modeled, organized, and operated its entities.

Previously, each entity was treated as an isolated structure. The new model proposed a shared base entity that could take on different types, use configurable fields, and adapt to each client’s methodology.

This would create a simpler foundation for engineering, a clearer experience for users, and greater business flexibility by reducing delivery costs and supporting new client acquisition.

07 — Technical Validation & Impact

When the design solution had to stand up to architectural scrutiny

The engineering team was involved from the earliest stages of the investigation. The analysis of entities, endpoints, record forms, and legacy constraints was not conducted by design in isolation. The solution needed to address the user problem, but it also had to be viable within a monolithic product with Java/JSF dependencies, active external integrations, reports, business rules, and relationships across multiple platform modules.

When I presented the proposal to consolidate the entity types into a more flexible shared foundation, the response was positive. The team recognized that the solution addressed long-standing tree issues: heavy rendering, multiple endpoints, fragmented maintenance, and the difficulty of evolving the component without affecting other parts of the system.

The engineering team also brought new perspectives on the proposal’s technical impact. Simplifying the model could reduce integration complexity, make the tree easier to maintain, improve performance, and prevent the same issues from continuing to compound as new clients and methodologies were added to the product.

At the same time, the team identified critical considerations that needed to be addressed before implementation:

– impact on active external integrations;
– dependencies on existing reports;
– tree relationships with risks, controls, audits, and other records;
– migration of legacy data into the new structure;
– compatibility with clients already using their own methodologies;
– risk of data loss or inconsistencies during the transition;
– dependencies on the JSF legacy layer and the application’s monolithic architecture.

After the presentation, engineering began a deeper architectural assessment of the solution. For approximately two months, the team evaluated impact, effort, migration risks, and possible implementation paths that would avoid disrupting existing client operations.

The conclusion was that the effort would be significant, but the expected value justified the initiative. The solution was seen as a preventive evolution: instead of continuing to fix tree-related symptoms client by client, the proposal addressed the structure that was creating slowdowns, fragmentation, and ongoing maintenance costs.

The implementation was then planned as a gradual rollout, starting with the most critical clients and first in a staging environment. Because Perinity’s platform is broad and each client has its own configuration, migration required manual review, data validation, and careful preparation before production rollout.

Although still under development, the solution already indicated meaningful gains:

– up to 14x faster tree rendering in high-volume scenarios;
– 80% fewer endpoints required to operate entities;
– 35% faster support diagnosis and guidance for tree-related tickets;
– a more flexible foundation for clients with different methodologies;
– lower future cost for maintenance, evolution, and integration of the structure.

The main impact was turning a critical area of the platform into a more sustainable foundation for scaling the product, reducing rework, and enabling technical users to manage complex structures with greater clarity, performance, and confidence.

08 — Learnings

Complexity does not disappear. It needs to be organized.

In enterprise products, the best solution is not always about simplifying the interface in isolation. Often, the friction users experience is the result of structural decisions accumulated over time.

The experience affects more than the people using the interface. It also shapes implementation, support, engineering, and the cost of evolving the platform. That is why everyone involved in the operation needs clarity, control, and predictability when working with critical information.

Design needs to consider the full system. When a solution improves information architecture, data modeling, performance, and maintainability, it reduces rework, speeds up diagnosis, and turns complexity into a more reliable, scalable, and actionable experience.