# Findings These are findings for the [testing we conducted on paid flow prototypes](https://gitlab.com/gitlab-org/growth/ui-ux/issues/14). ### Option 1 (Group creation before checkout) _Four users interacted with this prototype_ [View prototype](https://invis.io/K2UEWKZDHBZ) This version was difficult for users to understand. People had a poor understanding of the purpose of groups that their subscription is associated with their group. They also didn't expect to create a group at this step, as we had not previously introduced the concept of groups at all before this point. There was also confusion on what 'level' of their organization represent with their initial group (entire org versus specific team or function). ### Option 2 (Auto-created group defined in onboarding) _Four users interacted with this prototype_ [View prototype](https://invis.io/MYUI51IAFW9#/389960140_00-Marketing-Site) Based on the feedback from the first version, we created a new version where the group was automatically created and the user enters the metadata after the payment step. We also included some additional copy to emphasize that a subscription is tied to an organization for that use case. This version was an improvement, and made it clear that the subscription was tied to the organization. However, it was still not apparent that the organization was represented by a group in GitLab. Additionally, having the group automatically created was especially awkward for the single user scenario. ### Option 3 (Group creation after checkout) _Two users interacted with this prototype_ Next, we created a hybrid of the two previous approaches. We took the original group creation experience, but placed it after the checkout process. We also added copy emphasizing that organizations are represented by groups in GitLab. This version flowed more naturally than the others. Users understood that they were buying a subscription for their organization. There was still some confusion on the idea that their organization was a group, but landing them on the group page for their organization alleviated some of these issues. ## Related findings * **Pricing page features are not clear:** While not a primary objective of this testing, we discovered a number of issues with our pricing page. Participants mentioned they didn't understand some of the features we listed, which were often described using brief phrases without detail. For instance, users gave multiple explanations for what they believed _Code Quality_ to be. Even amongst our team we could not reach a consensus. These features are likely creating confusion rather than conveying value. * **Cost presentation is misleading:** Another pricing page issue, we noticed that participants misunderstood our pricing model based on the presentation of _$X per user, per month_. Some users then noticed the _billed annually_ item, but others didn't and continued to believe they'd be billed monthly. This created confusion and some negative sentiment when we presented the user with an annual cost at the checkout page. Even those that did notice the annual text would sometimes incorrectly assume this would allow them to get prorated subscriptions if they cancelled before a year. * **The first step of our flow was misinterpreted:** After registration, we asked users for their name and role. This was completely unexpected. Some users thought this was a data grab and would be fed to Sales or Marketing. Others thought the _Role_ item would be used to set privileges/access levels. We noted that this info would be used to tailor onboarding, but users missed this. * **Users sometimes wanted to use a different email for their organization**: We asked users to supply an email address for the personal account they create in the first step of this flow. However, when we asked people if they were creating a subscription for their organization, they mentioned that they would want to associate a different email address with the subscription that was not limited to just them, such as eng@company.com. We didn't give them the ability to do this. * **Terminology added to confusion:** Users sometimes misunderstood the meaning of concepts like _projects_ and _groups_ and how they related to each other. This included thinking that groups could be nested under projects. Users ascribed this to using different terminology from the rest of the ecosystem. Instead of _projects_, they were expecting to see _repositories_. Users also called out other unrelated terms they found confusing, such as using _Kubernetes_ in the left navigation.