Dell Technologies · Enterprise SaaS · 2022–2023
APEX Navigator for
Multicloud Storage
Defining a new product from scratch and simplifying complex infrastructure
My role
Product Designer
Timeline
2 years · 2022–2023
Platform
Dell APEX / Premier
Launched
Nov 30, 2023
Overview
Managing storage across multiple clouds is complex. Different environments, different tools, different mental models — it adds up fast for ITOps teams who just need to get work done without making a mistake.
This was Dell's first centralized SaaS platform for managing storage across public clouds. There was no existing solution, no prior designs, no internal reference point. We were building from scratch.
My job was to take that complexity and give it structure. Clear workflows, visual system representation, and a shared prototype that kept the whole team aligned from start to finish.
I joined this project in 2022 and worked on it for two years. I became the go-to designer for APEX patterns on the team — the person other designers and PMs came to when they needed to understand how the system should work.
Problem
Designing for multicloud systems introduced both technical and product-level challenges
01
No existing product or UX patterns to build from
02
Core workflows for deployment, management, and monitoring needed to be defined from scratch
03
System hierarchy could extend 4+ levels deep
04
Different stakeholders had inconsistent mental models of how the system should work
👉 Without a clear structure, both users and internal teams struggled to understand how the system should behave.
Evidence
Complex infrastructure relationships were difficult to represent through traditional UI patterns
Early discussions revealed confusion around system hierarchy and dependencies
Teams frequently required clarification during design reviews and handoffs
Lack of shared understanding slowed decision-making across product and engineering
Approach
Structuring Complex Workflows
Broke down deployment into step-by-step stages
Grouped inputs based on the type of decision users were making
Reduced cognitive load by limiting information per step
Defining Context Early
Surfaced product type and provider selection at the beginning
Ensured all downstream configurations were scoped correctly
Prevented invalid or conflicting setup decisions early in the process
Visualizing System Architecture
Designed a topology view to represent system hierarchy
Enabled users to understand relationships across 4+ levels of infrastructure
Encoded both structure and connection status in a single view
Managing Technical Complexity
Addressed complex manual steps (e.g., cloud access configuration)
Initially exposed full instructions, then refined based on feedback
Introduced progressive disclosure, collapsible help, and contextual guidance
Prototyping for Alignment
Built a fully connected, high-fidelity interactive prototype
Used the prototype to communicate system behavior across teams
Enabled stakeholders to explore and validate the product before development
Mid-project pivot
The platform changed near the finish line. The team said it couldn't be done in time.
In early 2023, when the design was almost done, business direction changed. The product would now be delivered through Premier — Dell's B2B eCommerce portal — instead of the APEX Console we had been designing for.
The team was concerned it couldn't be done in time. I was confident it could.
The reason wasn't that I work fast. It was that the prototype was built on solid component structure — reusable, well-organized, consistently applied. When the platform changed, the underlying flows and interaction logic held. What needed to change was mostly visual and layout.
I updated the designs, met the engineering deadlines, and also built a separate version of the prototype specifically for the Dell Tech World keynote — working with marketing and a third-party production company to get it stage-ready.
The lesson: good component structure isn't just about efficiency day to day. It's what makes you resilient when things change unexpectedly.
Key Design Decisions
Step-by-Step Deployment Flow
Deployment involves decisions that don't belong together. Basic setup is a different kind of thinking than performance configuration. Putting everything on one page would have forced users to process decisions they weren't ready for yet — and in infrastructure work, a misconfiguration has real consequences.
I grouped each step by decision type: what you're deploying → where it's connecting → how it's configured. Each step has a clear scope. Users can complete it and move on without holding everything in their head at once.
Topology visualization over text-based status tables
The system architecture is genuinely hierarchical — it can go four or more levels deep. A table would have required users to mentally reconstruct relationships the UI was hiding. For ITOps users troubleshooting live systems, that cognitive overhead is unacceptable.
The topology view encodes two types of information at once: structural relationships between components, and the health/connection status of each. Neither is expressible in a table without significant loss. The visualization isn't decorative — it's the only format that lets users understand what they're looking at and what might be wrong at the same time.
Progressive instructions for Cloud Access credential entry
The Cloud Access step requires manually configuring AWS Role ARNs and trust policies — a process involving copying values between two systems. There's no way to automate this; it's a constraint of AWS IAM.
My initial instinct was to show all instructions by default, since users would almost certainly need them. Early feedback flagged that showing everything upfront felt overwhelming, even for technical users. I redesigned with progressive disclosure: instructions collapsed by default, with "Where do I find this?" microcopy at each field. The goal was to make the complexity feel manageable without pretending it doesn't exist.
Configuration grouped by decision type
Rather than presenting configuration settings in the order the backend processes them, I grouped them by the type of decision the user is making: Basics (what is this and where does it live) · Performance (capacity and IOPS) · Availability (redundancy) · Networking (connectivity).
This matches how storage administrators think about their systems — as layered concerns, each with its own domain logic — and lets users with different roles navigate directly to the section relevant to their expertise.
Prototype as the team's source of truth
As more teams joined the work, static mockups stopped being sufficient for alignment. People interpreted designs differently because they couldn't experience the conditional logic or end-to-end flow.
Maintaining a single, fully connected prototype that represented the current state of the product at all times was intensive and not scalable. But it became the "bible" — the single reference for leadership, marketing, PMs, researchers, and engineers. That shared reference reduced misalignment in meetings and ultimately made the mid-project pivot manageable, because the component structure was solid enough to absorb the change quickly.
Final design
End-to-end experience across four workflow areas
Deployment — Simplifying complex setup
The deployment journey was designed to balance technical depth with guided clarity. Each step surfaces only what’s needed at the right time — helping users deploy storage on AWS confidently
Step 1
Product Selection — Guided Start
Visual cards for Block Storage vs. File Storage reduce decision friction. Progressive disclosure surfaces only the key decisions (product type, provider, region) while keeping the interface visually light.
Step 2
Cloud Access — Secure Connection
Complex technical inputs (Role ARN, trust policies) are made approachable through progressive instructions, collapsible help text, and inline "Where do I find this?" microcopy — anticipating user confusion without cluttering the interface.
Step 3
Deployment Configuration — Resource Setup
Settings grouped into Basics · Performance · Availability · Networking. Inline help and sensible defaults throughout. As users enter values, the interface calculates the minimum required AWS infrastructure — setting expectations before provisioning begins.
Management — Centralized visibility and control
View
Cloud Deployment List — Monitoring across environments
Status-driven table with color-coded health indicators for fast system assessment across AWS and Azure.
Capacity metrics and group details inline — no drill-downs required for routine checks
System-level and cloud-access views for different user roles
Detail
Deployment Details — End-to-end configuration insight
Layout split into system configuration (storage, region, IOPS) and real-time health monitoring
External navigation to PowerFlex Manager and CloudIQ for deeper analytics — maintaining continuity across Dell platforms
Mobility section for cloning and data movement without leaving context
Admin
Cloud Access Management — Credential oversight
Tabbed layout segments cloud providers (AWS · Azure · GCP) — scalable for future integrations
Account groups and permission details in a lightweight, searchable table
Data Mobility — Data movement simplified
OVerview
Mobility — Centralized view of data movement
Tabbed navigation for Volume · Application · File mobility groups
Source → target flow arrows make migration direction immediately readable
"Create mobility group" CTA promotes a clear next step without requiring menu navigation
Group
Group Overview — Visualizing data flow across environments
Visual flow diagram: source (on-premises) → target (cloud) → clone sets
Transfer method and progress details surfaced upfront for context without drill-down
Clone
Clone Sets & Clone Details — Managing replication
Sortable table: clone name · image time · mapping status
Inline "Create clone" — no context switching required
Editable mappings in detail view simplify volume association updates
Impact
The most measurable impact wasn't in the product — it was in how the team worked.
Product launched November 30, 2023 · Demonstrated on the main stage at Dell Tech World · Shown at AWS re:Invent
Defined foundational UX patterns for a new multicloud product
Established a clear interaction model for complex infrastructure systems
Reduced cognitive load by structuring deployment into guided workflows
Made complex multicloud workflows understandable by structuring deployment into clear, guided steps.
Enabled consistent understanding of system architecture through topology visualization
Aligned product, engineering, and leadership through a shared interactive prototype
Reduced repeated clarification cycles during design and development
Established reusable patterns that informed future multicloud experiences
Reduced repeated clarification cycles across teams by using the prototype as a shared reference for product behavior and system logic.
Served as the primary alignment tool across teams, enabling stakeholders to converge on a shared understanding of the product direction
What teammates said
"Many, many teams have come to rely on the Cirrus prototype as the source of truth for what the Cirrus experience will be. He's the Figma master, and the UX Cirrus team wouldn't have been able to deliver as swiftly or as well without his incredible skills in design and management."
Maggie Harney · Cirrus prototype recognition
"You consistently delivered quality work, on time, and never let ambiguous direction or requirements stop you from designing an excellent user experience for Multicloud customers."
Kathryn Ward (Manager) · Game Changer 2 Award — APEX Navigator for Multicloud Storage
"Min worked meticulously and tirelessly on the Figma prototypes that were absolutely essential for the DTW Day 2 APEX keynote demo. Without Min's help we would not have gotten the work done in the extremely short timespan that was required."
David O'Dell · Dell Tech World keynote recognition
Key Insight
The visual design is the last 20% of the work. The first 80% is spending enough time with the system to understand which decisions users actually need to make, in what order, and what they need to know at each step — versus what can safely wait.
A prototype is not a presentation tool. It's a decision-forcing function. When you put a high-fidelity, fully connected prototype in front of engineers, PMs, and leadership, you're not showing them what something looks like — you're forcing everyone to confront what they actually think should happen. That's where misalignments surface. That's where the real design work gets done.