Designing a global onboarding system for complex delivery operations.

Context

A public onboarding experience backed by a global learning system.

New delivery partners were stepping into a fast-moving operational role with a lot to absorb before their first day. My work centered on the curriculum strategy and system behind the onboarding experience: what needed to be learned, how it should be structured, how the experience could scale, and how regional realities could be handled without creating a collection of disconnected programs.

Problem

Consistency at global scale, without losing regional flexibility.

A single global playbook risks ignoring local operating realities. A collection of independently produced regional programs becomes difficult to govern, localize, maintain, and update. The design problem was larger than any individual course or video. It was an architecture problem.

Constraints

• Mobile-first delivery, because onboarding is often completed on a phone and in short windows.
• Stakeholder review across learning, operations, product, communications, legal, and regional partners.
• Localization had to be designed into the structure, not added after English content was complete.
• The content needed to remain maintainable after launch by teams that did not build the original system.
• The experience had to balance confidence-building orientation with safety and operational expectations.

My role

Own the system, not just the asset.

I led learning-experience and curriculum strategy across the onboarding ecosystem, including the content architecture, reusable production patterns, localization readiness, governance logic, and alignment across stakeholders. The work sat at the intersection of strategy and execution: define the system, then stay close enough to the build to make sure the system actually held up.

Investigation

The work started by separating the onboarding request from the performance problem. What did a new delivery partner actually need to understand or decide before the first block? Which topics carried meaningful safety or compliance weight? Which concepts benefited from practice? Which information could remain reference material? That mapping shaped the architecture and prevented every topic from becoming the same kind of learning asset.

Decision

Treat onboarding as a system rather than a library of videos.

The core decision was to create one shared structure that could be localized and adapted without re-authoring the entire experience for every market. Governance and maintainability were treated as design requirements from the beginning rather than operational clean-up after launch.

Evidence

Use the evidence that can be published, and do not pretend the rest exists.

Specific internal performance measures are omitted to protect proprietary information. The public evidence is the scale of the system, the published customer experience, and the operating mechanisms required to support continued delivery across markets.

Reflection

Great onboarding is really a systems design problem.

The work became scalable because design, governance, tooling, localization, workflows, and the learner experience were treated as one ecosystem rather than disconnected deliverables. That lesson continues to shape how I approach learning design now.