Data Modeling Platform
Enterprise UX • Activeviam
OVERVIEW
Data cubes are the foundation of financial analysis at enterprise scale but building them required deep technical expertise, Python scripts, and IT dependency.
I was brought in to design a visual interface that would let business analysts build and manage their own cubes, without writing a single line of code. The challenge wasn't just simplifying a complex system, it was doing so without stripping out the flexibility that power users depended on.
MY ROLE
Sole UX/UI designer
COLLABORATION
Engineers, Solutions Engineering and Professional Services
TIMELINE
12 months
THE PROBLEM
Business analysts relied entirely on IT teams using tools like AtScale, Kyvos, or internal Python/YAML configurations that required deep technical knowledge. This created a bottleneck: every time an analyst needed a new cube or a modification, they had to wait on IT.
The challenge was that the underlying system wasn't simple: cubes could involve multi-level hierarchies, calculated members using MDX, reusable artifacts, and complex aggregate logic.
How might we give business analysts the autonomy to build their own data models, without stripping out the flexibility that power users depend on?
USERS
THE ECOSYSTEM: 4 ROLES, 2 DIRECT USERS
User
Role in the system
Uses Cube Builder?
IT User
Configures and manages data sources
✓ Yes
FP&A Super-User
Creates and manages cubes
✓ Yes
DevOps User
Monitors live cubes, ensures uptime
✗ No
FP&A Analyst
Consumes cubes for financial analysis
✗ No
RESEARCH
Two rounds of interviews with two key stakeholders: a Principal Software Engineer in Solutions Engineering and a Solutions Architect in Professional Services. These weren't end users, but the people closest to client implementations, those who understood both the technical constraints and where business users struggled.
Round one surfaced the primary use case, FP&A analysts needed to build:
• Cube outlines
• Define hierarchies
• Create joins, measures, and fact/dimension (Currently done through a homegrown JS tool, AtScale, and Kyvos.)
Round two revealed deeper system requirements:
• Databricks integration
• MDX calculated members
• Query monitoring, and aggregate management.
I advocated for a drag-and-drop interface that generated YAML behind the scenes rather than a raw YAML editor.
Key tension: users initially need simple cubes but the system must scale. Designing for only one end of that spectrum would break the other.
EARLY ALIGNMENT
A rough sketch from an early session with the product owner and engineers to align on the high-level product flow before defining user journeys.
CORE USER FLOW
CUBE CREATION (FP&A SUPER USER)
DESIGN CHALLENGE
1. MAKING COMPLEX SYSTEMS USABLE
The underlying configuration was powerful but deeply technical - MDX calculations, join logic, aggregate management. The interface needed to map to these concepts visually without exposing their full complexity to the wrong user at the wrong time.
Rather than hiding advanced options behind toggles, I separated the experience into two distinct workspaces: IT users configure the technical layer in the Tables tab, while FP&A super-users work in the Cube tab where that complexity is already resolved.
Table tab - IT user
Cube tab - FP&A super-user
2. MAKING THE DATA MODEL VISUAL WITHOUT OVERSIMPLIFYING IT
Data models are inherently spatial, tables relate to each other, joins have direction, and the structure of those relationships directly shapes what analysts can do downstream. A form-based approach would have forced users to define relationships abstractly. Instead I designed a visual canvas where tables appear as nodes and relationships are drawn as lines between them.
SOLUTION
Visual join builder, dimension and hierarchy definition — a drag-and-drop interface that generates YAML behind the scenes, giving both IT users and FP&A super-users purpose-built workspaces that match their mental models and technical needs.
Drag and drop tables
Connected tables
OUTCOME
Cube Builder is currently in active development, with early builds already being demoed internally and to selected clients. Formal feedback from external users is still forthcoming, but initial demos have been well received — a meaningful signal for a product of this technical complexity.
Concrete metrics around time-to-build or IT dependency reduction are the next milestone to track as the product moves toward wider release.
REFLECTION
WHAT I'D DO DIFFERENTLY
Testing earlier would have changed the process significantly. Even one or two low-fidelity usability sessions with internal proxies before committing to a direction would have reduced the amount of decision-making done on inference rather than observation.
CONSTRAINTS THAT SHAPED THE WORK
• Development cycles were slow, creating gaps between design decisions and implementation feedback
• Client requirements continued to evolve throughout the project
• Access to actual end users was limited — most research was mediated through internal proxies rather than the FP&A analysts who would use the product daily
THE DECISION I'M STILL THINKING ABOUT
As the number of tables in the canvas grows, finding and connecting the right ones becomes genuinely difficult. I designed a contextual solution: a menu on each table that opens a focused overlay for connecting just those two tables, then returns the user to the full canvas. It hasn't been validated with real users yet — it's the decision I'm least certain about and the first thing I'd want to test when the opportunity comes.