AI Onboarding Service Design Blueprint

Mapping the onboarding customer journey for GitLab Duo, from first awareness through ongoing feature use, to find out why onboarding was so painful and what to do about it.

Context & Contributions

We already knew from prior research that onboarding for Duo could be painful. Part of the reason is that Duo has a lot of moving parts: different SKUs, a seat count paradigm, an ever-evolving set of features, and so on. Those variables are all related, and they’re driven by front and back stage processes that traditional research and design methods sometimes overlook entirely.

I led this project and did the initial work building out the blueprint and flow diagrams myself. One other Staff researcher joined partway through to and added to it.


PROJECT DETAILS
ROLE: LEAD RESEARCHER
PROJECT TYPE: SERVICE DESIGN BLUEPRINT
TEAM MEMBERS: 2
DURATION: 2-3 weeks

Problem

Duo’s onboarding experience was hard to see whole. Existing research on it was scattered across separate studies, admin-focused research, end-user research, repackaging research, each looking at a slice of the experience rather than the full thing. Nobody had put together a single picture of the entire journey, from a customer first becoming aware of Duo through configuring it, assigning seats, discovering features, and giving feedback, with the front stage, back stage, and support processes that make each step possible.

Hypothesis

We believed that looking at this experience through the lens of service design, rather than a typical usability study, would surface more of the elements and relationships that actually shape the customer experience, and from there, give us insight into the root causes of the pain points customers were running into and what we could do about them.

Methods & Process

Understanding

We started by pulling together everything we already knew: existing studies on admin experience, end-user experience, and Duo repackaging research, linking back to the individual studies throughout the blueprint wherever they were relevant. On top of that foundation, we conducted 8 new interviews with internal stakeholders across 8 different AI-related teams at GitLab, to fill in the front stage and back stage detail that customer-facing research alone doesn’t capture.

Refining

We organized the whole journey into five flows: Awareness to Trial/Purchase, Configuration and Seat Assignment, End-user Setup, Feature Usage, and the Feedback Loop. For each step in each flow, we mapped out the customer action, the pain point behind it, who’s involved (marketing, product, sales, engineering, and so on), and the front stage, back stage, and support processes underneath it. We paired the map with a matching workflow diagram tracing the actual decision points customers hit along the way, including every point where they might abandon the process entirely, poor trial experience, complex self-managed setup, version compatibility issues, seat assignment problems, IDE integration challenges, and more.

Delivering

We synthesized everything into a set of takeaways and recommendations, grounded directly in stakeholder quotes rather than our own paraphrasing. A few threads came up again and again: the sheer complexity of onboarding given how many variables are in play, a gap between what users expect Duo to do and what it actually does, seat assignment tooling that lags behind the need for it, settings scattered across the interface with no clear owner, and self-managed customers facing a whole additional layer of infrastructure problems. Our recommendations followed those threads directly: get better at educating users on what Duo can and can’t do, document and spread known self-managed issues across the teams who interface with those customers, and consolidate Duo’s settings into one coherent, well-supported place instead of leaving them scattered.

Findings & Results

This work fed directly into real product changes. GitLab moved to a flex, consumption-based pricing model for Duo, addressing the value-clarity and buyer-education problems we’d heard about directly from stakeholders. Duo’s settings got consolidated and given their own dedicated settings page, instead of being spread across general settings and usage quotas the way stakeholders described. And GitLab shipped a new onboarding experience for Duo, along with new marketing materials on the website aimed at better educating users on what Duo can actually do.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *