APEX
Designing Cloud-as-a-Service Product Experiences for a New Subscription Business Model
Dell APEX is Dell Technologies' as-a-Service portfolio — cloud, storage, compute, and data protection delivered through a subscription model. It marked a fundamental shift from one-time hardware sales to recurring services, and the digital experience needed to match that ambition.
Problem
As APEX expanded, the digital experience did not evolve at the same pace. Dozens of offer pages grew organically, creating inconsistent structure, redundant content, and confusion around what APEX was and how its solutions differed.
Outcome
I led UX design for 10+ APEX product and offer pages that contributed to 60%+ growth in subscriptions and annual recurring revenue. Simplified a fragmented portfolio into a scalable experience by standardizing page architecture, consolidating overlapping offerings, and grounding every design decision in multi-round qualitative research.
Company
Dell Technologies
Role
Collaborators
Platform(s)
Responsive Web
Year
2022
My role
I led UX design for APEX product and offer pages from 2021 to 2023, working with a small design team that included a dedicated UX researcher, and partnering with product managers across multiple business units. My work spanned the full design process from research through delivery, and included driving the portfolio consolidation effort that became the structural foundation for the redesign.
Understanding the system
APEX was not a single product. It was a growing portfolio spanning cloud services, storage, compute, data protection, custom solutions, and industry use cases, each owned by a different business unit with its own goals, messaging priorities, and launch timelines.
As the portfolio expanded, structural tension emerged. Business units wanted to emphasize their individual solutions. Marketing focused on positioning and differentiation. But research told us something different. Enterprise buyers were already multicloud-literate. They did not need to be convinced of the value of cloud. They needed to quickly understand what APEX specifically offered, how its solutions differed from each other, and what to do next. The existing experience was not set up to answer those questions.
Working with our UX researcher, I mapped the portfolio across categories, buyer journeys, and business unit ownership. What we found was a system where similar offerings were framed as separate solutions, page architecture varied across categories, and messaging was written for marketing audiences rather than the technical buyers who were actually evaluating the platform.
Goals and success signals
After mapping the ecosystem challenges, I aligned stakeholders around clear goals for both enterprise buyers and internal teams, with defined signals to measure progress.
These goals defined what success looked like for the redesign and guided design decisions throughout the project.
Constraints and complexity
APEX was already in motion. The portfolio was expanding rapidly within an existing enterprise environment, shaped by technical, organizational, and operational constraints.
Key constraints
Distributed ownership across business units
Each APEX offer was owned by a different business unit with its own roadmap and revenue goals. There was no centralized governance model, and stakeholders were often protective of existing pages. Every structural decision required alignment across independently operating teams.
Marketing versus technical buyer tension
Marketing focused on positioning and differentiation. Enterprise IT buyers focused on architecture transparency and risk evaluation. The experience needed to support both without overwhelming either audience.
Evolving product strategy
The portfolio was actively changing while we were designing. Offers changed scope, products were renamed, and portfolio structures shifted between design and launch. The system needed to absorb that change without becoming inconsistent for users.
Page fragmentation and redundant content
Offer pages had grown organically as the portfolio expanded. Similar solutions were framed as separate offers, messaging overlapped, and hierarchy varied across categories. Fragmentation had become a portfolio-level problem, not a page-level one.
CMS and engineering constraints
The redesign had to work within existing CMS capabilities and engineering bandwidth. Solutions needed to be modular and technically feasible inside an established ecosystem.
Early insight
What looked like a collection of inconsistent pages was actually a portfolio architecture problem. Solving it required redefining how the portfolio was organized as a system, not just refining individual pages.
Platform structure and portfolio architecture
As the early insight made clear, the issue was not isolated to individual pages. It was structural. Before redesigning offers, we needed to define how the APEX portfolio should function as a coherent system.
Mapping the ecosystem
Working with our UX researcher, product leads, and my design manager, I mapped the full APEX portfolio across categories, buyer journeys, and business unit ownership. This allowed us to step back from individual pages and evaluate the platform as a system.
What we found
Similar services were positioned as separate offers without clear differentiation. Category boundaries were blurred across cloud services, custom solutions, and use cases. Navigation did not reflect how enterprise IT teams actually evaluate infrastructure. And there was no consistent hierarchy to support comparison across the portfolio.
Reframing the problem
Rather than refining pages independently, we reframed the work as a portfolio architecture challenge. The goal became defining a clear, scalable structure that supported distinct category definitions, clear differentiation between adjacent solutions, alignment with buyer evaluation stages, and room for future portfolio expansion without fragmentation.
To understand the full scope of the ecosystem, I mapped all existing APEX pages and grouped them into categories, making visible where structure and differentiation were missing.
How might we design a scalable page framework that helps enterprise buyers evaluate APEX solutions while enabling multiple business units to launch offers consistently?
Standardizing page architecture
With the portfolio structure defined, the next challenge was creating consistency across individual offer pages. Pages had been built independently by different business units, resulting in inconsistent structure, varying levels of technical detail, and messaging that did not match how enterprise buyers actually evaluate infrastructure.
Understanding the audience
Our research surfaced two primary personas that shaped every framework decision. Maria, an autonomous IT Specialist who arrives knowing exactly what she needs and wants to self-serve through technical detail. And Tim, an experienced Enterprise VP who is relationship-driven, cautious online, and needs trust signals before engaging deeply with a solution.
Designing for both simultaneously was one of the central tensions of this work.
What research told us
Beyond the personas, research also revealed where the existing experience was breaking down across the full buyer journey. Customers were not finding what they needed at the Learn stage. There was too much redundancy, inconsistent messaging, and no clear path from understanding a solution to evaluating it.
Translating findings into a framework
I translated those findings into a standardized offer page framework organized around the key questions enterprise buyers ask when evaluating infrastructure solutions. The framework was applied across all APEX offer pages, giving different business units a shared foundation for launching new services while maintaining a consistent experience for buyers.
Offer Page Framework
Overview
Clear value proposition and core benefits, supported by validation signals such as customer proof points and analyst references.
How it works
Architecture explanations, operational model, and integration details for technical audiences.
Use cases
Real world scenarios and examples organized around buyer challenges, not product categories.
Next steps
Clear progression toward trial, demos, or engagement with Dell teams.
Resources
Supporting documentation, white papers, and deeper technical material for buyers who needed to go deeper before making a decision
Designing the APEX product experience
With the portfolio structure and page framework defined, the next step was translating that strategy into the actual APEX product experience. This work spanned multiple layers of the ecosystem, starting with the APEX homepage, continuing through the portfolio architecture, and extending into individual offer pages.
Redesigning the APEX entry point
The APEX homepage was the primary entry point into the platform, but the original experience functioned mostly as a marketing introduction. The portfolio was difficult to discover and required additional navigation to explore. The redesign reframed the homepage as a starting point for navigating the APEX ecosystem, introducing clearer pathways into the portfolio and helping users quickly identify where to begin.
Before - What wasn't working
The original homepage led with brand messaging and marketing modules. The portfolio was not visible from the entry point, requiring users to navigate deeper before they could explore available services.
After - A clearer starting point
The redesigned homepage surfaced core APEX service categories directly on the page, reducing navigation friction and giving users a clear starting point for exploring the portfolio.
Key design decisions
Introduced a portfolio-first homepage layout that surfaced core APEX solution categories directly on the page
Created clear entry points into the portfolio to help users move from high level messaging into solution exploration
Reduced competing marketing modules to prioritize navigation and product discovery
Established a scalable entry pattern that could support future portfolio expansion
Why this mattered?
Reframing the homepage as a navigation gateway helped users understand where to begin and how APEX was organized. It also established a scalable pattern that made it easier to introduce new services without increasing complexity.
Organizing the APEX portfolio
With the homepage acting as a clearer entry point, the next step was organizing how users explored the APEX ecosystem. The portfolio was still evolving internally, with different business units actively refining how their services should be positioned. The structure needed to support constant change without becoming confusing for users.
Portfolio structure
From the homepage, users could enter the APEX portfolio through clearly defined solution categories. Each category represented a group of related services designed to address specific infrastructure needs.
Expanding into individual offers
Within each category, users could explore individual APEX services, moving from high level solution areas into specific offers while maintaining context within the broader portfolio.
Key design decisions
Organized APEX services into clearly defined solution categories
Designed a hierarchical navigation model from homepage → portfolio → offer pages
Grouped related services to support easier comparison and discovery
Created a flexible structure that could accommodate new offers, consolidations, and portfolio changes over time
Maintained contextual navigation so users could move between related solutions without losing their place
Why this mattered?
Introducing a clear portfolio structure helped users understand how APEX services related to one another and where to begin. Just as importantly, the structure supported a rapidly evolving portfolio. As services were added, merged, or repositioned, the navigation model remained stable and understandable for users.
Designing scalable offer pages
With the portfolio structure established, the next step was designing the individual offer pages where buyers evaluated specific APEX services. These pages needed to support multiple audiences. Business decision makers needed to quickly understand the value and outcomes of a solution, while technical evaluators required deeper architectural and operational detail. To support both audiences, I introduced a standardized offer page framework that organized information in a consistent and predictable way across the portfolio.
Bare Metal as a Service (BMaaS)
APEX Bare Metal as a Service (BMaaS) is a compute offer that gives enterprise IT teams dedicated bare metal infrastructure on a subscription model. The page follows the full framework: anchor navigation at the top for fast self-direction, a clear product definition above the fold, overview and how it works sections for different audience depths, use cases, next steps, and a resources section for buyers who need to go deeper.
Managed Devices
APEX Managed Device Service is a fully managed subscription for enterprise PC fleets. It follows the same framework structure with a hero that leads with the customer outcome, feature highlights, business value metrics, device options, a customer story, and a clear next steps section for existing and prospective subscribers.
The framework at scale
The standardized structure was applied not just to individual offer pages but across multi-page product families. APEX Data Storage Services is one example, a suite of four related storage solutions each with its own offer page built on the shared framework. Showing the pages together illustrates how the system scaled across a family of related services while maintaining a consistent experience for buyers.
Key design decisions
Applied a consistent page architecture across all APEX offer pages
Structured information progressively from business value to technical detail
Designed pages to support both business decision makers and technical evaluators
Used anchor navigation to let users jump directly to the content most relevant to their evaluation
Ensured the framework could support different offer types without requiring custom page structures
Why this mattered?
Standardizing the offer page structure made it easier for buyers to evaluate APEX services across the portfolio. Because every offer page followed the same framework, users could quickly orient themselves regardless of which solution they were looking at. For internal teams, the framework simplified the process of launching new services by providing a reusable structure that could flex across different offer types.
Final solution overview
The final experience connected the homepage, portfolio navigation, and offer pages into a cohesive end to end journey. From the entry point through portfolio exploration to individual offer evaluation, each layer of the experience was designed to reduce friction and help enterprise buyers move forward with confidence.
The walkthrough below shows how these patterns come together across the platform.
Impact
The APEX pages contributed to 60%+ growth in subscriptions and annual recurring revenue during my tenure. That result reflected not just the design quality but the compounding effect of getting the fundamentals right: audience clarity, content hierarchy, and a framework that expert buyers could actually use to make decisions.
Beyond the metric, the work had lasting organizational impact:
The standardized page template was adopted across the portfolio and continued in use after I transitioned off the project
Portfolio consolidation reduced fragmentation and made it easier for internal teams to launch and maintain offer pages
The research surfaced insights that shaped content strategy beyond design, helping product teams understand how customers actually perceived APEX versus how it was described internally
The portfolio architecture established a scalable foundation that supported ongoing expansion without reintroducing inconsistency
Reflections & key learnings
APEX taught me that the hardest part of this kind of work is rarely the design. It's getting alignment. Making the case for simplicity to stakeholders who are protective of their existing pages, staying grounded in research when everyone just wants to ship, and building enough trust with product and engineering that your recommendations actually stick.
The research also changed how I thought about the audience. These were expert IT professionals making serious infrastructure decisions. They didn't need to be walked through a funnel. They needed the right information, organized in a way that respected how they actually think and evaluate. That realization shaped a lot of decisions, from how we structured pages to how we pushed back on marketing copy that talked down to users.
Looking back, I would have pushed harder for consolidation earlier. By the time I joined, a lot of the complexity was already baked in and untangling it took significantly more effort than it would have if the structure had been right from the start. That's something I carry into every project now.