Case Study

Royal Bank of Canada

In 2020 we designed a small pilot of the Data Fabric Portal, the tool where RBC's data teams register and classify datasets. We made it for a technology partner, to show RBC what a redesigned portal could be.

Client:Royal Bank of Canada

Year:2020

Industry:Banking

Services:UX and UI design, interactive pilot

Platform:Web app

RBC shield and the Data Fabric Portal name beside the portal dashboard and its notifications panel, with sample data

The Brief

A partner wanted to show RBC what its data portal could become.

The Data Fabric Portal is an internal tool at RBC (Royal Bank of Canada). Data teams use it to register datasets, set their categories and governance fields, and answer requests from other teams. A technology partner wanted to show RBC what a redesigned portal could look like, so we designed a small pilot for them. It did not ship.

Data Fabric Portal dashboard, with the sign in screen and its RBC shield in front

Screens: 13 from the 2020 pilot, 5 added in 2026.

Task flows, from sign in to delivery.

Steps in the Data Categories setup.

Solution

We designed one working day in the portal, screen by screen.

The pilot follows an analyst through one working day. They sign in, work through their requests, change two categories, register a new dataset and check that its first load is scheduled. In 2026 we redrew the 13 pilot screens on their 2020 flows, with a new look and new sample data, and added 5 more: search, a schema page, a dataset page, an SLA monitor and the approver's view. All names, codes and numbers are sample data.

Map of 18 Data Fabric Portal screens in four lanes: start the day, change a category, register a dataset and check delivery

01 Start

Start the day with what needs an answer.

The dashboard opens on the open requests and the latest activity. The top bar holds notifications and the user menu, and a small assistant chat answers questions from the help pages.

Portal top bar with notifications panel, user menu and the assistant chat — Top bar, notifications, user menu and assistant

02 Govern

One set of categories, changed by request and approval.

Data Categories sets which values and fields a dataset can use. It runs in six steps: Data Categorization, Data Classification, Data Governance, Data Traits, Operational and Review. A request can add a value, such as a new Business Classification. The review lists the changes ready to submit and marks each field as required or optional for physical and virtual datasets. The approver sees the same changes next to the requests behind them.

Data Categories setup, step 1, with a new Business Classification value added from a linked request — Data Categories: a new value from a request

Data Categories review with two changes ready and required or optional set per dataset type — Review of the category changes

Approver view of two category changes, with added values, linked requests and approve buttons — The lead approves the changes

03 Find

Check what exists before you add anything.

A search for FX_FWD finds no physical dataset, so the analyst knows a new one is needed. The schema result lists its 12 fields. The Physical Datasets list has a filter on each column, and a row opens to show its revisions. The dataset page gathers the details, recent loads and owners in one place.

Search results for FX_FWD with no matching physical dataset, and the 12 fields of the CM_FX_FWD_RATES schema — Search, then the schema behind the new dataset

Physical Datasets list filtered to FX datasets, with one row open to show its three revisions — Physical Datasets list with a row open to its revisions

Physical dataset page with details, recent loads, owners, categories and data consumers — Dataset page: details, loads and owners

04 Register

Three steps from a request to a registered dataset.

Registering a dataset takes three steps: Data Set, Categories and Review. A form can start as a copy of an existing dataset, so most values are already filled in. The Categories step holds the governance fields: owner, custodian and steward, yes or no controls, and the teams allowed to read the data. The last screen confirms the registration and closes the request.

Create physical dataset form, step 1 of 3, copied from an existing dataset, with dataset and domain fields — Create physical dataset, step 1: data set

Data governance fields with owner, custodian and steward faces, yes or no controls and data consumer chips — Step 2: categories, the governance fields

Review step with all required fields complete, and the confirmation that the new dataset is registered — Review, then the registered dataset

05 Deliver

Check that tonight's first load is on the list.

The SLA monitor shows which jobs ran late, lists the ones a person follows, and plots the run times of one job against its target. The new dataset is already on it, scheduled for its first run tonight.

SLA monitor with met, late and missed counts, a list of followed SLAs and run times for one job — SLA monitor: last night's runs and tonight's new SLA

06 System

One set of parts behind every screen.

The portal sets all text in Roboto, with Roboto Mono for codes, IDs and dataset names. Navy, taken from the RBC shield, is the main color. The stepper, status chips, buttons, table rows and inputs repeat on every screen, so a request, a revision or a late run reads the same wherever it appears.

Data Fabric Portal design system with colors, Roboto type, stepper, buttons, status chips, table rows and inputs — Colors, type and parts used on every screen

07 The pilot

A pilot, drawn to show what was possible.

This was a capability pilot, not a shipped product, so there are no usage numbers to report. What exists is the design: 18 screens that follow one working day on one set of parts. Every name, code and number on the screens is sample data.

Your project