New BILLmanager interface

Meet the global redesign of the client area in BILLmanager, the complex software product for hosting automation. I am the head of UX at ISPsystem, and I would like to tell you now about why and how we did this redesign.

Two years ago we could barely imagine what was ahead of us. Over these couple of years we have hired product and interface designers and added a lot of new frontend developers to the team. We have mastered Scrum and Youtrack to manage our development process. Interested to know why we did it and what we’ve got eventually? Read more in this article.

BILLmanager is a complex program for hosting automation. On one side, it provides work space for hosting staff (the admin area), allowing them to manage services, create tariff plans, etc. On the other side, it offers the client area to customers of a hosting provider. So far, we redesigned only the client area.

In this client area, a customer can pay for services and track the order history, buy and manage services or the account parameters, and communicate with hosting support. The product is very flexible and can look differently depending on the settings adjusted by a provider, and this definitely added much more difficulty to our redesign and development job.

ISPsystem was organized at the brink of 2000. Any automation back then could be considered as a good competitive advantage. In most IT companies their founders and developers designed products, and the same did we.

Nowadays it is different. More people not versed with technical aspects tend to use hosting, such as SMB who need a simple and affordable website. Such users don’t really want to struggle with the complicated interface, and they truly have this right. Once they face any difficulty, they either apply to support or simply leave BILLmanager and the hosting provider. So, the time to make the interface easier-to-use for the new audience has eventually come.

We don’t develop a new product but re-develop the existing one. Thousands of users work with this product every day. Therefore, we decided to start with data collection and go to our hosting partners for advice. Our marketing and support provided a lot of truly valuable information about users in BILLmanager 5, their everyday problems and tasks. We created a few Job Stories, divided them into categories, prioritized, and built a job map.

Then we drew a few initial interactive prototypes of the new BILLmanager interface. These prototypes helped us understand and test our concept. They were very raw and looked far from ready for development. However, they really helped us find a way. For all of this, we spent around four months.

Below I’m going to tell about some of the issues in BILLmanager 5 and the key principles of the interface in BILLmanager 6, which will help us avoid similar issues in the future.

Let’s have a look at some of the interface problems of BILLmanager from the point of view of a new user. The experienced users don’t see some of these problems; however, in order to become experienced, you need to use the product almost every day. Clients of hosting providers often do not visit their accounts unless there is an issue associated with their service e.g. with the virtual server.

As far as we know, most clients of hosting providers enter their accounts in the billing system less than once per week. You simply cannot become an experienced user this way, thence unlogical or unclear interface principles would likely remain unclear for you.

See below an example. It stumps a lot of users during their first visit:

The buttons underlined on this screenshot become available only after you have clicked on any line inside the table below them (in our case these lines are virtual servers). However, the lines don’t seem to be clickable even when you navigate your cursor to them. Furthermore, the buttons are not really linked visually to the lines in any way. There are a lot of such problems inside BILLmanager 5. Let’s have a deeper look at the most critical ones.

The next screenshot shows the BILLmanager 5 dashboard as it is seen by a new user for the first time. A lot of information is presented there “just because we have it”. Really useful data marked red gets lost among the unnecessary information.

It results in problems that new users face when doing simple tasks such as service ordering, adding their account balance, or sending a support request. Many users simply don’t notice the key buttons and menus (confirmed by many real user tests).

On the one hand, a provider is able to set up everything flexibly; on the other hand, a new user normally faces the three main issues:

Sometimes, when a user interacts with an object, he or she has to apply to support. See the screenshot with the virtual server below.

You can open a ticket from here (“Support” → “Support tickets” in the left bottom corner). However, if you click on “Support requests”, you would need to make at least three clicks in order to get back to your VPS parameters. The user context will be lost. Even the “return” button in your browser would not help here as it cannot work with tabs created inside BILLmanager 5.

You can see it everywhere. There are two main interface components: forms and lists. Text information is always presented as a form with fields that simply cannot be edited. Date format is taken from the database. Almost every table has the ID field. Why? Such field doesn’t give any valuable information to the user.

