Make it really clear how users can buy GitLab from the group billing page

changed milestone to %12.2

added Deliverable UX backend devopsfulfillment devopsgrowth frontend + 1 deleted label

changed the description

added to epic &1277 (closed)

changed the description

added priority1 label

assigned to @vitallium

added priority2 label

removed priority1 label

@tipyn Who would be the best person to ask about the logic of the Start your Free Trial CTA? I would like to know:-

Is it always displayed for new groups?
If a user starts a trial and it expires without upgrading, does it ever get displayed again?
If I downgrade from a paid plan (Bronze for instance) to a free plan does the banner ever get display?

@timnoah I don't know who originally implemented this, but @vitallium (possibly with @dennis's help) could take a look at the code to understand what the logic is. We should go straight there to find the answer.

@dennis @vitallium can you help, please?

@timnoah

Is it always displayed for new groups?

Yes but see conditions below.

If a user starts a trial and it expires without upgrading, does it ever get displayed again?

No, it will no be displayed again.

If I downgrade from a paid plan (Bronze for instance) to a free plan does the banner ever get display?

Yes.

To sum up here is the logic I found for that banner:

Design Proposal

There was some previous work completed in prior Design Discovery looking at how we might include some more purchase affordances on the Group Billing page.

Current	Proposal

This version includes a re-worked table like layout for each Plan. Trying to figure out if there are any Pajamas components that are closely aligned (Currently a modified Modal component) and will continue to investigate. Please let me know your thoughts.

cc @tipyn @jackib

Probably is more closely aligned with Cards. Documentation on this is yet to be updated and maybe an opportunity for us to explore @tauriedavis

@timnoah Nice work! I like the proposal a lot! It's so much more informative and actionable

I checked out the previous issue and I see that things have been evolving. I want to make sure we rationalize our design choices so I'd love to see some notes about your design point of view along with the proposal - some examples of this would be to explain things like:

Why show three features instead of 4, 6, 10, etc?
Why a card pattern vs. a table vs. something else?
Might we end up with a few different flavors of this pattern? Like a small plan compare and a large plan compare?
Why is the design in the customer portal so different from the design on about.gitlab.com, and can/should we aim to create consistency? Or are we purposely deviating from marketing?
Or any other considerations/decisions you made along the way. (This will be super helpful when documenting for Pajamas too!)

Once you are ready to move forward with something we should ask the growth team for feedback and guidance here because I know they'll be interested in this.

A couple of picky things - completely ignore these if you aren't this far down the path yet:

Can we kill that line of text that starts with "Learn more..." since it is sort of redundant now?
The buttons "Start your trial" and "Upgrade" don't follow the same pattern grammatically, although I don't think "Upgrade your plan" is a good solution. I don't think it's a big deal, just something to think about.
Is "billed annually" better than "paid annually"? Technically no one is paying until they upgrade, so it's a tiny bit presumptuous.

added severity2 label

Added a weight of 2 based on the current proposal. However, frontend might be slight higher, perhaps a 3.

In which case, we should probably go with the higher of the 2 (backend vs frontend)

I almost wonder if a frontend engineer can take this on entirely, @jameslopez?

I see that we already have something similar in the profile billing page:

changed weight to 2

Why show three features instead of 4, 6, 10, etc?

In past designs (before my time with GitLab) there has been thinking around how we might represent pricing within GitLab.com's design system. You can currently see this on the User Settings > Billing page.

My approach was to iterate upon this, removing visual noise and stripping back some of the elements for a more minimal approach.

The purpose of the Upgrade cards would be to give short, informative and easily digestible information. Three features with a link to learn more seems like a reasonable bitesize amount of information for users.

Why a card pattern vs. a table vs. something else?

The card pattern seems cleaner and more in line with how we use components in our Design System.

Might we end up with a few different flavors of this pattern? Like a small plan compare and a large plan compare?

Potentially, I can't think of any use cases right now but that doesn't mean variants won't become useful in future.

Why is the design in the customer portal so different from the design on about.gitlab.com, and can/should we aim to create consistency? Or are we purposely deviating from marketing?

The Customer Portal and about.gitlab.com are actually quite similar and share quite a few properties, like colours, typography and spacing to a degree. But did you mean "Why is the design on GitLab.com so different from the Marketing site about.gitlab.com"? I've previously advocated some investigation into a more harmonised brand experience across marketing and product. An example would be Atlassian, who I think does this well. In my opinion, GitLab Marketing and Pajamas are visually pulling in two different directions. Any attempt at this stage to harmonise would probably create a Frankenstein design system. It would definitely be a beneficial discussion to have at a higher level.

any other considerations

I see Cards in a similar way to the Modal component (presentation not interaction). This will include three main slots, title, content and footer. Unlike the Modal implementation, the title and footer should be optional making it a little more versatile.

cc @jackib

