Enterprise Data Management Platform

The problem: A growing enterprise application had become difficult to navigate. Home acted as the gateway to functional areas, while the same table model was being used for fundamentally different types of work.

My contribution: I identified that the underlying issue was structural, proposed a broader information-architecture and experience overhaul, and secured PM approval. As the sole designer, I worked closely with developers and senior management to shape navigation, data-heavy workflows, system behavior and the platform-specific component library.

The outcome: I delivered a revised IA and Phase 1 header navigation, designed two table models and configurable views, and built a platform-specific component library — giving subsequent feature work a clearer foundation.

Over time the product had accumulated functional areas that were hard to move between consistently. Home sat at the center, and dense tables carried most of the actual work — business data, logs, monitoring and administration, often with the same interaction pattern.

Access was not uniform: Regular Users, Super Users — including Investment and Financial Approvers — and Administrators could view, edit, manage or act on different things in the same areas.

The initial assignment was a UI enhancement. The structural issues would not be solved by restyling screens, so I proposed a broader overhaul of information architecture and experience and secured PM approval to pursue it.

As the sole designer, I owned the UX and UI design direction across the initiative: navigation, Home and functional areas, data-table concepts, Search Results, system behavior and the platform-specific component library. I collaborated day to day with the client-side PM and developers, and aligned the work with senior management.

Direct access to end users was limited, so I worked through close collaboration with product and business stakeholders. I challenged requirements around purpose, dependencies, technical constraints, compliance considerations, edge cases and expected outcomes — rather than treating them as a finished set of screens.

I mapped the existing information architecture to understand how functional areas were organized and how people moved between them. The original model made Home a mandatory starting point: Home → Functional area → Subsection → Table.

The proposed structure made the functional areas independently reachable through persistent global navigation. Home could then do what it was better suited for: act as a quick-access hub for frequently used sections and cards, rather than a mandatory gateway. The proposed structure is shown first. The comparison below then illustrates how the change affected the Home experience: from a collection of entry points to a working hub, with the main areas reachable through persistent navigation.

The IA change was not only structural. It changed the role of Home in the day-to-day experience: users no longer had to return to a central landing page to move between functional areas.

The first implementation phase introduced persistent header navigation, allowing users to move between major functional areas without returning to Home. Home remained available as a quick-access hub for frequently used sections and cards.

A sidebar navigation model was also designed to extend access across the platform, but it was planned for a later phase and was not part of the implemented release.

Permissions were designed as part of the UX architecture, not as an isolated administrative concern. The work started from the highest, most complete access level, then identified what changed for each user type.

Those differences showed up in User Profile, User Permissions, user management, Administrator-only actions, role-specific actions inside functional areas, and Read Only versus Edit.

The platform depended on densely populated tables. Relationships and actions changed from one section to the next, and the same interaction model was being asked to support both business work and maintenance work.

I designed two distinct table models to address different jobs. Data Tables were intended for core functional and business data. Zebra Tables were designed for logs, monitoring, user management and related maintenance work. The design separated business-data workflows from operational and administrative tasks.

I also audited the legacy tables section by section, identifying which dimensions were essential in each context. The proposed approach was intended to reduce unnecessary horizontal scrolling while keeping less frequently used dimensions available on demand.

The View Builder was designed to make data views configurable through dimensions, filters, grouping and saved views — rather than locking people into one predefined layout. The implementation retained a hybrid AG Grid appearance: the concepts were designed, but the proposed table models and View Builder were not delivered as a complete replacement.

As records and functional areas multiplied, finding the right information became part of the product problem.

Search Results was designed so people could locate a record without first understanding the application’s structure, including a working prototype that explored a second way of presenting those results.

Some workflows changed ownership or assignment of existing records and could affect downstream data. The interaction had to show what would happen before the change was committed, then keep confirmation, success, error and in-progress status inside the same flow.

Confirmation, success, error and system status make the result of an action visible. They do not replace the need to make the consequence of a change clear before it is committed.

An existing enterprise Design System provided the starting point. I expanded it into a platform-specific component library: tables and table headers, controls, rows, filters, contextual actions, and a clearer split between universal actions and the few that vary by context.

Some inherited components had unclear affordances. Search Fields, Dropdowns and Toggles were refined so those patterns behaved the same way across the product.

The platform-specific library was introduced progressively in staging and production, and became the reference for later feature design and implementation. This component-library work was distinct from the proposed table-model and View Builder changes, whose implementation remained hybrid.

The useful work was not a set of redesigned screens. It was making the relationships between information architecture, roles, tables, navigation, system behavior and reusable components explicit enough to design as one product.