Self-Service Pricing Feature Launch
Creating a self-service plan management feature from conceptualization to implementation, giving users control of their account subscription
End-to-End
Growth / Pricing & Payment
PROJECT TYPE
4 Engineers
1 Product Manager
1 Product Designer
THE TEAM
User Research
Wireframing
Prototyping
MY ROLE
Figma
Confluence
TOOLS
DURATION
3 Months
Overview
How might we allow users a way to seamlessly upgrade their subscription plan at any time, enabling them to prioritize completing daily tasks without disruption?
Providing users with flexible pricing and packaging plans in the B2B SaaS industry is vital to meet users’ diverse needs. Esper's pricing plans were only available on their website. The product itself lacked a self-service feature for users to upgrade their plans, forcing them to contact customer support if they needed a change in their plan subscription.
In November 2021, I designed a n in-app self-service pricing feature for selecting and upgrading packages. While the initial project had a larger scope, the final product was descoped to a MVP with one upgrade flow. My team and I completed the feature in January 2022. The feature launch was developed and released behind a feature flag, due to ongoing discussions surrounding plan differentiations. Nevertheless, the development of this feature allowed me to create an end-to-end design that established the groundwork for Esper's future pricing and packaging strategy.
The Opportunity
Providing a single avenue for adjusting subscription plans, which requires users to interrupt their daily tasks and contact customer support, can disrupt workflows and lead to user frustration and dissatisfaction. On the other hand, integrating an autonomous, in-app self-service pricing solution enhances the user experience, streamlines the adoption process, and improves overall satisfaction, benefiting both the business and its users.
The Solution
I designed a new self-service pricing feature that enables users to compare different pricing plans and purchase in-app. Administrative users can decide which plans are best for them autonomously, keep track of their billing history, and quickly get back to their daily tasks on Esper after their purchase.
Analyzing Requirements
Before diving into research, I wanted to understand project requirements, which proved to be an interesting challenge.
At the start of this project, requirements were ambiguous. The product team had not yet aligned on the details of each pricing plan offered, so I approached this project with flexibility and remained adaptable.
My main objective was to develop a three-tiered pricing model within the Esper product, allowing users to independently upgrade their plans and complete the checkout process. According to my PM, the pricing model would be based on user’s fleet size and desired features.
Research
Jakob Nielsen said it best: “Users spend most of their time on other websites.” It’s important to have consistency and use standards.
My goal was to design a flow that users were familiar with when it came to purchasing and checking out, so I researched several enterprise-level SaaS products, specifically analyzing the design of their subscription plans and upgrade flows. Below are examples of SaaS product upgrade and checkout flows from my research.
Ideation & Early Designs
I thought through various areas of entry for users to begin their upgrade flow, then explored different approaches to my designs.
I focused on identifying common scenarios that would prompt users to upgrade, because the goal of this flow was to be as seamless and least disruptive as possible. While the creation of a billing page was one obvious place to present pricing options, extending this capability to other console sections was vital.
Here is an example of entry points I identified and an initial user flow.
Exploring Pricing Tier Designs
Despite the upgrade flow having various entry points within the product, the objective remained consistent: to employ a unified pricing tier design across all flows. To achieve this, I explored different approaches for presenting the pricing tiers to users. My aim was to devise a solution that differentiated each pricing tier, provided users with comprehensive information to facilitate decision-making, and utilized an interface that allowed for straightforward comparison between tiers.
Upgrade Design in Billing Page
The main self-service pricing entry point was set up in the billing page, which followed the UI framework of the User & Team Management section. This design consisted of a sidebar navigation and main contents to the right of the sidebar. Because the given layout constrained the available white space to 3/4ths the space of a regular modal screen design, I thought through ways that I could showcase the tiers in a similar manner but maintain some visual design consistency.
Changing Requirements
Throughout this project, requirements continued changing. Finally, project requirements were descoped to a MVP with one upgrade flow in the billing page.
Adapting to changing requirements is a common challenge in design projects. In the case of the self-service pricing feature, it necessitated extensive discussions and consensus-building among multiple teams to establish a clear differentiation for each plan, but unfortunately, no decisions were reached by the end of our timeline
Consequently, the project scope became focused on developing a minimum viable product (MVP) for the pricing tier design and building the checkout page specifically within the billing section.
We wrapped up the project without knowing any distinctions between pricing tiers.
Final Designs
I validated my design against user heuristics to ensure that the final product would yield a seamless user experience.
With the revised requirements, I made adjustments to the design. I removed the slider feature and instead presented the various pricing tiers as the initial step of the upgrade process. Since the upgrade price still relied on device count, I incorporated an estimated device count input form as the subsequent step before guiding the user to the checkout stage.
Furthermore, in this design, I included a thumbnail minimum viable product (MVP) for another plan called "Esper Foundation for Android," which was planned for future development. This addition aimed to provide the foundation for the next iteration of self-service pricing designs.
Results & Impact
The feature did not go live, but the creation of the self-service pricing feature established the foundation for future development.
After three months of development, our team successfully wrapped the minimum viable product (MVP) of the self-service upgrade flow in January 2022. However, because the differentiation between each plan had not yet been finalized, the feature remained hidden behind a feature flag. Despite this, the significance of the design lies in establishing the foundation for Esper to incorporate additional details about plan differentiation in the future.
Unfortunately, I was unable to conduct testing and measure the impact of the self-service pricing feature at this stage. For future iterations, I would prioritize measuring key metrics like user engagement, task completion rate, and qualitative data. By analyzing these metrics, we can further enhance the self-service pricing feature and optimize the user experience based on user behavior and preferences.
Reflections
Some lessons that I’d take for my next project…
Stay goal-oriented.
During the entire project, the absence of details and ever-changing requirements posed a tough challenge. To make progress, I shifted focus to the overarching goals and the specific opportunity I was addressing. By reframing my mindset, I overcame uncertainty and channeled my energy into finding effective solutions.
Overcommunicate to ensure clarity.
In any team project, information can sometimes be limited to select members, leaving others unaware of updates. This occurred when I had one-on-one meetings with my PM to discuss project updates without engineers being involved in the meetings. To address this, I prioritized overcommunicating project changes. I noticed that engineers were not involved in certain discussions, and as a result, proactively involved them in all PM and design discussions. Inviting them to relevant meetings and emphasizing their early involvement ensured that everyone was informed and mitigated issues caused by missed communications.