UI Practicum #5. How to Deal with Complex Pricing Models

Published May 30, 2016 by Jane Portman
Categories:

• Articles
• Design
• UI Practicum

Earlier in UI Practicum we dramatically optimized a scheduling screen by identifying the most common use cases and separating them from each other (read the full story here).

Today we’ll help Dave Rodenbaugh to optimize some settings for their AWPCP project (which stands for Another WordPress Classifieds Plugin). Dave was inspired by our previous example and concluded that we can apply the same principle for his case.

This WP plugin allows the user to create a paid business directory with many categories. The final customer will be able to post to certain categories — depending on their fee plan.

Here’s how Dave identified the common use cases:

• users who want to charge different fees for different categories separately;
• users who want to limit the number of categories for a fee plan in general (any 4 categories for one price, for example);
• simple fee plans just wanting to charge for a set of features and make lesser features for free.

Here’s our hero for today — the details screen for a single fee plan:

Identify Potential Issues

The left column doesn’t cause any problems. It looks a bit busy, but that’s inevitable if you really have to set up a bunch of parameters. “0 means no limit” is not the best pattern, but it’s not critical here.

The key problems hide in the right column, where the user is customizing the categories. Several critical questions will arise in the user’s head.

A. How do categories and subcategories work? Why can I check the entire category, and still uncheck a few subcategories inside of it? This is a common mistake and easy to resolve. Whenever the entire category is checked, make sure to automatically check (and disable) all the subcategories in it.

B. How does “the number of categories allowed” work? What If I don’t want to limit them? This one is easy to improve, too. Just introduce a checkmark to toggle this option on or off (and disable the input field if the option is off).

But here go the hard questions.

C. What do these price labels mean for each category? Will they sum up? Where’s the total? Didn’t I just set the price for entire plan in the left column?

And the main one.

D. I do see the price labels, but are you sure I can charge for each category separately? What if I accidentally change these price labels in different plans?

These questions cannot be resolved within this screen. We need to think deeper. In the previous case the scheduling layout was bulky, but easy to understand — we merely optimized it, making it more elegant and saving a few clicks in the most common use cases.

Today the situation is different! The screen is confusing. We aren’t just optimizing a bulky grid of settings. We’re dealing with different pricing models.

Treat Different Pricing Models Separately

So it’s never a great idea to combine different logical models into a single setup. Let’s try to systematize what the user might want to do (mix and match):

• Charge for each category separately
• Provide fee plans for a limited number of categories
• Provide fee plans with a fixed set of categories or features

The second and the third options do the same kind of thing: sell plans. That’s good. That’s consistent. That’s what Dave’s current version is doing well: managing normal, serious plans (and each plan is customized with a good Fee Plan Details screen, like the one we’re tackling).

It would’ve worked great if it wasn’t for one little thing. The first option is not about selling regular plans! It’s about selling a huge number of “mini-plans” (access to individual categories). These mini-plans can’t be listed together with the normal serious plans — they require a separate global pricing grid to manage prices for each category.

So here’s the key problem in today’s story: this pricing grid was merged with the category list, and made the whole screen rather confusing. It happened naturally and without evil intent. They both relate to the category list, so they happened to meet in one location — inside the details for a single fee plan. Definitely not the best place for a global pricing grid!

That’s why Dave and his developer were struggling with this screen. We identified the problem. Now, what can we do to improve the situation?

Introduce a Global Pricing Grid for Categories

In the previous screen (one level up), before you list normal plans, introduce a checkmark that will toggle such pricing option.

The link Details and Pricing will bring up a screen with the following elements:

• a pricing grid — a list of categories with price labels (both in dollars and in credits if necessary);
• a few input fields that are required to set up a posting: same for all categories (duration, images & regions limits, number of characters).

As a result, the Fee Plan Details page will look very similar to its original, but without the confusion caused by the price labels:

Practicum

When dealing with complex pricing models, follow these recommendations.

• Decompose your pricing models to see what objects we’re working with in each model. Identify those that have similar logic, and those that don’t.
• Keep your logic models separate from each other. Make sure they don’t accidentally merge anywhere in your UI, like it happened in this case.
• Identify global and local settings and keep them in the right places. Make sure there’s no hint of global settings edited within a local object.
• Once again, double-check if the order of steps makes logical sense.

Have complex UI puzzles in your own product? Send in the screenshots to jane@uibreakfast.com, and I’ll tear down the most interesting situations here in UI Practicum.