Skills in use Collaborators
Design Product Management
UX Research Engineering team
Facilitation UX team
Content Design
Challenge
After joining CircleCI's growth team as a product designer, I collaborated with a research colleague to facilitate over 30 discovery interviews with new users. We found that many first-time users struggled to set up a meaningful project, leading to lack of adoption. We identified the largest customer problems:
» Configuring a project in CircleCI requires users to write code in YAML, which can be painful and error-prone, even for experienced developers. New users wer spending hours combing through documentation and forums just to get a simple use-case off the ground.
» The previous onboarding flow lacked sufficient signposting, context, and feedback, leaving users disoriented. Research participants said it was difficult to discern what happened as a result of their actions in the system, and why.
» A recent initiative to automate the project setup process resulted in users perceiving the experience was a black box, where they didn't have control over their own CI (continuous integration) configuration.
Solution
Our team conducted an in-person design sprint, iterated to create a spectrum of low-fidelity prototypes that we tested through usability research, and arrived at a new onboarding flow that:
» Uses our fine-tuned LLM to automatically generate YAML configuration for our users, as well as convert configuration files from our competitors to ease the process of migrating tools.
» Provides ample signposting and context to help users understand what happened, why, and what's coming next.
» Allows users to choose from a few different project setup methods based on experience level, preferences, and security requirements, creating a sense of autonomy missing from previous versions.
Learnings
Speed up early value.
Although we worked backwards from our ideal-state prototype to release parts of the new experience rapidly and get in-production user feedback faster, the first round launch took longer than expected. In the upcoming release phases, we plan to release smaller — but complete — pieces of the experience so we can learn from real user behavior.
These prototypes were intended to help us test hypotheses and assumptions we outlined as a part of our research plan. I worked at a medium fidelity when producing the prototypes to allow for lightweight iterations, and I made them as different as possible to ensure coverage of all the hypotheses in research.
Low-Fi Prototype 1: 'Fastest'
Tested the hypothesis: Despite different levels of experience, users would prefer onboarding to be more direct vs. more educational
Low-fi Prototype 2: 'Build as you go'
Tested the hypothesis: Signposting and context are key — Users want to know what’s coming next and why they’re being asked to take actions
Low-fi Prototype 3: 'Conversational CI'
Tested the hypothesis: Users would prefer to describe their pipeline in plain text and let us figure out how to write their YAML configuration
Low-fi Prototype 4: 'Vision'
Tested the hypothesis: Users would accept a longer onboarding process if it provided more educational content and guidance.
Low-fi Prototype 5: 'Template framing'
In research on the first four prototypes, templates came up frequently as something participants wanted, liked, or expected. This prototype helped us understand:
Would being able to try the product before account creation make users feel more confident?
Do users prefer an onboarding approach with more control, even if it means more required decisions?
Do users prefer opt-in over automagic?
Low-fi Prototype 6: 'Fast-Dash'
Combined the most successful aspects of two of the first prototypes. Questions it answers:
Do users prefer an onboarding approach with fewer required decisions, even if that means less control?
Does being able to view the workflow map + logs provide users enough confidence after the first pipeline runs?