Moving team memberships to flat tiers

Research before the rollout

What buyers were paying for

I led the interview process with our chief of staff and head of sales to test willingness to pay and understand problems with the existing offer. The team’s market review also examined how learning products and software companies packaged individual access, team plans and sales-assisted purchases.

Our interviews with team-subscription buyers pointed to a sequence: first establish the material’s relevance, then whether the learning format fits, then assess the price. A lower price alone would not answer whether someone had time to use the membership.

The findings also exposed a tradeoff. Flexible access suited people learning at their own pace, while live cohorts supplied structure and accountability. Separating the two could make the offer fit more budgets, but might remove the commitment that helped some members get started.

This was qualitative research with varied team segments. The synthesis called for further validation and did not test individual members’ willingness to pay.

Scope and sequencing

Renewing members came first

We prioritized existing members approaching renewal. Launching for new buyers at the same time would have added signup, onboarding and marketing work beyond the initial release window. I coordinated the design work across these phases with the PM.

The team combined flat tiers and separate cohort purchases into that renewal release. Two successive pricing changes would be harder to explain, while retaining several cohort bundles within every tier would multiply the choices. Existing members could choose their upcoming plan before it took effect at renewal.

1. Renewal migration

   Plan selection, renewal notices, billing changes and cohort-pass purchasing for existing members.

2. New purchases

   Signup, onboarding and a purchase flow for people joining under the new model.

One tier boundary remained deliberately firm: needing a single seat beyond the allowance meant buying the next full tier. The comparison needed to make the current allowance, upgrade and sales route explicit. Prorating an upgrade was a separate requirement, with the calculation to be resolved with Finance.

Experience audit

Map the account’s starting state

I worked at the journey level to keep the migration connected. A renewing team owner, a canceled individual member and someone with a failed payment could not all start from the same screen. The story audit connected those user needs to the paths through the new model.

I paired journey mapping with a screen-by-screen audit of the existing subscription experience. The library covered renewal, cancellation, reactivation, payment recovery and seat changes. It made the existing rules and entry points visible before we changed them.

Payment recovery was more than updating a card

The audit showed two different recovery paths. An overdue manual invoice had to be paid through Stripe’s invoice portal or resolved with support. In the failed-card flow, updating the card immediately charged the subscription and restored the account to active.

Those distinctions mattered during migration. The tracker called out a legacy team owner who needed to select a new plan before fixing the payment and confirming it. Treating that journey as a generic “update payment” task would miss the plan decision.

Design direction and QA

Track the work between teams

Designers tackled different areas of the UX and UI. I coordinated the high-level flows, reviewed designs against the journeys and worked with the PM to surface unresolved questions. Auditing and QA focused on the transitions between screens, including where one team’s work handed off to another.

The tracker distinguished work ready for engineering from work in progress, questions needing UX clarification and items outside the current milestone. Its handoff markings made cross-team dependencies visible. In the upgrade path below, payment, confirmation and success were grouped together before the billing page could enable seat assignment.

Reviews also checked whether the new offer stayed understandable across phases. In the later purchase-flow review, the team questioned how to show the individual plan’s total price and its included cohort pass. That was the same packaging problem appearing again in interface copy.

Interaction design

A readable checkout total

Checkout had to explain a yearly membership alongside transactional cohort passes. Pass quantities changed the unit price. A purchase could also include a discounted pass, a coupon, a prorated adjustment and sales tax. The interface needed to keep the buyer’s selections and the amount due understandable together.

Explain each part of the total

Plan and capacity

The annual membership price and the number of seats it covers.

Passes and discounts

Quantity pricing, a discounted pass and an order-level coupon are separate parts of the calculation.

Proration and tax

A dated adjustment for the plan change, tax details and the resulting total.

Terms after purchase

Membership renewal, pass expiry and the active-membership requirement for using passes.

The desktop specification placed the order recap beside the inputs so the cost remained adjacent to the selection. At phone widths, checkout became a full page, with selection, payment and recap in reading order. The wider project also had to bring tax collection into the rollout as cohort purchases became separate transactions.