Designing a fair and simple usage-based pricing

At Help Scout, we were expanding our product offering to include Proactive Messages - a highly requested feature that can add tremendous value to a business. We created a new pricing model to go with it which would lower the adoption barrier. I was leading design, ensuring this new model matched our company values.

Role

I was leading design, collaborating closely with the Director of Product Design, and the Growth cross-functional team (a Product manager, Engineers, and QA).

Minimize friction, enable scalability

Creating a new offering was an opportunity to create a new revenue stream. Our Finance and Product teams researched pricing models and a usage-based pricing model seemed like the one that would allow us to:

→ Minimize friction of feature adoption - we could allow customers to use Proactive Messages for free or at a low cost;
→ Enable scalability by connecting the paid price with the value they receive;
→ Potentiate expansion within our customer base by capturing additional personas and use cases.

A fair and transparent pricing experience

There are multiple ways to approach the creation of a new pricing model: we had discussions around ensuring our MRR was predictable or consistent but this didn't feel right. The most important thing for us was to create a model that felt "Help Scout-ish". To keep us focused, we defined guiding principles that would help shape the experience.

Going through discovery and explorations

To get us started we researched other products with usage-based pricing models, whether these were in the same space as us or not. One of the expected personas for this new offering was the "marketeer" so we asked some folks from our marketing department to test our prototypes and to learn what they are used to when it comes to the user experience of usage-based pricing models.

When dealing with pricing, customers are particularly careful and will naturally have questions, so throughout the process, one of the main challenges was to find the right balance in the amount of content we displayed in the UI.

Overall, we did two rounds of internal testing on our prototypes. We learned that:

1. People were concerned about when they'd learn about the additional costs of using Proactive Messages; 
2. It wasn't super clear whether their billing would increase automatically or not.
3. They felt that they had all the information they needed to make a decision. Although, some mentioned their first step would be to preview all pricing tiers.
‍‍
We also held a design critique where we wanted to get in the weeds of what the user interface looked and felt like.
‍During the design critique we reali the user interface could be simplified - while it contained all the information needed, there was a lot of repeated content and the number of clicks to accomplish tasks could be reduced. We were on a tight schedule so I suggested we time-boxed a week to see if we landed on something that felt right and simple - and so we did.

We were focused on addressing the most consistent feedback and pressing concerns:
‍1. We made sure to plan an email campaign to announce the new feature and the new pricing model. We also added
2. We clarified on the UI if the customers billing would increase automatically or if they had a spending limit set;
3. We made the UI less verbose while still ensuring the information was accessible, offloading some content to our help docs and emails.

During the whole process, we kept the communication lines open with everyone by sharing Loom videos of our progress and logging design iterations on a Dropbox Paper doc - this was a great way of keeping track of our decisions and getting feedback from all people involved.

The final version

Overall we wanted to create a functional user interface: customers should have the ability to quickly see how much they are paying and, to help them decide whether to set a spending limit or not, their current usage and when these values reset.

Making it accessible

Accessibility was a top priority for us as a company, so this UI was no exception - we needed to ensure that all components and interactions were accessible. The slider interaction was particularly tricky so I collaborated closely with our frontend engineer to ensure that it followed the standards. Together, we also polished a lot of the interaction details.

Other impact areas

I also had the opportunity to impact our marketing website, finding a way to include the new pricing information on our pricing page, reusing the new design elements but adjusting to our website language.

Additionally, many of the design elements created for this solution were added to our design system, contributing to improving our design language across the platform.