HackerEarth Recruit Pricing
HackerEarth Recruit SaaS application allows technical recruiters to conduct online programming tests and remote interviews to hire tech talent in an effective manner. I recently redesigned our pricing structure to make it more obvious, streamlined and transparent.
The Task

In early November 2015, we set out to revisit our pricing strategy with a goal to make it more obvious, streamlined and transparent for our customers.

We had something called test and interview credits which were nothing but HackerEarth Recruit currency. With credits, you could invite candidates to take recruitment tests or interviews. But it was not clear to our customers that you could invite only one person with one credit, since the the terms credit and invite are so disconnected.

Also, customers had to purchase credits again and again as they got over and this was a huge pain point as they had to do a number of transactions manually and had to keep track of the number of credits remaining in their account.

My Work

I designed the information architecture, UX flows and visuals for different components of the new pricing structure. Starting with the pricing page, I designed the billing and usage section, subscription plan change wizard, payment settings, flows for different edge cases, payment invoices and emails.

Since I was designing a B2B product, it was critical that I understood our customers and our business motivations. I took time to discuss with our founding members, the motivation behind rethinking the pricing structure and how we thought it will affect the way our customers use our product. And since I had never designed a pricing structure before, there was a tremendous amount of I could learn.

Invites, Not Credits

Our first step towards making the new pricing structure obvious was to choose to use the term “invite” instead of “credit”. The term “invite” makes it clear that you can invite only one person for a test or an interview. So, invites became the new HackerEarth Recruit Currency.

Brainstorming Possible Workflows

We started brainstorming different pricing plans. The primary goal is to help customers choose a plan that fits their requirements and then let them use HackerEarth Recruit without having to worry about purchasing invites ever again.

We zeroed in on four plans, namely
1. Free - Use HackerEarth Recruit for free for as long as you want
2. Startup - For small requirements
3. Enterprise - For enterprise accounts
4. Custom - A tailormade plan that fits your needs

I started by outlining where the user signs up for a plan and what all cases might occur, for example, if the user hasn't added a payment method or if the free trial period is over. I listed all the scenarios and edge cases and proceeded to design flows to handle them.

Sketches And Flow
Pricing Page

I designed a pricing page that sets clear expectations of what our customers can expect from different plans.

Billing & Usage

Billing & Usage section provides a complete overview of the payment methods, usage, due amount and invoices. Here, users can -
1. View and edit the primary payment method
2. View their invite usage
3. View amount due at the end of the month
4. View and download invoices
5. Deactivate account

The New Sign Up Page

I also redesigned the HackerEarth Recruit sign up page to show the details of the chosen pricing plan and the set of features the customers get with it.

Emails

Moving on, I designed the welcome email and other emails to be sent to users at different time. We tried to keep the message as simple and clear as possible.

What I Learned
People don't like surprises, especially when they're paying

We made it a point that people should know exactly what they are paying for. That means no surprise transactions, no forcing people into upgrading their plan and no hidden costs. Also, we made it really easy for customers to track their usage by showing them their remaining and used invites, monthly due amount, and promptly downloadable invoices for every transaction done previously.

Design of a pricing structure is much more than what it looks

The visible components of a pricing structure can be compared to the tip of an iceberg. These visible components essentially boil down to the pricing page and the billing section. But there were so many invisible design components that we took care of. That means we simulated a customer's usage journey through each plan and handled all the edge cases that occured. Not to mention, all the notification emails and alerts that we designed.