So, our team had to persuade the company to revise its design and development approach and push the User ahead of the Developer. And you know what? We did it :)

Design is always about hypothesis. Even if you have a lot of statistical data, research results, and feedback from your support team, this all is in the head of your designer, and he/she is the one who builds the product. Data about users and their behaviour improve quality of your hypothesis. It would be great if your design would be changed evolutionarily, you have just a few theories to test for one iteration, these theories affect only a part of your product and can be checked on the prototypes and real users after the release. Your designer understands clearly which solutions are good or bad and which path to choose. However, such ideal world didn’t happen in our case.

We are first real designers in the company who work with products. Before us designers only drew icons. We had to redesign the interface completely. It would definitely lead to a lot of various theories, and I felt like blind in a dark room. Therefore we created the main principles and tested them on our prototypes. These principles helped us implement our design theories.

A user doesn’t need all product features at the same time. He or she doesn’t strive to find every corner of your product. However, BILLmanager 5 was designed to be developed easily, and this creates the problems. This is so easy to find another line to the endless left-side menu and a search field to help a user find the required menu in global navigation (true catastrophe, indeed).

In BILLmanager 6 we made the main menu horizontal. It looks really simple from the first sight; at the same time, it contains the same set of features. We made the interface much easier-to-use for most users by making it a bit more complex for the rest.

Yes, the horizontal menu is more difficult to develop: We had to design every element very carefully and test our theories on prototypes. But the good news is that now everything important is available right away.

One of the key elements that allowed us to make the structure easier-to-use was object cards. These cards show all features and parameters of the object. It doesn’t matter how complicated the object looks: the card allows to manage it from one point. This is an example of a VMmanager license:

In BILLmanager 5 the same information is scattered among a few pages or sections, or simply missing.

All service user tasks in BILLmanager 6, like profile operations, balance, support tickets, or cart viewing, were designed so that they could be called from any context (system status) and allow a user to return to the previous task easily. See the screenshot with the support system below. You are adding a ticket (or reading FAQ available right here to solve the issue on your own), click on Send, see information about approximate time of response, and get back to your previous work without any excessive steps.

Domain ordering differs from virtual server ordering. This is the reason why we have made such operations different and customized for the most important services such as virtual and dedicated servers, domains, SSL certificates, and virtual data centers. We will keep working on it and make them better, but already now ordering of these services is much easier.

Users tend to order only one service. In this case, addition to cart is excessive, thence in BILLmanager 6 you can order a service and pay for it without adding it to the cart. For instance, you can set up SSL ordering like this:

I showed you the old dashboard of a new user at the beginning of the article. Useful information there can barely be found among the less important data. We changed it in BILLmanager 6.

Our dashboard has a few different options to show, depending on the amount of active services and provider settings. If there are no services, the billing system will show services available for order and sorted in the order specified by the provider, or send a client to order the main service, although we recommend providers to display services on the dashboard instead. If your client has just a few services ordered, the system will show them all on the dashboard. If there are a lot of services, it will show only those having issues.

Furthermore, we are not going to show empty tables to a user anymore like in BILLmanager 5. If a client enters the virtual server section but has no servers there yet, the system will initiate a new server order.

The more changes we bring to the product simultaneously, the more difficult it gets for users to perceive these changes. We have redesigned the whole interface, so user reaction is very crucial for us. We track it in ISPsystem account area which has been upgraded first. We look at conversion rates after different actions such as license purchasing and prolongation, support tickets, or balance additions; keep track of return rate (it keeps growing by the way), etc. By now we can make a conclusion that negative feedback on the new interface is minimal. Most users switched to the new UI smoothly and without any difficulties.

Mobile interface. We want to implement it as soon as possible and plan to give the mobile user the same features available for the desktop user. We are going to start with basic functionality (service ordering, balance, quick view of parameters) and add more features with time.

Website integration. We want a provider’s website to know that a user is authorized in the billing system. In this case the user will be able to see his/her balance, send a support ticket quickly, and order a service without any issue right from the website.

Integration with ISPmanager and VMmanager. We plan to convert the account area into the single point of management of all resources purchased from the provider.