In this project, I took on the role of UX/UI Lead Designer, leading the definition of the experience and interface for a critical national system with a direct impact on sensitive state-level operations.

In a project of this complexity, where various teams, entities, and developers intersect, chaos can quickly set in. The truth is that many usability and consistency failures arise not in the design phase, but in the transition to development. Ensuring that UX/UI decisions were respected became a mission in itself.

To reduce friction and maintain consistency, I created close routines with the technical teams, including recurrent Design Pods where we discussed components, behaviors, and sensitive decisions. These sessions were fundamental for aligning all parties, involving developers early on, and protecting design decisions, which, amidst all of this, needed room to breathe.

Despite the extreme level of secrecy involved (full NDA mode), I was responsible for:

• Creating and scaling a design system from scratch, adapted to an ultra-regulated ecosystem.

• Translating complex and hierarchical processes into simple and usable flows.

• Daily oversight of multiple development teams, ensuring consistency and technical viability.

• Managing and adapting the experience according to user profiles, access levels, and operational contexts.

• And of course, maintaining focus on the end-user, even when bureaucracy or time seemed to pull in the opposite direction.

Here, design wasn't just visual work; it was a piece of strategy, diplomacy, and structure.

I joined the project during an early phase, but with part of the user research and requirements gathering already complete. I quickly had to adapt my pace to a highly complex and constantly changing reality.

The challenge was threefold:

• How to respond to a project with monumental expectations within an unrealistic timeline for its scale?

• How to design a coherent and robust solution while code development was already progressing, even without a design system in place?

• How to gain traction and space in an environment dominated by specialists with decades of in-depth knowledge while I was still learning the language of this ecosystem?

Upon diving into the project, I quickly realized the struggle wasn't just against time. It was also against the complexity of the data, the organizational structures, and the multiplicity of user profiles, each with very distinct tasks, access levels, and responsibilities.

While I was creating wireframes and designing components for technical specifications, I had to learn at lightning speed: from the entity's internal processes to decision flows, including back-end technical limitations and legal and operational implications.

It was a true exercise in empathy, resilience, and adaptation. A constant battle with time, code, the egos of those involved (including my own), and hundreds of difficult decisions.

Here, there was no room for shortcuts. With some existing modules, or "applications," functioning as isolated platforms, the question arose: "Do I use what already exists as a base, or do I create from scratch?" My answer was clear:

"If I'm going to do it, I'm going to do it well."

And I did. I created a design system from scratch, even with all the limitations imposed by time and infrastructure. I worked closely with senior specialists, who already came with firm visions and certainties about what "works," where the logic of "as few clicks as possible" prevailed—no breadcrumbs, no frills.

It was an exercise in extreme simplification. Aesthetics gave way to pragmatism. The motto? "Less is more," but in hard mode.

The design system was built from scratch. But it wasn't born alone.

It was an endless iterative process. Interminable meetings, continuous adjustments, heated debates. There wasn't a single vision, and inputs came in homeopathic doses; each module brought new requirements that broke or reconfigured previous decisions.

This uncertainty forced me to be in constant contact with the developers—ensuring that what was designed was feasible, that it didn't break what already existed, and that it continued to serve the end-user.

A design system, besides coherence, demands constant vigilance. It's a living organism, and here, it was almost a mythological creature I had to tame.

From the user experience perspective, the goal was clear:

To create something that worked intuitively and without friction, even in a dense and technically demanding environment.

We developed a set of modules that followed the "less is more" philosophy, eliminating noise and focusing only on the essentials. We avoided unnecessary functionalities, prioritizing real impact on users' daily lives, considering not only experienced professionals but also newcomers and the system's longevity.

Nothing was done on a whim. Everything had a purpose.

This project taught me more than any book.

Working with sensitive data and maximum security isn't just a technical challenge; it's a lesson in responsibility, ethics, and commitment to social impact.

I learned to deal with people, with egos (including my own), in a dynamic of constant confrontation between ideas, needs, and priorities, but where the focus must always be on the user.

"Less is more" stopped being an aesthetic motto and became a working philosophy. Optimizing seconds per interaction can mean gigantic gains in a state structure.

A good project needs a head, body, and limbs. Without structure, deviations become inevitable. We had to make sacrifices, but always aware of what was at stake.

I've always been multidisciplinary, but here I had to embrace the chaos with grit: designing, testing, defining systems, interacting with developers and PMs, learning about internal processes and legislation, and still creating something coherent and usable.

A design system built from scratch, even with all the obstacles, is an essential tool for ensuring scalability and consistency in a large-scale project.