Loading…
Customers had to check three different places to find out what happened to their requests, and most gave up and phoned the call centre instead. I merged them into a single list where every request looks the same and shows exactly which step it is on.
Buying a policy online meant typing out your documents, then your spouse's, then every driver's — on a phone, with the papers in another room. Most of that information was already in the customer's account, so I taught the forms to offer it.
When a request failed, our customer area would show a developer's error text, a spinner that never stopped, or an empty page that looked like the customer had no policies at all. I replaced all of it with one honest answer.
The cabinet's "My family" form was four fields long and had a problem in every layer: you could add yourself as your own relative, it demanded an ID nobody remembers, impossible dates crashed it, errors ignored your language, the dropdown wouldn't close, and backspace didn't delete. This is the whole repair — backend rules, state-service integration, and frontend polish — of one deceptively simple form.
The insurer already knew what your plan covers and what you had spent, but it lived in a system built for insurance staff. This is the page that turns those raw records into the two answers people actually want: what am I covered for, and how much is left.
The policy-cancellation wizard already worked — users could verify identity, pick a policy, and submit a refund request. Then came a focused afternoon, the kind that actually decides whether a feature ships: cutting the product list to what the insurance core can really cancel, replacing scan-on-every-cancellation with a 30-minute verification window, making the wizard survive page reloads and language switches, and teaching the reason chips to match the product. About three hours of work, none of it a rewrite — all of it the difference between "works" and "ready".
We added a reason step with an optional PDF to our policy-cancellation wizard. My first upload design had two new endpoints, a new table, and a cleanup cron — what shipped has none of them. How walking the real user flow one more time made the feature smaller, safer, and done faster.
A user's cancellation refund was approved and paid, yet their cabinet showed "in progress" forever. The bug lived between two systems that never talked to each other — here's how I found it, made the status update itself before the user's eyes, and prepared the flow for the statuses still to come.
Three improvements around our online policy cancellation: every attempt now starts with a real identity check through MyID, the page no longer asks for card details when a request already exists, and "nothing here yet" screens finally help instead of confusing.
Cancelling a policy used to mean a trip to the office. I wired our customer cabinet to a new cancellation service built by my teammate, so now a customer picks a policy, sees the exact refund, enters a card, and tracks the request — all online.
A three-day sprint on the gross.uz personal cabinet: switching it to a single trustworthy data source, finding policies users didn't know they had, and polishing the interface until it feels like an app instead of a website.