Might we end up with a few different flavors of this pattern? Like a small plan compare and a large plan compare?

What I'm getting at is this type of situation where we have a pattern that repeats itself in part and if we implement both versions of this we will need to take steps to ensure consistency both when we design/build and when we iterate on these later.

@jackib Ah yes, Gotcha! I agree and think this is an interesting scenario, as the Customer Portal follows a completely different design system or styleguide as compared to GL.com. I know the vision is to eventually move to a place where we have all transactional workflows in GL.com (SaaS users not having to engage with the portal at all) for consistency and better user journeys.

Right now, we could try to sync the Cards look and feel but we still have a hurdle to overcome due to the differences in fonts, colours etc on the Customer Portal.

marked the checklist item @timnoah to review and add a design MVC - We could consider this as a first stepping stone to making the portal invisible to users. as completed

changed the description

Can we kill that line of text that starts with "Learn more..."

Yup agreed we have the links inside the cards anyway

The buttons "Start your trial" and "Upgrade" don't follow the same pattern grammatically

We use the word Upgrade quite consistently across other touchpoints, so a change here could have a knock-on effect, just something for us to be aware of.

Is "billed annually" better than "paid annually"?

I agree with you and have changed the copy to "billed". Maybe a European thing, but we often use the phrase charged annually.

I have just updated the Design Proposal in the issue description and this is ready for ~"UX ready". Please let me know if there are any objections

cc @jackib

@timnoah Let's see if the growth PMs have feedback on this before moving to UX ready.

@jeremy @jstava for awareness and feedback. What thoughts do you have on the compare plans card pattern vs the existing grid view? If we go with cards, what features should we be highlighting and how might we experiment with this?

I like the visual presentation of the card pattern better. I like that we've gotten rid of center text alignment, and the visual weighting of the text feels more balanced. The information feels easier for my eye to parse and know where to go next.

As far as areas I'd be interested in further exploration:

Have we considered including the "Everything included in (previous plan)" language? This keeps things consistent with our pricing page and I think helps reduce repetition ("Unlimited repositories" is duplicated across all plans, for instance).
Is there a way we might be able to include the Free plan? I admit this might be a challenge, but when combined with the above makes it a little easier to see the incremental value in each plan.
Have we considered reducing the weight of the price for each plan? I don't want to induce sticker shock before someone's actually studied the value we're delivering at each tier.

The problem I'm trying to solve is to make sure that the value of each plan is well-articulated. Showing the deltas between plans might help.

I'll add on to this feedback to say that all of this can be explored or considered in a future iteration. As designed, it's a improvement and I don't think we should let perfect be the enemy of good.

Awesome work! I love the design over our current solution. I think the cards are simple, intuitive and easy to grok. a few bits of feedback:

I would like to see us highlight a "recommended" plan for a user upgrading from free. Something as simple as a visual "recommended" indicator can push users who are on the fence to move up to the next plan. Even if we only capture 1 out of 100 of users who would have upgraded to the bronze plan, but have now chosen our "recommended" option (lets say silver for this example), we have just equaled the value of getting 4.75 users to upgrade to bronze.
What happens after a user clicks on this card? Do they still have to upgrade through the subscription manager? Does the experience change for the user at all?

added [deprecated] 🍎 label

@jackib Whilst I appreciate the deeper dive into this, this is a small MVC that's trying to solve the problem of "Make it easier for people to pay via the group billing page". I'd prefer to keep this moving, especially since the customer portal is going to need an entire redesign overhaul anyway later on - if we continue to use it as in the way we are today.

I think @timnoah's design proposal makes sense to me and if he's happy that this is ready then I'd like to make it available for engineers to work on as soon as we can since we're already a week into the release. We can iterate on this later with the Growth folks if needs be.

@tipyn I want to promote a habit of collaboration with growth partners so that we can build a backlog of solid opportunities to test. That doesn't mean we have to put brakes on good ideas like this one. The conversation resulted in some additional ideas and follow-up issues, which is my expectation of how the process should work.

In the future, you can always just ping the product designer if you think an issue is UX ready, and if they agree we'll update the label.

@jackib Makes sense. I would prefer if we created new follow up issues for further iterations/discussions so as not to get into the weeds and discussions too much on small MVC's. That's all.

I added the UX ready label because @timnoah had already approved the designs and since we're already behind on this release, I want to keep this moving. Usually, I don't touch that label.

added workflowready for development + 1 deleted label

Thanks @jeremy and @jstava for some great suggestions. I've mocked up a second version based on some thoughts you both had but I think it requires more discussion so maybe best lives in a follow-up issue.

I've gone through each plan and instead of repeating features across all I've looked to pull out where added value is included. This requires further research and discussions around the KSP's for each tier.

Have we considered including the "Everything included in (previous plan)"

Agree, this would help create more consistency with our other pricing styles.

