CrowdStrike · Self-service purchasing

Self-Service Cybersecurity Purchasing

The assignment was to design a checkout, but the customer was really moving through account, payment, subscription, and order rules that had previously been handled through assisted sales. I had to make those rules understandable without making the customer learn the organization behind them.

My role
Senior UX Designer
Primary actors
New and returning customers, marketing, product, engineering, leadership, and billing systems
Status
Final designs informed implementation; exact launch scope and production outcomes are unverified
System scope
Account state, shipping, payment, order review, recovery, and responsive continuity

Delivered

New- and returning-customer designs

Final flows and implementation decisions are documented.

Resolved

Payment and order-context states

Recovery and dependency decisions were included.

Not measured

Checkout-specific production outcome

Conversion, adoption, support reduction, and revenue causation are not claimed.

Business context

Turn assisted enterprise purchasing into a self-service path for SMB customers

CrowdStrike’s enterprise sales model was built around high-touch deals. The checkout connected a marketing-led storefront to Chargebee customer and payment records so SMB customers could understand a product, create or verify an account, provide billing and payment information, and complete an order.

Service challenge

The screen was simple; the customer states behind it were not

Account identity, subscription state, payment methods, product eligibility, order records, and Chargebee all shaped what a customer could do. A clean screen would not help if those dependencies produced the wrong next step.

Delivery constraints

Keep the model adaptable while account and payment rules moved

Cart scope shifted, payment options changed, and the team was learning Chargebee’s boundaries. Two marketing teams, engineering, product, and product leadership brought different priorities, so the design had to preserve a stable sequence while individual requirements changed.

Customer states

Design the state model before polishing the path

New and returning customers required different context. Missing payment methods, incomplete accounts, and existing subscriptions needed explicit recovery.

  1. Identify account
  2. Resolve eligibility
  3. Select product
  4. Recover payment
  5. Confirm subscription
  6. Preserve order context
New- and returning-customer checkout state connected to Chargebee.
Account state · Customer identity connected to billing records.
Checkout screen for adding required account information.
New customer · Required account information.
Checkout screen for adding shipping information.
New customer · Shipping information.
Checkout screen for adding payment information.
New customer · Payment information.
Recovery state explaining that a saved payment method is missing.
Recovery state · Missing payment method.
Recovery flow for adding a new payment method.
Recovery flow · Add a new payment method.
Returning-customer state with payment resolved and order ready for confirmation.
Returning customer · Payment resolved and order ready.

Cross-functional decision

Use familiarity as a risk-control strategy

Competitive and heuristic review compared stepped, all-in-one, and sidebar directions. The team selected the all-in-one model because it kept the sequence and order context visible and could reflow naturally on mobile.

Checkout layout option considered during concept comparison.
Concept comparison · One of the structural directions evaluated.
All-in-one checkout structure selected for predictable progression and mobile continuity.
Selected direction · All-in-one checkout structure.
Sidebar checkout structure explored and later discarded.
Discarded alternative · Sidebar structure exceeded the final project scope.
Review-order layout documenting order context before purchase.
Order context · Review state before confirmation.

Orchestration map

Trace each customer state back to the rule creating it

The checkout was not one happy path. Customer progress depended on account, payment, and order states, with recovery interrupting the sequence when those records were missing or incomplete.

Checkout state-orchestration map

Reconstructed from preserved screen flows and project notes. It is an interpretive service-design artifact, not a record of the production Chargebee architecture.

On smaller screens, each stage is stacked for easier reading.

Lane / stage
Identify
Account
Shipping
Payment
Review
Purchase
Customer
Signs in or continues
Creates or verifies account
Confirms details
Uses or adds method
Checks order and terms
Submits purchase
Interface
Branch by customer state
Expose missing information
Keep sequence visible
Interrupt with recovery
Preserve order context
Confirm outcome
Backstage
Match customer record
Validate required fields
Apply shipping rules
Read and write payment state
Validate commercial rules
Create order record
Team alignment
Marketing and product entry rules
Account requirements
Engineering constraints
Chargebee boundaries
Leadership and legal input
Implementation handoff
Recovery
Unknown identity
Incomplete account
Invalid details
Missing or failed payment
Changed order state
Failure confirmation

Identify

Customer
Signs in or continues
Interface
Branch by customer state
Backstage
Match customer record
Team alignment
Marketing and product entry rules
Recovery
Unknown identity

Account

Customer
Creates or verifies account
Interface
Expose missing information
Backstage
Validate required fields
Team alignment
Account requirements
Recovery
Incomplete account

Shipping

Customer
Confirms details
Interface
Keep sequence visible
Backstage
Apply shipping rules
Team alignment
Engineering constraints
Recovery
Invalid details

Payment

Customer
Uses or adds method
Interface
Interrupt with recovery
Backstage
Read and write payment state
Team alignment
Chargebee boundaries
Recovery
Missing or failed payment

Review

Customer
Checks order and terms
Interface
Preserve order context
Backstage
Validate commercial rules
Team alignment
Leadership and legal input
Recovery
Changed order state

Purchase

Customer
Submits purchase
Interface
Confirm outcome
Backstage
Create order record
Team alignment
Implementation handoff
Recovery
Failure confirmation

Tradeoff

Protect the workflow when a visual decision changes

I recommended a restrained card treatment; product leadership preferred a larger branded visual. I presented the competitive evidence and mobile implications, then carried the selected direction into the final design while preserving sequence, review, and recovery.

Validation boundary

Use the preserved evidence without inventing precision

The work included competitive and heuristic analysis, concept comparison, stakeholder reviews, and usability testing.

Outcome and limits

The workflow is documented; the business effect is not

The delivered work included the selected all-in-one model, new- and returning-customer screens, persistent order context, missing-payment recovery, and responsive criteria.

  1. Measured: no checkout-specific production metric is sufficiently supported
  2. Context only: the work occurred during company growth; causation is not established
  3. Not proven: launch scope, completion, conversion, adoption, support reduction, or revenue impact

Takeaway

Familiarity was a risk-control decision, not a lack of ambition

The important work was translating account and payment rules into understandable states, preserving recovery, and knowing which visual tradeoffs could change without breaking the customer workflow.

Service design, human-centered AI, and workflow transformation

I help teams make complex workflows clearer, more reviewable, and easier to act on.

© 2026 Ariel KohSeattle, Washington