UX Project
Frictionless onboarding with Magic Link
HPE customers needed a simpler way to get started with the GreenLake Cloud Platform (GLCP). Before using any service, they had to manually claim and activate each device or subscription, often entering long serial numbers or navigating complex onboarding flows. This slowed adoption and created friction for every new customer.
Timeline: 3 Months
Role: Lead Product Designer
Tools: Figma, Miro, Slack, Microsoft Teams, Microsoft Outlook, Notion, and Jira.
Problem: “In today’s world, it takes multiple steps for customers to add their devices and subscriptions to their accounts before they can start managing them. We need an easy way for customers to claim and activate their devices and subscriptions in GLCP.” as stated in the HPE Product Requirement Document
Challenge: How might we reduce onboarding friction so customers can activate devices and subscriptions in minutes, not hours?
Solution: We designed Magic Link, a feature that:
Eliminates manual serial number entry by providing a single activation link.
Lets customers onboard devices and subscriptions directly to their accounts with one step.
Creates a faster path to value so customers can start managing their resources immediately.
Getting Started
This project was originally scoped by Greg Furuiye, who proposed implementing the onboarding workflow using an existing wizard component from our design system. When I joined, I inherited his initial requirements and worked with the Product Line Manager (PLM) to refine them, expand the feature scope, and design the full end‑to‑end flow. I led the definition, design, prototyping, and usability validation phases, collaborating closely with engineering to ensure a smooth handoff into development.
Research & Insights
Discovery II - Understanding resource types and dependencies
We identified four types of resources that customers needed to onboard:
Service subscriptions: cloud services customers could claim independently.
Infrastructure subscriptions: must be assigned to a service during onboarding before the wizard can finish.
Devices: physical hardware that could be claimed on its own.
Hard‑attach devices: hardware tied directly to specific subscriptions. These had to be claimed in sequence: you couldn’t claim the subscription without also claiming the corresponding device.
The onboarding flow needed to handle any combination of these resources:
All at once, if the customer purchased everything together.
Individually, if they only purchased one type.
The feature had to automatically present the correct steps in the right order, while still feeling seamless and low‑touch for the customer.
Design & Iteration
Insights - Creating a flow chart
Before exploring individual interactions, I needed to test whether the full onboarding flow was even viable. The goal was to support any combination of onboarding elements, subscriptions, devices, and hard attach resources within a single, unified experience. To do that, I mapped out a high level flowchart showing how all pieces might work together. This helped me identify logical dependencies (e.g., certain subscriptions requiring device pairing), surface edge cases, and validate whether it was possible to consolidate these divergent onboarding paths into a single, adaptable wizard.
Once the core workflow was defined, I focused on designing a flexible wizard that could adapt to various customer purchases. This included service subscriptions, infrastructure subscriptions, devices, and hard attach devices, with each type having unique dependencies.
Iteration 1: Card Step Layout (Inherited Design)
Approach: A “card” layout for each onboarding step, users would scroll through cards representing resources, select them, and move on.
Exploration: We tested patterns for filtering, pagination, and table selection across cards.
Key Issue: Scale. Users could have hundreds of resources, making this layout unmanageable. Pagination was unclear, and interaction became clumsy.
Iteration 3: RBAC + Error Handling
Approach: We built for edge cases and real-world scenarios:
What happens if a user doesn’t have permission to onboard resources?
What if onboarding partially fails (e.g., one resource fails, one succeeds)?
Enhancements:
Introduced RBAC aware UI states and clearer error modals.
Added locking logic to reduce double claim risks.
Displayed dynamic access banners based on user role or org level restrictions.
Iteration 2: Conditional Steps in a Wizard
Approach: Shifted to a traditional wizard with 3 steps:
Subscription Selection
Device Selection
Review & Submit
We explored conditional logic within the wizard, for example, if a service subscription was selected in Step 1, we needed to introduce a new step for assignment before the user reached Review.
Design Challenge: How do we insert or skip steps without disorienting the user? What’s the right visual and navigational cue for steps appearing dynamically?
Solution
We designed Magic Link, a frictionless onboarding feature that would allow customers to activate all eligible devices and subscriptions in one step:
Single link activation: Eliminates manual serial number and subscription key entry.
Dynamic wizard flow: Automatically detects resource types (services, infrastructure, devices, hard-attach devices) and presents the correct steps in the right order.
Scalable design: Accommodates any combination of resources purchased together or separately.
The workflow was engineered to be modular, low touch, and capable of replacing the current manual onboarding process entirely.
Reflection & Next Steps
Magic Link was never intended to replace the existing onboarding process. It was designed as an additional, simpler path for customers who wanted a low touch option. Customers could still onboard devices and subscriptions manually through the platform, but Magic Link aimed to give them a faster, more automated alternative.
While the end-to-end workflow and UI patterns were solid, the discovery of two critical security and collision risks stopped us from shipping:
Security risk: While users were required to sign into their account before onboarding resources, anyone with the Magic Link could create a new account and claim the resources to it, bypassing intended ownership controls.
Resource collision risk: Two different users could potentially onboard the same resource to separate accounts at the same time.
We chose not to move forward until engineering could build safeguards for ownership validation and resource locking.
Next steps:
Partner with engineering to design verification layers before resource claiming.
Implement real-time collision prevention to ensure resources can only be onboarded by one account at a time.
Conduct usability testing on the wizard flow to validate that conditional steps and mixed-resource onboarding are intuitive.
Re-evaluate the MVP scope and sequence the security fixes so this feature can be shipped in a future PI.
Discovery I - How customers onboard resources today
Customers had to manually claim their devices and subscriptions in GLCP before they could start managing them. The process required:
Knowing order details upfront. This included serial numbers, MAC addresses, and subscription keys.
Completing multiple clicks and back and forth steps inside the platform.
Calling HPE Technical Assistance (TAC) when they hit blockers.
Customers expected a zero touch or low touch experience, something simple and automated. Instead, they got a manual process that slowed them down and caused frustration.
Adding to the friction, hardware and SaaS subscriptions came from different backend systems. GLCP received hardware serial numbers from the factory, while SaaS subscriptions flowed separately. Customers had to first claim their subscription key, then manually attach it to a hardware serial number that should already exist in GLCP, an extra step prone to confusion.