Dell Partners
Integrating partners in to the APEX cloud platform
Partners are companies that Dell partners with to sell products. Every transaction aligns to internal a business sales motion, i.e. Distribution, Resell, Host, etc.
Currently partners drive 65% of Infrastructure Solutions Group (ISG) and 84% of VxRail revenue
Dell's Partner Program provides products, services and support that provide:
Access to the Dell ecosystem, with a presence in 180 countries, and a market share of over $45B, leading a multinational IT vendor serving 99% of Fortune 500 companies
Benefits structure based on revenue and certification.
Our goal was to enable Partners to transact within APEX (Dell’s Cloud Platform), focusing on Distributors and Solution Providers for the big private preview release.
The Challenge
A partner in the APEX context comprised of many users, many roles that can function as a Tier1, Tier2 or Tier3 entity with Dell - creating many to many relationships in our system.
This effort required collaboration across multiple workstreams across Dell with varying levels of design maturity. This meant we needed to work with both agile and waterfall teams.
Additionally, the cloud subscription model is completely different from the traditional business model on the Capital Expenditure side. We needed to educate the Business Operations Team (BOT) on how a partner will work within the console and how it would impact those traditional practices.
Limitations
Data in the partner portal can be viewed as "bad data" as in, is not mapped in a way that is easily usable in APEX, resulting in some manual processes.
APEX was initially designed for direct customers in mind. Since this was an entirely new type of user with different needs, every part of the cloud console required updating.
Due to the quick turnaround deadlines, requirement development, UX design and testing scenarios were being created in parallel.
The given requirements were limited in detail and required multiple working sessions to develop them so we could efficiently move forward with the designs without unnecessary rework.
What is a Dell Partner?
The Process
Discovery
Terminology Breakdown
Partner Type and Commerce Functions Matrix
Requirement Building
Miro Workshops with Stakeholders
Goal Writing
UI Designs
Breadth of work
Breakdown of the views for Solution Providers, Distributors, End Customers, and Dell Sales Associates
Key Features
Continuing Work
Wins
Changing the Mental Model
Because Partners were new to APEX and our team, we had to quickly do a lot of discovery work.
There was so much new vocabulary and acronyms that we started a mini dictionary with any new terms and explained in plain language their meaning.
Because Partners were coming from the Capital Expenditure side of the company (CAPEX), we needed to translate what that meant from a cloud standpoint (Operational Expenditure, or OPEX for short.)
We created this chart to help map all the different Partner tracks, what they do, and what those actions would be in APEX.
This was integral for us to get the big picture, but it also functioned as a communication tool, not just for us but across the multiple teams we collaborated with.
Requirement Building
The requirements we received were very limited and were missing key parts of the APEX ecosystem. We received these seven requirements to start from.
To remedy this, we held workshops with the stakeholders to nail down all the details of the user flows using Miro. This was instrumental in creating unity with the siloed teams and move efficiently towards our goals.
Goal Creation
Once we understood Partners from a CAPEX and OPEX perspective, and the desired requirements, we wrote mission statements to measure our designs against.
If we achieve these goals, we will open up new market opportunities that are unavailable today, accelerating sales and increasing stickiness, ensuring we become a full As A Service provider in the industry.
The Designs
Because Partner was a new type of user for the APEX cloud console, the breadth of the designs needed were immense.
A Problem of Scale
A partner introduces new lenses/states to view APEX. It adds many new layers of users, permissions, behaviors, and states that require more complex interactions. We moved from a singular user navigating in a linear way to multiple users navigating in a highly dynamic non-linear way.
Because of this each part of APEX required new designs with new flows and actions. This was made extra challenging since new features were being added to APEX constantly, so we had to continually communicate with all the other APEX teams, and update our designs accordingly when their designs changed.
This would be one thing if it were just one new user type, but there are seven different partner types. Although we were focused on integrating two of them for the first release, we had to create scalable designs that would accommodate those other partner types being added. We also needed to account for the end customer sees when they are using a subscription through a partner. Plus the Dell Sales Associate screens for when they onboard a Partner and their associated customers and resellers they do business with.
Partners can interact as different Partner Tracks.
The different tracks help them bill things correctly and have the correct views/context for each screens. For example, the Solution Provider Track is when a Partner is selling directly their own customer. Whereas the Distributor Track is when a Partner sells to another Partner.
To help Partners have context as to what business track they are acting as, we introduced this “Context Switcher” in the sub header bar. This allows the Partner to easily switch between tracks when needed to manage different parts of their business on the fly.
In this example screen, “Howdy Partner” (Our fake Partner company) is transacting as a Solution Provider, they will select a customer they would like to purchase a cloud subscription for.
In the case of a Distributor,
They would select a Reseller that they are transacting with as well as the end customer who will be using the subscription (which is required for legal reasons.)
These context selections where they need to select a customer and potentially a reseller are necessary for three different flows where the Partner needs a view through this specific lens of selections, such as in the order creation flow, support, and metrics pages.
Additional options were needed for the Site Details Page since you could be shipping hardware to either, a Partner site, a Customer site or a Reseller site.
The Billing & Payments section required updating to show Partners where their costs were going and which customers were associated with each subscription. We plan to expand these pages with more robust filtering and reporting.
Customer Management
The only new page we added was a customer management page for Partners to view and manage their customers as well as have an easy jumping off point to view subscriptions and analytics associated with that customer.
Although it wasn’t part of the original requirements we felt this was a necessary addition to the platform with the complex relationship between entities.
In addition to the Partner facing screens, we had to consider the Dell Sales Agent views. At the time, manual onboarding was required by a Dell Sales Agent, so we needed to revamp their onboarding screens to allow them to give access to new Partner users and make those associations in the system to the Partner’s customers and resellers.
Continuing Work
Because of the expedient deadline, the design process was done in tandem with wireframe creation. So the next steps are to test the designs.
Recommended Testing Focus:
Organization selector – do users understand the need to set context
What views in general do partners need?
Data visualization vs reports
How does change in context affect current APEX interactions
Interstitial pages, how do they impact a users mental model of APEX
Working on Upcoming Features
Updates to the permission models to include more complex relationships, such as the user flow shown here outlining the interaction between a Partner and a Customer get approval of the terms and conditions of the product.
Provisioning
Multiple track onboarding and automation
New Partner Tracks to be added: Cloud Service Providers, Independent Solution Vendors, Original Equipment Manufacturers, and Telecommunications
Toggling between Partner Tracks and direct purchasing for themselves.
Globalization: challenges in UI and legal requirements
Wins
We successfully launched our designs in time for Private Preview as well as made in roads with teams at Dell who were unfamiliar with design thinking.
We achieved this through:
Adapting to different working styles and processes. Being able to make changes on the fly. Good communication within the team.
Adapting the tools to our need. We built artifacts as we needed them.
Communicated the designs across the company, presentations that gave teams clarity and focus.
Teaching design thinking through our methodology.
Business Operations Team PM, advocating for discovery, for us all to come together and define what the experience should be.
And getting more robust requirements for the upcoming releases.