

Design Strategies for a Successful Pricing Table - UXMovement
http://uxmovement.com/design-articles/7-useful-design-strategies-for-a-successful-pricing-table

======
JangoSteve
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).

~~~
blaines
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.

~~~
bmelton
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.

~~~
DJN
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.

~~~
bmelton
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.)

------
fookyong
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.

~~~
lukevdp
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.

------
d_r
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.

~~~
estel
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?

------
callmeed
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. )

~~~
aresant
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 -

------
DJN
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?

~~~
jsatok
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.

~~~
DJN
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.

------
zbanks
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_.

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

------
cammil
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.

------
olliesaunders
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.

------
binx
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.

------
njharman
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.

~~~
DJN
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"

:)

