SKIO Music: Pricing Page Redesign
Role: Lead Product Designer| Status: Shipped
Background
SKIO Music’s mission is to give artists increased commercial opportunities and reduce the legal and administrative bottleneck around licensing and copyright. Currently, it is a music contest platform that hosts premiere song contests for world-famous artists and allows amateur artists the opportunity to win world-class prizes and be discovered.
We (the Product team) were in the process of modernising and updating the UI for all our core pages to their new look and feel, and our Pricing page was no exception. Visually, it didn’t flow cohesively, the amount of copy in the plans felt overwhelming, and the background imagery used was outdated.
We also wanted to take the opportunity to make the Pricing page more comprehensive and understandable for our users. Specifically, we wanted to show users more of what SKIO had to offer, allow users to compare the differences in our plans more easily, and reduce the volume of CS inquiries.
Approach: Researching, Ideating, Deciding, Building
I began like I always do, with research and exploration. Then, I ideated in high-fidelity (I typically go low/medium-fidelity first) to share with our VP of Product so we could decide what iterations to move forward with. Once we had alignment and feasibility was determined with our development team, I handed off the final mockups to them and assessed the quality of builds on Staging by providing regular feedback before deployment to Production.
Researching
For this project, I wanted to understand how other products and services handled their Pricing page to note best practices to make it intuitive to our users (see Jakob’s Law). A few of the regular practices I noticed during my research were:
- Feature Matrix
One format shows the feature/category on the left furthermost column and uses checkmarks within columns to indicate whether the plan includes it, whereas the other format is more verbose and offers the feature/category under each plan with the value difference (present on the legacy page) - FAQ
Most had an FAQ section (absent from the legacy page) - Annual vs Monthly Billing
One format uses a sentence to show the difference in price, whereas the other utilises a toggle to switch between prices (present on the legacy page) - Social Proof
Typically a mosaic or carousel of business logos (present on the legacy page)
Ideation
When it comes to ideating, I often hand-sketch wireframes before going digital. However, based on my research, I had a clear understanding of what content sections the page should contain (at a minimum, a hero header, a feature matrix, social proof, and a FAQ) and the variations I wanted to try out, so I went straight to high-fidelity.
My main focus was on ensuring we clearly communicated what SKIO had to offer and the differences between plans. I was drawn to this version of the feature matrix (compared to the “feature beneath each plan” version) as it feels easier to compare the differences at a glance due to the reduced amount of copy (reduced cognitive load).
It was also vital that we pre-emptively address any questions or concerns that users may have regarding pricing. Therefore, FAQs were chosen based on the most commonly received inquiries by CS and recurring questions found across other Pricing pages.
Another essential point was to show users the difference in annual/monthly billing clearly. In one version, the pricing difference was indicated in one sentence underneath each plan, whereas the other version utilised a dropdown to toggle between the pricing differences.
Decide
In an ideal circumstance, we would have shown a high-fidelity prototype to our users (especially those who reached out to CS) to discover and address any design or usability issues. However, as we needed to release this feature sooner rather than later, I shared the prototypes with the VP of Product instead to discuss.
For the feature matrix, we decided to move forward with the plan name directly connected to the matrix instead of split apart as easier to understand (more readable) due to the proximity of the plan name with the feature matrix.
The feature sub-copy was moved into info tooltips to reduce cognitive load instead of being shown on the page. We believed this would result in a net benefit for the user, i.e. the page would feel less overwhelming visually, which would outweigh the cost of having to click each info tooltip to learn more about each feature.
We also decided to add additional content rows. Firstly, we added categories to group similar features together to help users understand what SKIO had to offer at a high-level (Community, Song, Marketing Services, Content). We also added additional features within these categories to be more comprehensive about what SKIO had to offer.
For annual/monthly billing, we decided that toggle-less pricing would make it easier for users to compare annual/monthly prices as they could do so without interacting with the page.
For the FAQ, our VP of Product and I aligned on all questions except for one. There was initial pushback from him regarding the question, “I want to downgrade or cancel my membership — how do I do that?”
He argued that we shouldn’t be so forthcoming about these steps because this could potentially lead to a loss in paying subscribers. However, I brought up a few points:
- People who want to cancel/downgrade their membership are going to do so anyway, so let’s make this experience as transparent and easy as possible
- A lot of products and services have free trial periods with easy cancellation. From my own experience, I’ve been persuaded to try some of them out because of how transparent they were about how easy it was to cancel or downgrade. Thus, there may be an opportunity to convert people on the fence about subscribing due to the anxiety and perception of how difficult it may be to cancel or downgrade (e.g. Planet Fitness horror stories — please don’t sue me).
Presented with these points, we agreed that this question would remain as it would lead to a more positive experience for current or potential subscribers and could lead to additional revenue.
Build
Upon deciding which designs to move forward with, we engaged our development team to discuss and ensure that the designs were feasible. As most of the page was composed of components used elsewhere on our platform (hero header, pricing card, social proof mosaic and testimonial, FAQ), the only novel component was the feature matrix that wasn’t going to be an issue to build.
With no red flags, final mockups were handed to our development team. Then, each time a build was ready for review, the development team would push it to Staging. I would then assess it to ensure that it adhered to the visual design as much as possible and respected any intended interactions. Any notes/changes would be detailed in a Google Doc to share with the development team, and after a few cycles of this, we finally pushed the build to Production.
Impact
After launching the redesigned Pricing page, we validated that our redesign was a success as we saw a 25% reduction in pricing-related inquiries to CS. Additionally, our Pricing page was updated with our UI and exhibited some best practices seen on other modern Pricing pages.
We did not notice any significant increase in signups or cancellations/downgrades.
