PromisePay for parking tickets:

How we doubled conversion from landing to payments in 3 weeks

In a nutshell

This is a story about fixing the onboarding experience for an existing product with low inbound traffic. It shows how you can learn and grow without running A/B tests or having a lot of data.

It also highlights the benefits of fixing the process before fixing the product and the fruitfulness of low-hanging fruits.

Role: Design Lead / Solo designer
Timing: 3 weeks
Teams & parties involved:  Engineering, Operations & Support, Design, Legal
Context & Goals
Understanding the problem
Fixing the process
Ideation → Execution


In February 2019, I joined the Promise team as a solo designer to work on a mobile-first website that allowed people who struggle with parking fees to enroll in interest-free payment plans.

By that time, the product was piloting in 3 US cities: Oakland, Philadelphia and Denver. For a while, the team had no designer, and had acquired some design debt, yet any global re-design or UI update that would slow down development was off the table.


Our long-term product mission was to prevent needless incarceration triggered by unpaid traffic tickets and to prove that helping people in debt instead of punishing them leads to better outcomes for everyone.

The tactical goal was way more tangible. Our website traffic mostly came from Google ads, so decreasing customer acquisition cost (CAC) and increasing conversion from landing to payment were at the top of the list.

Increase conversion to payment
Decrease CAC

(We took several paths to decrease CAC, but I'm going to focus only on the in-product changes for this case study).

Step 1. Understanding the problem

Fresh eyes review

Every time I join a new team or existing product, I like to do an exercise: I sit down, play with the product, and then spend some time capturing every possible question before I go and talk with the team.

Not knowing anything about the reasons behind specific solutions can be really helpful when spotting potential pain points.

Screenshots and questions (Click to zoom in)

Onboarding flow

Actions taken

Discovered product issues

At a glance, we had a pretty straightforward user flow, yet the data indicated some hidden issues. The main mystery was our huge drop off between Step 1 (landing on the index page) and Step 2 (reviewing unpaid tickets).


Only 14% of people were making a payment


Only 30% of people who landed on the index page went to the 'Ticket found' page

Discovered process issues

Step 2. Fixing the process before fixing the product

How to learn quickly when you don't have enough data?

I must say that having so little data was a new and challenging situation for me. Being used to running tests and reaching out to a pretty significant user base (hundreds of thousands), I had to be creative to identify other ways we could learn.

Issue → Algorithm

Actions taken

Step 3. Discovery

Those quick process fixes allowed us to access more data and dive deeper into some of the in-product problems. Pretty quickly, we discovered a bunch of low-hanging fruits issues.


~25% of people who entered their ticket number went to the ‘Ticket not found page’


~15-20% of people where mistyping the ticket number

If a client left us their contact details, we were able to find their tickets ~75% of the time

Only ~20% of people were leaving their contacts

If a client sent us a photo of their ticket, we were able to find the ticket in ~90% of cases, only ~4% of clients were sending us photos

Humans are generally bad at typing long strings of letters and numbers

People were trying to use other numbers instead of the citation number

People were entering extra symbols (dashes, or letters that sometimes were printed on the citation but weren't  part of the number itself)


We used an incorrect title for our main input field


People don’t know the car license plate number

Quick research showed that none of the 3 pilot cities used the term ‘Ticket number’ on their printed citations

Correct terms were: ' Citation number', 'Traffic violation number', and 'Notice number'

Parking tickets don’t have the best design, and quite often the paper slip has multiple strings of numbers

Some people get tickets when driving rental or borrowed cars, and some simply don't care to remember their plate number

Knowing this stopped us from using plate numbers instead of ticket numbers as the main ID

For each discovered issue, I came up with a list of hypotheses and possible solutions that we discussed and triaged with the team.

Digging deeper for product insights

Our biggest product discovery came competely out of the blue. We noticed an extremely curious pattern going through the payment plans data: some clients were subscribing for a 2-month payment plan and then making two immediate subsequent payments.

0_o ???

Our product was created for a specific audience and use case: people who didn't have money to pay their traffic violation fines. So why would anyone subscribe to a payment plan and don't use it?

Such behavior seemed extremely weird unless you assume that the clients' initial goal was to pay their ticket in full and not have a payment plan.

We made a few calls to verify this with our clients and confirmed this assumption.


People choosing a 2‑month plan and making 2 immediate payments

0_o ???

Our product was created for a specific audience — people who didn't have money to pay their traffic violation fines.

So why would anyone subscribe to a payment plan and pay it off immediately?

Our only guess was that people had no intention to have a payment plan but simply wanted to pay their tickets in full.

2-month plan was the shortest payment plan we offered

Steps 4–5–6.
Ideation, Validation, Execution

For every mentioned product discovery, we came up with supporting hypotheses and suggested solutions. I then teamed up with CS, Operations, and Eng teams to verify and triage the full list.

We decided to implement a few obvious improvements for the input field on the index page, do a quick redesign for the 'Ticket not found' page to encourage people to leave their contact info, and add 'Pay in full' as an option. See the solution map below for more details.

Click to zoom in

Actions taken

Updated landing page
Updated 'Ticket not found' page
Added 'Pay in full' feature
🚧 I promise this looks better on desktop. However, since you are on mobile, can you share why are you reviewing portfolios on mobile? I'd appreciate a quick email —
Landing page (before)
Landing page (after)
Plan selection (before/after)
Ticket not found (before)
Ticket not found (after)


  • Conversion from landing page to payment doubled, 14% → 31%
  • CAC decreased by 5 fold
  • % of visits to the ‘Ticket not found’ page decreased by 25%
  • % of people sharing their contact info increased by 30%
  • Up to 60% clients used the ‘Pay in full’ feature

Lessons learned

It turned out that by following our initial idea and focusing on people who struggle to pay their fines, we simplified the payment process enough to become attractive for anyone who had a parking ticket. At least 60% of our actual users were not the people we had built for.