Design Strategies for a Successful Pricing Table | Hacker News Reader

Design Strategies for a Successful Pricing Table

uxmovement.com

134 pointsUXMovement26 comments

So, far every article I've seen from uxmovement.com has anecdotal advice with no sources, and no numbers to back them up.

Also, when creating the tiered plans for your web-app, I highly recommend NOT having anything that is "unlimited" in any of your plans. It is very hard to go back and un-unlimit your plan. Don't leave it open-ended.

Sure, make the limits high on the top plan, hell make them higher than anyone could possibly need, but still have limits. If someone needs more than that, you can work something out. If nothing else, have a per-instance-pricing plan ($50/mo for 500 things + $0.05 per additional thing).

Most things that get called "unlimited" are usually dependent variables, though. For example, if a cloud hosting plan offers "unlimited" storage, but only 5GB of bandwidth between the compute nodes and persistence nodes per month, then really you can only store (5 * the number of months you've had the account) GB, because, past that, there's no way to get more bits persisted.

The decoy pricing plan was straight from Dan Ariely's Predictably Irrational, though he could've cited this.

You can catch the gist of it from his TED talk: http://www.ted.com/talks/dan_ariely_asks_are_we_in_control_o... Starts around 10:00 in.

It's mentioned in Predictably Irrational, but price anchoring is an old concept, and the author of the post does not have an obligation to cite the book.

I can't help but mention... un-unlimit would be better written simply as limit.

"It is very hard to go back and limit your plan."

That is definitely smart advice though, it's always easier to increase limits than to decrease them.

My issue is, how valuable is a web service? How do I determine a reasonable price to charge? Pricing is something I feel is hard to test.

This is, I think, the number 1 application for A/B testing that makes it worthwhile, despite so many people loudly screaming that it's worthless.

The simplest suggestion I can make is to test the living daylights out of pricing. Set your base at something reasonable -- definitely more than your rock bottom price, and should be well above break-even. If you can scale your fixed costs and estimate the average cost per user (bandwidth, disk space, etc.) then you can apply a margin. Make sure you're covering overhead (which is insanely complicated if it's Freemium), and then play around.

