Designing Promotional Codes: A UX Case Study –

In May 2016, I got a contract as a UX consultant for a relatively complex product. James is the product owner and he approached me to write FAQs for the product website, going by my (that time) title — content strategist.

UX—Alignment of business goals and users’ goals for their interaction with the product

I told James that I do not work with product teams only to write FAQs, I need to get involved for the product UX — design, content, and for the big picture business goals.

When given a chance for a quick review, I immediately noticed massive gaps in the current UX, in message architecture, and how business rules were compromised (read violated) in the customer journey. This was even before we agreed to work together, and my two hours of product review won me the contract as UX consultant.

The Product: This is a SaaS where customers can sign up and buy a subscription plan to add one or more businesses they own. Then they design custom coupons to offer deals on their businesses.

The Goal (for this case study reference): To design promotional codes (PCs) to get maximum sign ups on the product pricing page.

— — — — — —

The basic structure of this post is:

  • Before I Took Over
    – The Scope
    – Why the form design is broken
  • My Questions
    – Business Goals and Promo Codes
    – The New Form
    – Whether to get card details for free trial PCs
  • Edit PCs: Original, and Revised Workflow

I hate sharing this structure but it may be helpful to setup the context. I tweeted it to Medium and wrote to their support team as a feature request, happy to see their email that they liked it.

Before I Took Over

The steps to create a PC was a broken experience. It did not comply with the business rules, and there were huge design gaps for validations and usability.

The Scope

  • While creating a new PC, I can assign it any discount value — 1% to 100%
  • A PC has an expiry date and customers cannot redeem it after it expires
  • A PC can have a cap on number of instances that it can be redeemed
  • I can select a subscription plan (it being a SaaS model) for a PC and the customers can redeem the PC only when they buy that specific plan

The promo code form looked as below.

The promotional code design form — before I took over the product

Why The Form Design is Broken

  • Select Package: How I can assign a PC to 2 packages?
  • Free Trials: It is not advisable to mix 100% discount PCs with lower discount value PCs. Free trials should be handled separately for reports (data) and for other reference points (marketing).
  • Validity: The label Validity is used for two different fields — a sign of poor metadata planning.
  • Package Types: The option Promotional Package Type was not aligned with promo codes’ workflow, nor with the business rules.

In addition to the basic usability issues in this form, I had questions on how it helps James meet their goals.

My Questions

On Business Goals, and for Promo Codes’ Rules

[A] Order Volume Cap: Customers could select the number of businesses (as the unit of quantity) while buying a plan on the product pricing. So, if the price of 1 business in two plans is $5 and $9 respectively, the price is updated in real time for the number of businesses that customer wants to buy. For example, the total cost buying a plan for six businesses is:

Promo codes are valid for bulk order too

Since the price updates for each unit in the order, we do not need a cap on the number of businesses for PCs.

But for a free trial, I should have control over how many businesses I want to give as part of a free trial promo code.

If customers can buy N (say, 50) number of businesses without a PC or with a non-free trial PC, it does not mean that all customers with a free trial PC too should be able to buy N (say, 50) businesses. I should have this control to define a cap.

[B] Same Customer Using a PC Again: For the total number of times a PC can be successfully redeemed — does it mean a redeem by a unique user, or by repeat users too?

I should have this control whether same user can redeem a PC only once or any number of times.

[C] Context: We need to setup the context for PCs by adding a descriptive note for reference — whether it is for holidays, or a specific festival.

Without a context, how will you know which PCs are working better or least?

This data can help in growth strategy. Also, I proposed them to use a naming convention for these descriptive notes — it helps in reports.

[D] Unlimited Number of Instances: James wants an option to allow Unlimited number of instances for any PC. He anticipates that they may need to distribute such PCs to a large audience such as at a conference, or via an email campaign. Not convinced, I advised him to add a number as big as 10000 or even bigger so that at least we can have data for PCs’ redeem rate.

We cannot find a percentage out of an unlimited value.

[E] Validity: For a free trial PC, we need to define the validity of the free trial after which customers need to buy a plan. It is not required for a non-free trial though.

So, I should have an option to setup the validity of free trial PCs.

The New Form

A work-in-progress view of the new PC form is:

A revised (work in progress though) promo code design form —in compliance with product goals
  • I can select multiple plans for which this PC is valid.
  • If I select 100% discount, the option to set a percentage discount value is not available now. For such free trial PCs:
    – I can setup a cap for number of businesses
    – I can setup the validity of that free trial
    – I have a choice for whether we should ask customers for their card details (more details on this later in the post)
    – The Unlimited option is not available for number of instances.
  • For non-free trial PCs, the Unlimited option is available.
  • I can control whether a customer can redeem a PC once or multiple times.

It is not the best of form design experiences (a work-in-progress view, and also because this form is for product admin and not for customers) but at least it complies with the business rules of why we need promotional codes.

I want to make sure that I should be in the right momentum while creating a new PC as I posted a comment in this great post on form design by Vitaly Dulenko.

Whether to Get Credit Card Details for Free Trials?

Once important decision was whether to ask users for their card details for free trials. I did some research and these posts by Chargebee, Lincoln Murphy, and by Pierre Lechelle gave us some real good food for thought.

James proposed a middle way and we agreed to keep this ‘get card details’ option open for different PCs. So, I have a choice whether to ask for card details for PCs. For customers, the next step was of course different in either case — whether they add card details, or directly see their dashboard.

The basic structure was ready for how PCs form design works for business rules, for validations, and usability. The job was half done — the next important step was to fix the gaps in how Edit a Promotional Code should work.

Edit a PC: Originally

I could edit any PC and make any changes (in the original form that I shared earlier in the post). For example:

  • I could change the subscription plans for a PC, anytime.
  • I could update the number of instances, and the number of instances are reset from 1 after a coupon change is saved.
  • I could change the discount value, and I could advance the expiry date too.

It was a perfect recipe for highly inconsistent PC reports that would have been of no value to James or to the product team.

Edit PCs: My Questions

Number of Instances: The Problem

Assume that I define the number of instances for a PC as 20. It is redeemed 8 times when I edit the PC and change the number of instances to 30.

Now when the PC is redeemed for available limit for number of instances, the total number of times it is actually redeemed is 38, whereas the number of instances associated with this PC are 30 (there are no PC versions). So the reports are not normalized and the team cannot make any sense out of the PC reports data.

Number of Instances: The Solution

When I edit a PC, I cannot decrease the number of instances. And when I increase it, I should see a message for how these are adjusted for redeemed PCs. For example when I change it from 20 to 30:


  • The expiry date cannot be advanced, it can only be extended.
  • Owner cannot change the PC name, the subscription plans, and the discount value (for normalized data in PC reports).


My role in the team has given a totally different (and much needed) direction to the product. The team had designers, programmers, and a project manager but the UX perspective was missing.

This is only one side of the story. I worked on other related areas:

  • How customers actually use these PCs on the pricing page
  • PCs for upgrades and renewals
  • PCs reports

This product has given me an opportunity to bring different skills together — part UX, part content strategy (we talk about taxonomy and metadata), and part business analysis (for business rules).

Note: The form design works a little different on smaller devices.

Thanks for reading this far.

If you found this post valuable, please recommend it (the little handclap) so that it can reach others.

Cover Photo by Alexey Ruban on Unsplash

Author: Vinish Garg

Collect by: