A credential flow from 5% to 30% conversion
I argued the whole flow was built around the wrong thing, got to redraw it, and conversion went from 5.1% to 29.9% over nine months.
Redrawing it meant moving the stored information underneath, not just the screens.
Nothing here belongs to us
Heating an old apartment building is one of its largest bills. We’ve told customers we saved them more than $173M.
Every piece of the evidence for that belongs to somebody else. We don’t own the bill, the portal it lives in, or the password that opens it.
Credentials expire on their own schedule without saying so. Portals get redesigned without warning.
My role
I designed the flow and the failure states, wrote a lot of the front end, and made the architectural argument.
Not mine: the verification service and the utility integrations. Better scraping landed in the same nine months, and I can’t cleanly separate my part from that.
The shape was wrong
You can’t fix the wrong noun with better copy.
The old version walked you through one step at a time, starting from the building. Reasonable, until you meet a customer.
What we actually found:
- One login covering four buildings.
- Four logins covering one building.
- An account covering three of yours and two belonging to somebody else.
The old version assumed one building, one account. That assumption wasn’t in the screens, it was in how the information was stored, which is why nobody had fixed it.
So I proposed starting from the account. Connect it, find out what it actually covers, then map that onto buildings while verification runs in the background.
I don’t know that I’d have said yes to me. Getting told yes is still the most generous thing that company has done for me.
Introducing the pizza tracker
Flipping it created a new problem. Verification now runs in the background, background work makes silence, and silence reads as breakage.
People had just typed in a bank-adjacent password and were looking at a blank screen. Of course they left.
My idea here was deliberately dumb, and I kept calling it the pizza tracker until the name stuck.
Named stages, where you are now, and no time estimate we can’t honor.
You always know where your pizza is, and nobody has ever needed a tutorial for it. A fake progress bar is worse than none.
The bad states got real screens
Four states I drew as real screens with real language:
- Credentials expired.
- Partial coverage.
- The portal changed overnight.
- Verification failed and won’t say why.
That’s most of the work in this project.
On a system you don’t control, that isn’t the edge case. It is the product.
What I was designing for is simpler than it sounds. You should never be unsure what state a connection is in, and definitely not when the state is bad.
What I still can’t see
Lifetime completion across the whole wizard is 10.4%, dragged down hard by the early months. Both numbers are true.
Somebody would do that math eventually, so I’d rather hand it over. What surprised me is that nobody asked.
I volunteered it in a review and it changed how the number got quoted internally.
The real failure is that I know how many started and how many finished, and nothing in between. So I improved this without ever knowing which single step was worst.
The fix is cheap: an event per step, per outcome, per type of failure. Then expired credentials and a changed portal stop looking like the same number.
About a week of work, and it turns nine months of iteration into a handful of experiments.