Is there a way we might be able to include the Free plan?

It does add some context having the Free plan included but we do lose some of the nice, easily digestible clarity we had with just the three.

Have we considered reducing the weight of the price for each plan? I don't want to induce sticker shock before someone's actually studied the value we're delivering at each tier.

I think this would be a great research study as I'm not sure either way whether sticker shock is an issue for us. Maybe marketing has some research they could share.

I would like to see us highlight a "recommended" plan for a user upgrading from free.

Highly agree @jstava we can look to iterate on this. We could base the recommendation on some light machine learning, like current and predictive usage

What happens after a user clicks on this card?

Hopefully, the Self-Service Upgrades Flow issue helps take you through the process

Thanks a lot, Tim. Super grateful for the response, I'll create a follow-up issue for this and move this further exploration there. All worth following up on, but probably not needed for this iteration.

I opened https://gitlab.com/gitlab-org/gitlab-ce/issues/65217 for the follow-up.

changed the description

@dennis I think we may have an opportunity here to complete the ~"pajamas::create", pajamasbuild, ~"pajamas::style" for a single-source-of-truth Card component that is implemented in Vue and thoroughly documented on design.gitlab.com. Wdyt?

Really sorry that I'm coming to this two weeks late, @timnoah! That makes sense to me. Though I would say that this issue would then be dependent on creating this design system component. I'll see if I can set up the proper tickets for everything to be worked on.

Thanks @dennis that'll be big help

@timnoah there's an existing ticket regarding Card here gitlab-org/gitlab-services/design.gitlab.com#287 are you able to run with that?

I'll take steps to get a basic implementation of bootstrap-vue card into gitlab-ui

Depending on the differences between the basic implementation and the specs we can follow up on it.

@rhardarson sounds like a plan! Will move component discussions into gitlab-org/gitlab-services/design.gitlab.com#287

gitlab-ui implementation here gitlab-ui#400 (closed)

mentioned in issue #65217 (moved)

removed UX label

added gitlab.com label

mentioned in issue gitlab-design#526 (closed)

marked the checklist item @dennis for your visibility and input (although, this may mostly be frontend - if you could confirm that'd be great) as completed

@vitallium, since it doesn't look like this has been started, would you mind if I re-assign this to @rhardarson as one of his first tasks ?

@rhardarson what do you think? Think you could take this on?

As per https://gitlab.com/gitlab-org/gitlab-ce/issues/63599#note_196598596, we will want to create a design system component for this one. Feel free to ping me on Slack, or perhaps we can set up a pairing session to go through it.

@dennis yes, sure. No problem!

@dennis happy to take this on, looks like a solid improvement to the page.

I'll reach out on slack for design system walkthrough

assigned to @rhardarson and unassigned @vitallium

marked this issue as related to gitlab-org/gitlab-services/design.gitlab.com#287

mentioned in issue gitlab-ui#400 (closed)

@timnoah I think it makes sense to update the cards in profile/billings to fit the proposed design. Consistency in presentation. What do you think?

Agreed @rhardarson That page is currently being worked on -> https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/15075. It would be great to replicate this on the profile/billing page.

Currently, as an MVC we are removing the pricing table on the profile/billing page for users eligible to upgrade. The idea is that we then create a follow-up issue for the profile/billing page to copy over the pricing table designed on the group/billing page to the profile/billing page.

mentioned in issue gitlab-org/gitlab-services/design.gitlab.com#287

@timnoah @tipyn just a heads up that this task will likely miss the milestone.

I'm trying to grok the logic of how subscriptions are presented, so it's going slowly on my end.

What's our process for missed milestones? Is there a label I add or something similar?

@rhardarson @gitlab-bot will automatically set the corresponding labels if it misses the milestone. We only have to update the milestone in the case it misses %12.2

Is this technically in development? My apologies for not walking you through it sooner but basically we want to move issues from workflowready for development to ~"workflow::In dev" to ~"workflow::In review" until the issue is finally closed.

Is this technically in development? My apologies for not walking you through it sooner but basically we want to move issues from workflowready for development to ~"workflow::In dev" to ~"workflow::In review" until the issue is finally closed.

Ah I see the label <-> lanes on the fulfillment FE board now. I'll update it.

added workflowin dev label and removed workflowready for development label

mentioned in commit gitlab-design@af6f0381

changed the description

changed milestone to %12.3

@rhardarson Thanks so much for the update. I've moved to %12.3 :)

Make it really clear how users can buy GitLab from the group billing page

Problem

Original Proposal

Design Proposal

Design Specs

Result

Next steps (if any)

Designs

Child items ...

Activity

Design Proposal

Make it really clear how users can buy GitLab from the group billing page

Problem

Original Proposal

Design Proposal

Design Specs

Result

Next steps (if any)

Relates to

Activity

Design Proposal