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.
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.
(We took several paths to decrease CAC, but I'm going to focus only on the in-product changes for this case study).
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)
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).
Issue
Only 14% of people were making a payment
Issue
Only 30% of people who landed on the index page went to the 'Ticket found' page
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.
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.
Issue
~25% of people who entered their ticket number went to the ‘Ticket not found page’
Issue
~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)
Issue
We used an incorrect title for our main input field
Issue
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.
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.
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.
Issue
People choosing a 2‑month plan and making 2 immediate payments
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
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
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.
