Customer Center

The challenge

The system had been built in the late 1990s to let retail and wholesale customers manage domains, hosting and billing. A decade later, BigRock and a DNS management product were added on top of it. Every year brought more features, and each one was fitted into an architecture that had never been designed to hold them. By 2017 it was the backbone of the business and one of the hardest things about being a customer.

The goal was not nostalgia. We were not trying to restore the early days of OrderBox — we were trying to recapture what had made it feel simple, on a foundation that could carry a rapidly evolving business and a far more diverse user base than it was built for. Better experience and genuine simplicity were the means; customer success and a lower churn rate were the point.

Five goals framed the work: easy to use on every device, products actually organised, usable across a range of personas young and old, new revenue models — and, added later once we could see what we were dealing with, less is more.

Research with no data

The first problem was not a design problem. No tracking metrics existed anywhere on the legacy system — twenty years of use and not one event to read. There was no funnel to inspect, no drop-off to find, no way to know which of the hundreds of features anyone actually touched.

So we went and asked. We reached nearly thirty customers on the phone. We sat with six people from the support team, two each from the tele, chat and ticket desks — the only people in the company who heard the frustration every day and could tell us what it sounded like. And we pulled apart how GoDaddy, Namecheap and CrazyDomains handled the same jobs.

Talking to support turned out to be the shortcut. Customers describe symptoms; the support desk has already worked out the pattern behind them.

What we found

Six things came back, and the last one reframed the project:

1. AProducts were listed in no particular order, so finding one was guesswork.
2. BRenewal meant opening each product in turn just to find out whether it needed renewing.
3. CRaising a ticket took three pages of navigation.
4. DDNS was the biggest problem of all. Customers did not know what an A, AAAA, CNAME or NS record was, where to change one, or where not to.
5. EMultiple logins were required to get through one job.
6. FPeople came back for four reasons only: to renew, to update contact details, to manage DNS and nameservers, and to file a ticket.

That last finding is the one the redesign hangs on. A control panel with hundreds of features was being used, over and over, for four things. Everything else was scenery — and the four jobs people came for were buried behind it.

The new architecture

Before anything could be drawn, the existing information architecture had to be mapped — you cannot define a new flow without knowing the shape of the old one. Laid out end to end, the old flow showed how far a customer travelled for each of those four jobs.

The replacement was a single-page application in three columns. The first column carries overall navigation. The second lists the products. The third is a workspace where the work actually happens — payment, DNS and nameserver management, reaching any third-party control panel, opening a ticket. Nothing that mattered required leaving the page any more.

Then the layout was pushed further, under the goal we had added late: less is more. Products were grouped. Each product carried its own alert notifications and its own support link. Renewal moved onto the first page, both for a single product and for a whole group at once. Links opened third-party panels directly, and cross-sell was built in as a considered call to action on the product list rather than an interruption.

Four problems, four fixes

Finding a product, and renewing it

The first two findings were really one problem. Products were grouped under the domain name they belonged to, so the thing a customer thinks of as my website appeared as one row instead of five unrelated ones. Expiry dates sat on the surface. Anything needing attention said so, with a call to action next to it.

Renewal collapsed with it. The old flow ran: view all orders, pick products, choose tenure, pass an upsell and cross-sell screen, read an order summary, then choose a payment method and pay. The new one starts with a Renew button sitting next to the product — or Group Renew for everything under that domain — and then does tenure, order summary and payment in a single step.

Raising a ticket

Support existed only in the footer, with no relationship to the product a customer was struggling with, three pages away from the point of frustration. The support centre moved to sit beside each product, so asking for help about something happens where that something is.

Nameservers

The old screen put the BigRock nameserver and any third-party nameserver in the same fields, which is precisely where naive customers came unstuck. The new one asks a question instead: is the server with BigRock, or somewhere else? BigRock is the default and points at whatever server the customer has bought, falling back to ns.bigrock.in. Choosing Custom Name Server from the dropdown opens an empty field to type into. Making it a choice rather than a text box is a small change that made a disproportionate difference.

DNS

DNS management had been a separate section at the bottom of the page with no relationship to the product, opening in a popup, with every record type on its own tab and no grouping. Customers could not tell the record types apart and were left guessing at what each one did.

The rebuild splits the audience instead of the records. Manage DNS is only enabled when the nameserver is BigRock's — if the domain points elsewhere, DNS belongs to that provider's panel, and saying so prevents an entire class of mistake. For the naive customer there is Simple DNS: a Destination record that handles A, AAAA, CNAME and NS behind one idea, and Site Redirect for URL redirection. For the expert there is Advanced DNS: one entry point for every record type, values grouped by host name, fields that change with the record chosen, and the rules enforced rather than explained — a CNAME record nullifies A and AAAA, an NS record nullifies CNAME, A and AAAA.

The same screen also carries the things people came back for: editing contact details, the security pin for a domain transfer, privacy protection and theft protection as switches, and information where a decision needs context.

What changed

Two months after the phase-one launch, on web and mobile, renewal conversion had moved in the right direction and DNS management was measurably easier to get through. The number that mattered most to me was the support contact rate, which dropped significantly — customers were fixing their own problems, which is the outcome the whole redesign was aiming at.

I would not over-claim two months of data. A change of this kind is a behaviour change, and behaviour changes show their real shape over a much longer period than one quarter. The honest reading is that the early signals pointed the right way.

Figures are omitted for confidentiality. The application was still under active development at the time this case study was written, and all views here are my own and do not necessarily reflect those of BigRock.

My role

I led UX design, working with the business unit head, marketing head, brand manager, product manager, the support team and the core and frontend developers. Research, prototyping, information architecture, wireframing and user testing were mine.

In practice that meant partnering with product and brand to turn insight into features that answered real customer behaviour; building the information architectures, wireframes and prototypes that carried the vision well enough to win alignment and drive decisions; defining scope alongside the project management team, and arguing for customer goals while keeping business goals whole; designing responsively across journeys, wireframes, prototypes and specs; validating with more than fifty internal and external users; presenting the work to executives and senior stakeholders to earn buy-in; and analysing the product after launch with our project management partners so the design kept improving.