SingleStore | Cloud Database Platform
SingleStore's new credit-based pricing model was launching to simplify cluster creation for trial users. However, early beta feedback suggested confusion around how credits were applied, what "upgrade" meant, and how to estimate monthly costs.
This research aimed to identify usability friction in the credit purchase and cluster creation flow before launch, enabling the team to refine terminology and UI clarity to reduce support burden and improve conversion.
SingleStore was transitioning from a traditional pricing model to a credit-based system to give users more flexibility and transparency. However, this introduced new complexity:
Product leadership needed to validate the new flow before launch to avoid conversion drops and support costs.
As the solo UX Researcher on this project, I was responsible for:
While I owned research execution end-to-end, success required close partnership with Product and Design. I collaborated with the Product Manager to validate that task scenarios reflected real trial user workflows—she flagged that most users configure clusters immediately after signup rather than exploring first, which informed scenario sequencing. After the first 3 participants, I shared preliminary findings with the Design team: the "Upgrade" confusion was unmistakable. They quickly mocked up alternative button labels ("Add Credits," "Purchase More Credits") which I tested with the remaining 2 participants. This rapid iteration loop—research finding → design hypothesis → validation—compressed what could have been a multi-month cycle into a 2-week sprint.
Designed task-based scenarios simulating real workflows: (1) Sign up for free trial using 300 credits, (2) Configure and deploy a database cluster, (3) Understand estimated monthly credit usage, (4) Purchase additional credits when running low.
Recruited 5 participants via internal beta program representing financial services, aviation & aerospace, IT services, and communications industries.
Conducted remote testing using Maze.co platform with participants completing tasks using Figma prototype. Think-aloud protocol captured reasoning and confusion points. Post-task questions probed comprehension of terminology.
Collected quantitative metrics: Task success rate, ease ratings (4.2/5 average), time on task.
The cluster creation flow tested with users: from initial signup through configuration to security settings
The 'upgrade' flow that caused terminology confusion — users expected to change cluster configuration, not purchase additional credits
Analyzed qualitative feedback to identify patterns: (1) Terminology confusion — 4 of 5 users misunderstood "upgrade" as changing cluster configuration, not purchasing credits, (2) Mental math burden — 3 of 5 users requested automatic calculation of remaining credits, (3) Credit scope ambiguity — 2 of 5 users uncertain if credits applied to storage costs.
Applied severity ratings based on frequency (how many users experienced the issue) and impact (how much it eroded trust or blocked task completion).
Delivered 3 prioritized recommendations: (1) Change "Upgrade" terminology to "Add Credits" or "Purchase More Credits", (2) Show remaining credit calculation with "You'll have X credits remaining after this purchase", (3) Clarify credit application with tooltip: "Credits apply to compute usage; storage billed separately".
Product team implemented recommendations #1 and #2 fully, and #3 as light guardrails plus just-in-time messaging. I worked directly with the Product Manager to prioritize fixes based on implementation complexity and impact. "Add Credits" was a simple label change (shipped in 2 days), while automatic credit calculation required backend logic (2-week sprint). Engineering initially suggested deferring #3 (credit scope clarity via tooltips) to a later release, but I made the case that tooltip copy was low-effort/high-impact—they agreed and shipped it with the initial fix. This collaborative prioritization ensured we addressed the highest-impact issues without delaying launch.
Participant feedback showing confusion about "Est. Usage per Month
Users expected "Upgrade" to mean changing cluster size/configuration, not purchasing additional credits. 4 of 5 participants expressed confusion, which could block users from purchasing credits when trials ran out.
UI showed "Est. Usage: 180 CR/month" and "Credit Balance: 300 CR" but didn't calculate "Remaining: 120 CR after 1 month." 3 of 5 users requested this feature to reduce anxiety about unexpected charges.
Users didn't know if credits applied to compute only or also storage. 2 of 5 users asked explicitly. Uncertainty about total cost could block purchase decisions or drive support tickets.
80% of participants rated cluster creation as "very easy" (5/5). The happy path worked well — issues were isolated to specific terminology and information gaps rather than fundamental workflow problems.
Users wanted visibility into exactly what they'd be charged for before committing. One user said: "Setting that would allow me to 'pause' the service if I ran out of credits, rather than charge me."
When credit estimates were clearly labeled with context (e.g., "Based on 24/7 usage for 30 days"), users felt more confident. Ambiguous labels like "Est. Usage per Month" caused uncertainty.
Evidence: "Upgrade" Terminology Created Confusion
