Higher user pricing tier
At Atlassian, I am part of the Marketplace Design team. My primary responsibility includes designing experiences for the pricing and packaging of apps. but on a whole, I also manage the Partner side experiences along with another Designer. This was the first project I worked on and, I managed to make this go live even before completing 90 days in Atlassian.
This was my first experience designing enterprise solutions. This was an interesting challenge for me. Atlassian’s way of documenting everything in Confluence helped me swim through an ocean of topics and domain knowledge to quickly catch up the slack.
Context:
The primary users who use the marketplace are Partners (supply-side) and the End customer (Demand side). The Partners list their apps in the marketplace to sell. Whereas customers use the marketplace to buy apps that help them customize Atlassian products ( Jira or confluence ) specific to their business use-cases. Customers can run these base products in different hosting types (Cloud, server, and DC). and similarly the Partner can make the app available for all the hosting types.
Problem:
To design for Atlassian Marketplace it is very crucial to have regular cadence with the Partner as well as the customers in Marketplace. On interviewing few marketplace customers during our regular cadence, we discovered large customers ( 1000+ users ) who are willing to migrate from Server/DC to cloud hosting type found the cloud app pricing steep compared to their existing hosting platform. This eventually became a blocker for cloud adoption. Even though at this stage I was not part of the research I managed to get full use of this cadence for my other projects.
I also understood Partners were tackling this shortcoming in a non-scalable one-off discount negotiation approach.
eg. At that time a cloud app can cost on average 11.1x the price of its Server equivalent for the 5000 user tier.
When we dug deeper, we discovered this to be partly because of the inability of a partner to set a granular price for the 250 + user tier. So the customer org who had 251 users were paying the same as another org having 5000 users. This lack of granularity also made cloud apps on an average 11.1x expensive than their server apps respectively.
Providing our marketplace partners flexibility in setting prices for their apps above 250 users on a cloud platform became the primary goal. This will also help our large marketplace partners with 1000+ users who are willing to move to the cloud to get better price apps for our marketplace partners.
Challenges
For bringing the cloud app prices less in comparison to Server prices It is important to educate the partners and provide them the right tools to make informed pricing decisions. How to nudge partners to lower prices for higher user tiers became my Design challenge.
The measure of success:
One interesting thing that I picked early on working with other Atlassian members is the Measure of success criteria. This set for every almost every project even design to help access the impact of the Design. So we designed the following metrics to gauge the success measure for this project.
Adoption of cloud apps (after migration), How many partners are setting different prices for the newly added tiers, Change in the cloud to server price multiple ratios.
Approach
for the problem at hand, after multiple internal ideations, Me and my triad decided to go with the following approach.
Current Per-user pricing tiers for cloud apps in Marketplace:
1-10, 11-100, 101-250, 251+
New tier additions
1-10, 11-100, 101-250, 251-1000, 1001-5000, 5000+
This can enable partners the needed flexibility to set prices for higher user tiers. To nudge, we can have some benchmark values of prices for each tier against reference values. This can help bring awareness to set the right price for each app against different tiers. My Product manager had a fair bit of understanding of the different instruments that can be used to set the price of an app. He was exploring the benchmark values to provide and at this time my key role was to explore how subtle design cues can inform partners to set the price right. I had to make sure these nudges are not too overwhelming and are simple enough without hindering the actual pricing experience.
Different design tasks at hand
At this point, I had zero knowledge about app pricing. I managed to schedule different meetings with the domain experts and Technical product managers ( People who interface with the partners on day to day basis) I got some basic level of understanding. With this, I started wondering, different design interventions that are required for the given flow of setting the price.
With the new tier introduction, how to communicate the new pricing tiers and prompt the users to set the prices for the additional tiers.?
What kind of subtle cues are required to help users set the price?
If there is more than one reference value how do we explain and communicate information about each benchmark value?
How do we make sure partners don’t miss the opportunity to set new prices for their apps?
Solutioning
First to communicate the new tier introduction. I identified different touchpoints and explored different design options. The tone and communication went through multiple levels of content design. Since I didn’t have a dedicated content designer. I sparred and took my designs to multiple Crit groups to get different perspectives and feedback.
During this stage, my product manager after a successful DACI zeroed in on two benchmark values: Normalize pricing values and Cloud server multiple values.
Normalized price is an average price benchmark of any cloud app against the average price of all DC apps for each pricing tier.
Cloud server price multiple is to communicate the gap in price between cloud apps and server apps for each tier pricing.
How might we communicate information about the bench-marking values?
For this problem, I explored different content modulations and modal representations. For each exploration, a Figma prototype was created and used as a way to validate with the right stakeholders. You can find some of the explorations below.
How might we nudge the partners to lower the price for higher user app tiers?
I explored various design options involving subtle cues like color, arrow while the user is inputting the price value. While validating with different teams and domain experts it became clear that it is important not to complicate the pricing input (since it will affect actual business). I started my second round of exploration with reference benchmark values in the different columns provided against different input fields. Once the designs evolved. The new solution has normalized pricing values next to each input field. If the set price is closer to the price insight value. The user is setting the price right.
I created a complete design walk-through which you can find below. This was used for Dev. Handover also. This was a new experience for me in this organization I was looking for references and ultimately ended creating my own method.
. Click the button below to view the prototype. For the best viewing experience use a desktop browser.
impact
To conclude. The project achieved its intended goal.
For end customers, We got an overwhelming response. within 2 months of the launch from September 2020, We observed significant pricing changes for most of the apps. As expected cloud prices in comparison to server prices on an average dropped up to 49% for the 10000 user tier. a similar reduction of up to 37% for the 5000+user tier and 23% for the 1000+ user tier was observed. This will unblock and greatly satisfy the customer who is willing to migrate to cloud apps.