Offer the 'base' price as a special deal, while testing out prices all over the place. Double that price, and set it as the 'non-discounted' deal to some users. Someone else recommended recently (I can't remember who, sorry) that if you want to be equitable, you can double the price on the sign-in page, then if they bite on that, only CHARGE them what you're charging as the base price -- but if you track the results on that signup page, you'll know how many people were willing to pay double.

Lastly, as a piece of obvious advice, if you can at all help it, don't raise the prices on existing users. Grandfather them in unless you absolutely can't, and if you can't, figure out some way to take really good care of them.

Why, why, why would you use cost-plus pricing for software as a service? The price of average cost per user is cratering for virtually any input you can measure except cost of customer acquisition.

You should set your prices based on the value that you are delivering to your customers and not based on how much it costs you to deliver.

To find out the perceived value, you need to get out and talk to customers.

You're right of course -- I didn't mean to imply that you should use cost-plus pricing as a baseline, rather, that you should definitely not do anything BELOW cost+, regardless of how much (or little) value you might be delivering to your customers.

That said, there are numerous examples in which even this rule can be thrown away (Facebook, Twitter, et al.)

Is this actually from experience? Or is this simply cherry-picking from famous web apps?

If the author hasn't built a successful pricing page themselves, then this is just white noise. Best practices for this kind of thing seem to go in and out of style every 6 months.

Disclaimer: I have made 2 SaaS apps and the pricing page is the kind if thing where if you haven't done it before, your opinion about what color green works best etc has zero value.

I agree. It definitely seems as though the author is working from their own design intuition rather than data.

On a side note, what effect do you think design has on the decision between pricing plans compared to the decision to buy the product at all?

When I'm buying software I think, "Ok, I'm going to need x user accounts, xx of this feature, what's the cheapest plan that has that".

I dont think many people that need 2 users would go straight to a 10 user plan if there is a 3 user plan.

I loved the post, but would be interesting to see some actual data behind these observations.

Some of these seemingly contradict each other: one "rule" claims that ascending order of prices is better, another claims the opposite.

Sorry, where did they do this? Some of the examples they gave, certainly, didn't conform to all of their tips - only the one that they were demonstrating at the time, but I didn't see any contradiction in the text?

Anyone have thoughts or experience on using prices divisible by 5 versus 4s/9s? (Plans of $5, $10, $25 a month vs. $4, $9, $24, etc. )

I've found that odd numbered pricing - particularly 79, 95, & 99 - outperform even numbers almost accross the board.

Definitely test both - but that's accross quite a bit of data, and different products -

Some A/B testing of 'odd pricing' (e.g. 39.95 vs 39.99) for software can be seen here http://www.alwinhoogerdijk.com/2009/05/28/odd-pricing-95-vs-...

Two issues:

1. There is no quantifiable data to backup the assertions. Does anyone have A/B test data to back any of the author's assumptions?

2. There is no discussion on how to structure pricing that scales on a specific metric e.g. users, storage space, number of uses etc.

The common approach is to lump all the plans into 3-4 buckets with the last bucket being an "unlimited" plan. Suffice to say, this approach may not be ideal in cases where users have widely differing requirements.

For example, imagine pricing a product based on impressions/page views. Buckets simply don't make sense.

I'm currently experimenting with a pricing table that allows buyers to CUSTOMIZE their plan from a traditional 3-4 plan table.

See http://www.trafficspaces.com/plans/ for how I've done it. What do you think?

We've done A/B testing at Rypple on our Pricing page, and found most of the principles suggested by UXMovement to be true.

http://rypple.com/pricing

You've done some interesting things with your pricing page. Couple comments: - I'd reduce the complexity of the page by removing the drop down boxes for impressions and just changing the pricing buckets to up to the maximum impressions offered by that bucket. The way you've got it now means there's effectively 13 plans. - I've found that listing the features in order from those included in all plans to those included in the fewest plans to work the best.

Thanks for the advice.

We'll reorganize the feature set as you've described. It seems to make a lot of sense.

Regarding the drop down, whilst it isn't the most ideal implementation, I can't think of a way to allow publishers to pick a plan that meets their specific needs without using the drop downs.

We've tried to reduce the visual complexity by using 4 buckets, hence the drop downs in each category. Getting rid of them, I fear, may create more confusion about the flexibility (or lack of) of the plans. Especially because our customer's requirements are quite varied. We've literally got people on 250,000 impressions and others on the largest plans.

Pretty cool. And they're not too sketchy!

The only one I was put off by was #6, hiding your free plan. Although it certainly makes sense, I know I get easily pissed off by this sort of thing. If you follow the other rules, and put it off to the right, I think it'd be fine.

Also, if you have them sorted in descending order AND have a decoy, I feel like that could be offputting: the first price you see would be huge.

Thus priming you to expect large prices and pleasantly surprising you with the cheaper prices.

There was a good article I read a while back on how restaurants could improve their menus to increase revenues. I think a lot of similar things apply, and that article seemed to have the evidence to back up the ideas.

Unfortunately I cannot find the link, but one of the things I did remember was that customers spent more when prices were not preceded by the currency sign.

On the topic of UX but unrelated to pricing tables: I really like the tops of the social networking logos just above the comment form that pop out on hover. I'm not sure why I like them so much. But there's something about having an onslaught of social media logos encouraging you to share which bothers me and this bothers me less.

This seems very useful had not given much thought to pricing grids (easy oversight I guess). Though I don't know about hiding the free packages, if your not going to promote it why have it and surely a free customer is better than none. I Think this calls for some A/B testing.

this seemed very scammy and "customer hating / clueless corporate like". the opposite of the clue train. and when i see this kind of shit for real it pisses me off. sure if you want idiot customers who are tricked by simple psycology and you dont mind insulting eveyones intelligence, but really you should / could be better.

Care to mention which point you have a gripe with?

Short of not being backed by hard data, I don't think they were all bad. Definitely not "customer hating" or "clueless"

Reply on news.ycombinator.com