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).
Only 14% of people were making a payment
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.
~25% of people who entered their ticket number went to the ‘Ticket not found page’
~15-20% of people where mistyping the ticket number
We used an incorrect title for our main input field
People don’t know the car license plate number
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.
People choosing a 2‑month plan and making 2 immediate payments
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.