After we were done with all the tweaking of our UI, we wanted to test it and the solution to that came about through a strange opportunity. One start-up which was implementing JusBill, was also looking for staff in its accounts department. As part of the interview process, we asked each one of them to sit in front of a computer and use jusbill to generate a bill. We would obviously tell them who the consignee was and what the product needed to be sold but nothing more. Out of 25 candidates 11 generated the bill with absolutely no navigational questions; 8 had less than 4 questions and the remaining needed us to tell them how to do it once!
These were people who had never seen JusBill before, never used anything of this sort. These were people with general educational level of around Senior Secondary only. These were people from remote villages around Bulandshahr and Sikandrabad.
What excited us most was that this meant direct employable computer skillset for a huge set of people! This is the story of how we went about developing the user interface for JusBill.com
The Premise
JusBill.com is a simple invoicing application built for the Small Business staff in India. When we went for our first installation, we took about 20 minutes to explain to the billing staff on how do they use and operate JusBill. The person we were training was not a graduate, he was however intelligent and had invoicing experience using paper and pen. He took 20 minutes of our teaching him how to use JusBill.
20 minutes of personalised training was a huge disappointment. The fact that the training time included explaining how to connect to the internet and type www.jusbill.com was no consolation either.
The problem
When we dissected the problem, we realised that he was very comfortable with the screen as long as he saw a place holder to fill up stuff. So when he wanted to fill up the vehicle number, he could see a text field with label as Vehicle Number – he could fill it up. Similarly when he wanted to add a consignee, there was a field saying “Load Customer” in his face and he promptly used it.
The place where he faced problem was when he could not find the placeholder. We had hidden the Excise Tax field and it was available only on a click! The reason for hiding Excise tax was that retailers do not have to pay Excise Tax and therefore they do not want to see an additional field which would confuse them.
The problem was tricky simply because part of our customer base wanted the fields to be visible and part of them did not! Not making these fields visible confused one lot and making it visible confused the other.
The Non Solution
The first idea was to build up different forms for different types of customers. So a retailer would never see Excise Tax field but a manufacturer would. The solution was flawed because of several reasons
- Govt Regulations keep changing and you never know which all new taxes or changes may come about. Keeping several forms would lead to maintainability issues and sooner or later we would be faced with the same dilemma which we faced today.
- There was a class of customers namely dealers and traders who needed both – Excise tax to be visible on certain kind of transactions and not visible on certain others.
Solution – Take 1
We decided to keep one form itself with partially hidden fields. Whatever fields would be automatically hidden or visible is decided by the type of user. User can expand partially hidden fields easily by checking the visible part of these fields.
How is that different from a click, you would ask. When we were using a click it was opening up a drop down box of taxes, excise being one of them. So a customer would need to click thrice on the same link to add Excise and VAT and Additional Duty.
In our solution, we instead put three different checkboxes each with Excise / VAT / Special Additional Duty. Those who want to specify Excise can simply check on that check box and AJAXically the Excise tax is applied.
The one form concept also paid dividends. We would show this form immediately after login. This reduced the number of clicks to reach the most frequented page and gave him/her an added comfort level.
We had to use a substantial amount of AJAX and Javascript to ensure that he sees things happen the moment he presses the button. All that the UI had to do for him was to reassure him till he grows familiar with it.
The Challenge
We had the good fortune that our first user was someone with no experience of internet or internet based applications. He became our model user and forced us to use the simplest possible UI for our application. The subsequent users have been far more technology savvy. The urban backoffice users are at immediate ease with the system.
As we progress further there are newer challenges that come.A recent user from Kerela told us that there is Cess on VAT in Kerela; something that we put up for him in a matter of hours. This functionality is redundant to most other non Kerela customers but since it followed the same principle of partial visibility, none of our existing customers called in or reported anything. Most realised the same only because they saw our mail telling them about it.
Solution – Take II
Improvement of UI is a continuous process, We keep exploring opportunities where we can make it simpler. But what we keep in mind always is that simplicity is not the absence of complexity; it is the removal of complexity. A simple user interface does not mean reduced features; it just means a comfortable experience which empathises with the user’s needs.