Incomplete data
Several target datasets were empty, structured differently, or missing fields assumed by the designs.
Case study 01 · Shipped · Summer 2026
From dashboard designs to governed, multi-tenant analytics.
I translated product requirements into working AWS QuickSight experiences, then helped prove that the embedded product could keep each financial institution's data separated.
20+analytics experiences implemented
4regulated product domains organized
2tenant contexts demonstrated
1structured implementation handoff
The assignment
The designs existed. The working analytics system did not.
NICE Actimize was moving a set of visual analytics into AWS QuickSight. Product had already defined what the dashboards should communicate. My responsibility was implementation: connect the available data, rebuild the visuals and interactions, handle migration constraints, and validate the embedded multi-tenant experience.
Ownership boundary
Product team ownedBusiness requirements, dashboard intent, and initial visual designs
I ownedQuickSight implementation, migration adaptation, validation, demo, and handoff
Why it was not a copy-and-paste migration
Platform differences
Filters and visual behavior from the previous analytics tool did not always map directly into QuickSight.
Access dependencies
Embedding and user tests depended on cloud permissions, registered users, and authentication setup outside a single dashboard.
Tenant risk
The same product experience needed to change data by institution without exposing one tenant to another.
Implementation process
01
Translate
Turn designs into an implementation contract
The product team supplied dashboard requirements and visual designs. I translated them into datasets, calculated fields, filters, visual mappings, and acceptance checks—while documenting gaps that could not be reproduced directly during migration.
02
Build
Reconstruct the analytics experience in QuickSight
I implemented more than twenty analytics experiences across AML, fraud, combined risk, and transaction workflows. The work included resolving empty or mismatched sources, recreating cross-visual filters, and adapting designs to the capabilities of the new platform.
03
Validate
Prove embedded access and tenant isolation
I built a local embedding proof of concept, tested the registered-user access path, and validated how user groups and row-level security constrain data. The final walkthrough changed tenant context while keeping the product experience consistent.
04
Handoff
Leave a system another team could continue
I organized analyses, dashboards, datasets, access rules, implementation notes, and known limitations into a structured handoff. That preserved both the delivered work and the reasoning behind it.
Sanitized system view
One product experience, governed at the identity and data layers.
The proof connected the product shell to a registered-user analytics experience. User and group context determined which row-level rules were applied before tenant-specific data reached a visual.
Product surface Access control Data layer
ProductEmbedded applicationTenant context
registered user→
AnalyticsQuickSightDashboards + datasets
PolicyUser / group mapRow-level rules
Tenant ABank A dataAuthorized rows
Tenant BBank B dataAuthorized rows
Reconstructed product view
A dashboard was evidence only when a user could trace the answer.
The final story began with a risk question, narrowed the population, and continued into the records behind the total. The interface below is a sanitized reconstruction—not an internal company screenshot.
HIGH-RISK CUSTOMERS128current view
OPEN ALERTS42requires review
ONGOING CASES17linked records
Subject status128 total
61%Review
Review Monitor Cleared
Traceable customer recordsOpen detail →
SUBJECTRISKSCORESTATUS
Customer 014High92Review
Customer 087High89Monitor
Customer 106High84Review
Sanitized reconstruction with illustrative data
Decision record
How should product designs become buildable analytics?
Decision
Create an implementation map for each visual: source, metric, grouping, filter behavior, and acceptance check.
Why
It turned visual requirements into testable units and exposed missing data before final assembly.
How should tenant separation be validated?
Decision
Test both the data rule and the user experience: user/group mapping, row-level rules, and a visible Bank A → Bank B switch.
Why
A correct chart is not enough if an embedded user can reach the wrong tenant data.
How should the final demo tell the product story?
Decision
Follow one auditor-style question from risk overview into customers, alerts, cases, and regulatory records.
Why
This demonstrated traceability and exam readiness instead of presenting a disconnected feature tour.
Result
The deliverable was more than a set of charts.
I delivered a working analytics migration, a multi-tenant embedding proof, an auditor-centered demonstration, and a structured handoff for the team continuing the work.
- 20+ analytics experiences implemented across four organized domains
- Embedded tenant-switching flow demonstrated with access isolation
- Datasets, rules, limitations, and continuation steps documented
This case study intentionally avoids confidential screenshots, customer data, internal identifiers, and unverified business-impact metrics.
Next evidence record
SuperGrowth — responsive company & product website →