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 to build and modify cube that required deep technical knowledge.
Exiting workflow:
• Python / YAML configuration
• AtScale & Kyvos
• Deep technical knowledge required
• Every change depended on IT
Result:
Every new cube or modification became a bottleneck.
Why this was difficult:
The underlying system wasn't simple.
It included:
Multi-level hierarchies
MDX calculated members
Reusable artifacts
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?
PRIMARY 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
Interviews:
2 rounds
Participants:
• Principal Software Engineer
• Solutions Architect
Although they weren't end users, they were closest to client implementations and had firsthand knowledge of both technical constraints and business pain points.
ROUND 1
Learned business analysts needed to:
• Build cube outlines
• Define hierarchies
• Create joins
• Create measures
• Manage dimensions
Current workflow:
AtScale • Kyvos • Internal JS Tool
ROUND 2
Revealed additional requirements:
• Databricks integration
• MDX calculated members
• Query monitoring
• Aggregate management.
Design direction:
Rather than exposing YAML directly, I proposed a drag-and-drop interface that generated it behind the scenes.
DESIGN PRINCIPLES
✓ Empower business users.
✓ Preserve expert flexibility.
✓ Hide technical implementation.
✓ Generate configuration automatically.
✓ Design for novice and expert users.
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
Challenge
The underlying configuration included:
• MDX calculations
• Join logic
• Aggregate management
The goal wasn't to remove complexity, it was to expose it only when users needed it.
Decision
Separate the experience into two workspaces.
Tables → IT users configure the technical layer.
Cube → Business users build cubes without touching joins or SQL.
Table tab - IT user
Cube tab - FP&A super-user
2. MAKING THE DATA MODEL VISUAL WITHOUT OVERSIMPLIFYING IT
Challenge
• Data models are spatial.
• Tables relate to one another.
• Joins have direction.
Decision
• Data models are spatial.
• Tables relate to one another.
• Joins have direction.
SOLUTION
I replaced a code-driven workflow with a visual modeling experience. Tables became connected nodes, relationships became visible, and technical configuration was generated behind the scenes, allowing both IT users and FP&A super-users to work in interfaces designed around their needs.
Drag and drop tables
Connected tables
OUTCOME
Cube Builder is actively being developed, with early builds already demonstrated internally and to selected clients. The design established a visual modeling approach that replaces code-driven configuration with purpose-built workflows for both IT users and FP&A analysts.
While formal user metrics aren't yet available, early internal demos validated the overall direction and the product continues toward broader release.
IMPACT
✓ Established the interaction patterns for visual data modeling.
✓ Replaced a code-first workflow with a visual experience.
✓ Reduced dependency on YAML for business users.
✓ Created separate workspaces for technical and business audiences.
REFLECTION
WHAT I'D DO DIFFERENTLY
Earlier usability testing, even with internal proxies, would have replaced assumptions with observation before committing to key interaction patterns.
PROJECT CONSTRAINTS
• 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
FUTURE VALIDATION
As data models grow, connecting the right tables becomes increasingly difficult. I designed a focused connection flow to reduce visual overload, but without access to end users this remains the interaction I'd validate first in future testing.
TAKEAWAY
The biggest lesson wasn't how to visualize data models, it was exposing complexity without overwhelming users.
The best enterprise tools don't remove complexity; they organize it around the user's mental model.