This project focused on the redesign of Galicia Bank’s Business Online Banking platform, a core enterprise system used by companies to manage financial operations in a highly regulated, high-stakes environment.

The platform supported multiple business roles with different permissions and access levels, where clarity, trust, and correctness were critical. Errors or misunderstandings could directly impact users’ finances, making this a system where design decisions carried real consequences.

This was not a visual refresh. It was a foundational system redesign aimed at improving autonomy, reducing operational overhead, and enabling the platform to scale.

The platform faced several structural challenges:

• A legacy interface that had remained largely unchanged for years
• A migration from ASP.NET to .NET, introducing technical constraints and dependencies
• Inconsistent information architecture that made tasks hard to complete
• Heavy reliance on call centers and marketing teams to compensate for usability gaps
• No unified design system to support consistency or long-term scalability

At the same time, the platform needed to support different business users—administrators, operators, and decision-makers—each with distinct responsibilities, permissions, and visibility.

→ Single designer responsible for UX, system logic, and documentation

→ Fixed launch deadline aligned with business objectives (8 months)

→ Highly regulated domain, with no tolerance for failure

→ Concurrent design, development, and documentation required to support migration

The redesign started by shifting focus from screens to system logic:

• Defining role-based workflows and permission boundaries
• Ensuring the right information and actions were visible to the right users
• Designing interactions that reinforced privacy, control, and accountability

Information was reorganized into a clear structure:

• Primary navigation for stable, system-wide access
• Dynamic content areas eflecting context and role
• Account-specific details surfaced without overwhelming the interface

This structure aligned the platform with users’ mental models, especially under time pressure.

In this project, navigation was not treated as a visual problem, but as a structural system decision.

The platform needed to support multiple business roles, each with different permissions, responsibilities, and usage frequency. The primary risk was not that users would “fail to find” an option, but that they would misunderstand which actions were available to them in a given context.

Given the volume of functionality and the need to expose it without forcing deep, repetitive navigation paths, I evaluated multiple navigation approaches. We chose a mega menu not for aesthetic reasons, but because it allowed us to:

• Make the full system map visible at a glance
• Reduce cognitive load for frequent, repeat tasks
• Enable anticipation (“I know where things are before I search”)
• Maintain consistency across roles without duplicating structures

This decision prioritized clarity and predictability over apparent simplicity, based on the understanding that in enterprise financial systems, hiding complexity often increases risk rather than reducing it.

One of the core challenges was translating business rules and permission models into behaviors that users could clearly understand through the interface.

The system needed to communicate, at all times:

• what each role could do
• which information was available
• when an action was not permitted — and why

Rather than delegating this logic exclusively to the backend or relying on error messages, I focused on making system rules visible through the UI itself—using states, visual hierarchy, repeated patterns, and consistent micro-decisions.

This approach required:

• designing role-specific flows
• defining clear states for available, restricted, and contextual actions
• avoiding “surprises” during critical moments such as confirmations, submissions, and transfers

The goal was not only to prevent errors, but to build trust, ensuring the system felt predictable, transparent, and under control—even in complex financial scenarios.

Within a context of technological migration and tight timelines, documentation stopped being a final artifact and became an active part of the system.

As the sole designer on the project, designing, documenting, and implementing happened in parallel. This required treating documentation as a tool for alignment and scalability, rather than a formality.

Documentation enabled us to:

• reduce ambiguity during implementation
• ensure consistency across modules developed at different times
• support system continuity beyond my direct involvement

Rather than describing screens, the documentation captured:

• rules
• decisions
• reusable patterns
• system boundaries

This experience shaped a way of working I still use today: designing systems that can survive over time, across team changes, and under evolving business demands.