Task
The system has a lot of legacy and has to be rewritten from scratch. Old UI is inconsistent and looks differently in different parts of the system. It should be put on consistent design system, have to be similar to existing one to make a transitions less confusing for existing users and be easer and faster to use for everyone involved.
Problem
Car inspection ERP has a lot of fields that would be printed in a car diagnostic card. Filling the form for each vehicle takes around 10 minutes. Most car inspection station have 1 or 2 inspectors. If there is one inspector, he is the only person, who fills the form and who actually inspects the car. Customers should wait the whole time in line. Some people can get bored and go to another car inspection station, because there are really plenty of them. If there are 2 of them, one would inspect the car and second would fill the form. If one is faster, second would have to wait to synchronise.
My role
Inspected legacy UI, found bottleneck points, designed UI kit, found problems, proposed solutions, optimised UX.
Key metrics
We mostly were watching UX-metrics:
Task Success Rate - a percent of successfully filled diagnostic cards without any mistakes
Task Time - time to fill and submit 1 diagnostic card
Product metrics in AAARRR-funnel were not applicable to this project, because it was non-public.
Results
To fill a form for a car in old interface average inspector spent around 10 minutes. I've managed to optimise the process by auto-fill as much fields as possible, that decreased the time to ~2 minutes or less in 80% of cases. This allows to serve more customers in both cases or both inspectors could fill their forms and inspecting their customers simultaneously, doubling the speed of service. Average reissue of diagnostic cards with error decreased from 13 to 2 per month.
Team
CTO - communicated with customer, collected requirements and feedback
UI/UX Designer - remade an UI, optimised UX
3 Frontend developers - ported the whole product frontend to React.js allowing UI to be reactive
Backend developer - ported the whole product backend to Node.js allowing backand to be 85% faster
My solution
There are actually two potential keys that could give us useful data: VIN number and vehicle passport.
In original interface, fields for vehicle and fields for owner and person submitting car for inspection are mixed up.
So I decided to logically split them in 4 blocks: data about vehicle, data about owner, data about person submitting car for inspection and inspection results.
Key fields are now made significantly larger and bordered with colour to make them easier to find. All the data is validated before the form is submitted and incomplete forms are saved automatically on any change.
What can we get from VIN number
VIN number has a lot of information encoded inside. However, number of digits and amount of encoded information is different, depending on a vehicle brand and year of manufacturing. VIN number was introduced in 1954 and for cars made between 1954 and 1981 there are actually no standard format. Modern VIN-numbers are based on ISO 3779-1983 и ISO 3780.
Not every symbol could be used in VIN-number. Allowed symbols are:
0 1 2 3 4 5 6 7 8 9 A B C D E F G H J K L M N P R S T U V W X Y Z
It is forbidden to use the letters I, O, Q, since I (i), O (o), Q (q) are similar in outline to the numbers 1, 0, 9, and also to each other. We added this to criteria of validation in time of typing, but correct modern number have a check digit, that allows to
Following the internal data, cars made before 1981 make less then 20% of all the traffic, which means that reach for this feature is 80%. Only in case of really vintage car (older then 1954, which is less then 1%) we can't get any info filled automatically.
Vehicle data block
First data block contains 15 fields:
- VIN
- Car brand
- Car model
- Manufactory year
- Driver license category
- Vehicle category (R.E.3)
- Full weight
- Unloaded weight
- Chassis / frame number
- Body number
- Fuel type
- Type of brake system drive
- Vehicle registration plate
- Mileage
- Tire brand
And 2 checkboxes:
- Foreign owner
- Was used as taxi or bus
Directly from the VIN we can achieve:
- Car brand
- Car model
- Manufactory year
For most cars without significant renovation, we can also automatically copy VIN-number to:
- Chassis / frame number
- Body number
Using a proprietary database in 99% cases we can easily get correct info for:
- Driver license category
- Vehicle category (R.E.3)
- Full weight
- Unloaded weight
- Fuel type
- Type of brake system drive
And from traffic police database we can get:
- Vehicle registration plate
- all the information excluding current mileage filled from last year's inspection
So we have 12 out of 15 fields with info about vehicle filled automatically. Of course, inspector must double-check it and ask checking questions about all of them.
Now inspector would have to fill in only 3 fields and 2 checkboxes out of 17 in this block:
- VIN
- Mileage
- Tyre brand
- Foreign owner
- Was used as taxi or bus
All these fields excluding VIN are placed closed to each other to make them easier to fill.
Car ownership document data block
Second data block contains 6 fields and 1 radio for choosing passport or registration as presented document:
- Ownership document number
- Date of issue
- Place of issue
- Owner's last name
- Owner's first name
- Owner's patronymic
All of these data can be taken from a single traffic police database request alongside license plate number from a first block. In case of request fail, document number is validated with a check digit.
The inspector have fill in 0 fields out of 6! In most cases inspector just need only to select a presented document in a radio button.
Car presenter info data block
Contains three fields:
- Presenter's last name
- Presenter's first name
- Presenter's patronymic
Following internal statistics, in 71% of cases, vehicle is presented by owner (94% in case of personal vehicles), so we fill these fields automatically.
So, the inspector have fill in 0 fields out of 3 in most cases.
Technical inspection conclusion data block
This block have 3 radios and 4 text fields:
- Radio stating is inspection passed or not
- Radio stating is this inspection primary or secondary
- Date of inspection (locked to current date)
- Radio to choose how much time this diagnostic card would be valid (6, 12 or 24 months since date of inspection or automatically)
- Date of expiry (connected to previous field)
- Price of diagnostic card
- Inspector's comments and remarks
Radio for is this inspection primary or secondary is set to secondary automatically if there are any technical inspection records for this vehicle.
Following Russian law, vehicles younger then 4 years doesn't have to pass technical inspection. If they are older then 4 years, but younger then 10 years, they must pass it every 2 years. If vehicle is older then 10 years, technical inspection must be passed every year. "AUTO" button choses expiry date automatically following this law, but the law does not prohibit setting expiry date less than specified. So, if our customer have set this function in settings, price would be different. 6 month could be useful to save some money if the vehicle is planned to be sold.
Price of diagnostic card is filled automatically following internal database, but can be adjusted individually.
In comments and remarks field inspector must write "doesn't have any" if he actually doesn't... and we fill it automatically!
So in best case the inspector have to touch 0 elements out of 6!
More about UI and it's visual feedback
Grouping and field positions
Old form had very messy UI. Fields were grouped in a matrix with kinda bad grouping. Fields had fixed length, that was not corresponding with actual text line length and was aligned as a matrix. Form had a lot of screen space wasted for nothing.
Many researches confirm that F-pattern is more easily to read than Z-pattern, so I decided to abandon the matrix structure, analyse maximum text length for every field, set a fixed maximum length for them in pixels and rearrange all the text fields to comply with F-pattern. If screen width is too narrow, fields would be arranged in 2 rows, without moving next row fields to the right.
Automatically filled and validated fields
Every field can give visual feedback in 4 colours: grey, blue, marine and red. Grey colour means inactive untouched field, blue colour means active field, grey colour with blue check mark in the right means that field was filled by user and passes validation, grey colour with marine mark means that field was filled automatically and red colour with exclamation mark in the right means that field has error.
There is a significant space between rows of fields made to show explanatory text: was that field filled with data from VIN, database or from traffic police in marine colour and errors in red.
If user touches marine colour field or check mark in the right of it, that field turns blue. This is helpful to easily mark automatically filled and manually checked fields.
Multiple selections
Form has 8 multiple selection fields. 4 of them made in form of button groups to let user fill them in one click. 4 other have a look of a text field and in empty state have a chevron icon in the right and can be filled typing first letters on a keyboard. In most cases they are filled automatically and needs to be touched only while checking automatically filled data. This design is also more convenient when inspector moves between fields using a "tab" key.
Required and optional fields
There are a lot of research and doubts about these one. 3 most used solutions include: marking all the fields with "Optional" and "Required" text, marking optional fields with small "Optional" text and marking required fields with red asterisk.
From terms of avoiding maximum of user mistakes, the best solution is to mark all the fields, optional and required with a text, because even unexperienced user can clearly understand it almost without any thinking. But we have lots of fields with long content and captions and a lot of underline text. Having every field marked like this will clog the interface too much.
Marking only optional fields with text is a bit better, but this is very good for forms that users would fill only once or very rarely (e.g. e-commerce). Also, I am trying to make fields narrower to fill as much of them in a screen as possible and having this in caption would be harmful for it.
Having required fields marked with red asterisk is least convenient solution for forms people fill rarely, but this is not our case. The system is used only by experienced inspectors and legacy version already have red asterisks. This symbol is already an industry standard and used, e.g. in Typeform so should be familiar to users. Moreover, there is a note in the beginning of the form explaining it's meaning.
The main problem with asterisks in era of server-rendered web-pages is validation on submit. People had to press button and wait until the form was submitted to understand that it's not valid. Now it's a lot simpler. Every field could be validated in real time. In my interface, if required field is skipped, it would turn red with an error description below.
Results
To fill a form for a car in old interface average inspector spent around 10 minutes. I've managed to optimise the process by auto-fill as much fields as possible, that decreased the time to ~2 minutes or less in 80% of cases. This allows to serve more customers in both cases or both inspectors could fill their forms and inspecting their customers simultaneously, doubling the speed of service. Average reissue of diagnostic cards with error decreased from 13 to 2 per month.