Redesign service Gorserv
2021
Gorserv is automatised service which helps customers to order household services and helps foremans to find a work. It is like an Uber for handymans.
The system operates as follows.
There are two types of users in the system: clients and service providers. When something breaks in a client's home and they need a technician for repairs, they submit a request on the Gorserv.com website. Service providers receive and accept these requests, then go to the client's address to perform the repairs. If the service provider completes the job satisfactorily and the client has no complaints, the request is considered fulfilled and closed.
However, sometimes things don't go as planned. Additional services may be needed, or the technician may have performed the job poorly. To address such issues, the client contacts the dispatcher, and the dispatcher creates aa appeal (=claim) for the request (=completed service).
There are two types of users in the system: clients and service providers. When something breaks in a client's home and they need a technician for repairs, they submit a request on the Gorserv.com website. Service providers receive and accept these requests, then go to the client's address to perform the repairs. If the service provider completes the job satisfactorily and the client has no complaints, the request is considered fulfilled and closed.
However, sometimes things don't go as planned. Additional services may be needed, or the technician may have performed the job poorly. To address such issues, the client contacts the dispatcher, and the dispatcher creates aa appeal (=claim) for the request (=completed service).
I developed new interface for appeals, which was designed primarily to speed up the work of dispatchers, as well as to simplify the search and comparison of information during data exchange within the company.
Create a new appeal
I started working on the creation form for inquiries. It has a small set of fields, but due to the lack of design, it looks complex and untidy.
Old design of the form for creating appeals.
The main task in developing any form is functionality, convenience for employees, and aesthetics. Even simple alignment of elements relative to each other and reducing the abundance of borders would make the form significantly neater, simpler, and more understandable. However, we already have a design system that will expedite the construction not only of this but any other form in the system.
Together with the client and their team, we discussed the problems of the current interface, and I identified the main pain points in creating inquiries:
Together with the client and their team, we discussed the problems of the current interface, and I identified the main pain points in creating inquiries:
Problem
Solution
Difficulty in understanding the structure due to chaotically arranged fields without grouping by meaning.
I re-evaluated the arrangement of fields as if a dispatcher were describing the inquiry in text: who the inquiry is from and about what, and who, where, and what actions need to be taken.
There are unnecessary elements and fields.
After discussing the form with the client, we not only removed fields that are filled in automatically or are not used in further work but also added fields that dispatchers lacked in the old form.
Some names were given in technical language from the database, without considering the understanding of users, especially beginners.
Now all fields are named according to their content. For example, "Источник" (Source), I changed to "От кого" (From whom), or "Описание родительской заявки" (Description of the parent request) transformed into "Исходная заявка" (Original request). Shorter and to the point.
Fields are of the same width and lack orientation regarding the volume of information they should contain.
In the new form, there are no long identical fields that may resemble a lined notebook. Each field is as long as the information it contains.
The fields are arranged in one column, simplifying their vertical filling.
Two columns have turned into one, which can be filled sequentially using the Tab key.
New interface
A design system is a living structure that changes and grows in the process of working with it. New elements are added, and existing elements are adjusted for new conditions and tasks. It's a natural process.
Work with appeal
After creating appeals, we moved on to analyzing the screen for working with them.
A screenshot of the old page for working with appeals and comments from the developer.
Workflow
Here, in addition to the problems present in the form for creating a new appeal, new issues have arisen:
- Low information density.
- Insufficient grouping of information by meaning; some fields are not in their proper places.
- Unimportant data that takes up too much space on the screen.
- The page is stretched in height due to the different content of two columns.
- There are tabs that can shift content on the page when opened/closed, complicating the standardization of content representation.
- Lack of visual identifiers for different types of information.
- Inconvenient handling of inquiries through radio buttons at the very end of the page, which essentially represent the main function of the interface.
- The client wish to have white and dark interface's modes.
What needs to be done
Low information density and grouping by meaning
The first step in working with the new interface is to create the structure and hierarchy of elements. To do this, it is necessary to understand what is important for the dispatcher to see first, what he frequently uses in his work, what is missing, and what hinders him, and in what sequence he works. I asked to record a video of the employees of the company, the head of the quality control department, and technical specialists working with the screen – people who work in the system every day and for whom it is being improved.
Employees often exchange order and request numbers, and now this can be done with a single click by pressing the icon next to the number. The touch area should be wider than the icon for easy targeting.
In the title of the request, buttons for editing and deleting the request have been moved. Previously, they were at the very bottom and visually related to working with slots rather than the request as a whole.
Employees often exchange order and request numbers, and now this can be done with a single click by pressing the icon next to the number. The touch area should be wider than the icon for easy targeting.
In the title of the request, buttons for editing and deleting the request have been moved. Previously, they were at the very bottom and visually related to working with slots rather than the request as a whole.
On the first screen, there is reference information about the initial request (service provided) for which this appeal (claim) is created. The screen is divided into 2 parts. On the left, there is information about the appeal, and on the right, there is reference information about the initial request.
The status of the inquiry is important. It indicates at which stage of consideration it is: in the schedule with the performer, in progress, postponed, in the stage of report formation, under review, rejected, or closed.
Сonsistency of information place
In the old interface, collapsible blocks were frequently used, which shifted the content. This made it challenging for various employees to orient themselves to the screen, as different blocks were typically expanded for each user. Additionally, this display style hid information that could have been condensed rather than hidden.
For instance, in the "Slots" block (a slot being one execution or service correction), each slot occupied 3 rows. The total number of slots never exceeded 5.
For instance, in the "Slots" block (a slot being one execution or service correction), each slot occupied 3 rows. The total number of slots never exceeded 5.
I made each slot a separate row where all the information fits, and I changed the order of the fields, placing the worker's full name in the middle so that the appointment dates do not visually mix with the dates in the schedule. The worker's full name has become an active link leading to their personal page.
Informativeness
For each inquiry, there is a call history. It is a separate page where the dispatcher can view the dates and duration of calls, listen to the conversation recording, and transcribe the audio into text.
On the main page, I added a brief summary that enhances the informativeness of the section before entering it. Specifically, it includes the date and time of the first and last calls, as well as the total number of incoming and outgoing calls related to the inquiry.
This demonstrates the duration of working with the inquiry and the level of communication activity with the client.
On the main page, I added a brief summary that enhances the informativeness of the section before entering it. Specifically, it includes the date and time of the first and last calls, as well as the total number of incoming and outgoing calls related to the inquiry.
This demonstrates the duration of working with the inquiry and the level of communication activity with the client.
Updated action history
All operations related to the appeal are reflected in the "Actions" block, which was inaccurately named "Comments" in the old version and opened upon button click.
Updated block is collapsed at the first view, showing only the latest action. This helps dispatchers quickly understand the current status of the inquiry and what needs to be done next.
Updated block is collapsed at the first view, showing only the latest action. This helps dispatchers quickly understand the current status of the inquiry and what needs to be done next.
Previous version
The expanded block has gained numerous additional functions. Actions now have hashtags indicating status, message type, and reasons for changing the appeal status.
Color-coded markers have been added to all actions for quick orientation and information retrieval of the required type. Color choices have been retained from the old interface to ensure dispatchers' familiarity:
Calls are additionally marked with a phone icon, which can be clicked to access the call description in the call history.
All histories on the page are sorted from new to old. In the old interface, each data table had its own sorting, confusing dispatchers.
Color-coded markers have been added to all actions for quick orientation and information retrieval of the required type. Color choices have been retained from the old interface to ensure dispatchers' familiarity:
- Orange for rejected requests.
- Red for postponed requests requiring further action.
- Blue for requests rescheduled in the worker's schedule for another time.
- Dark blue represents data changes or • system commands.
- Light blue for statuses indicating interactions with the client.
Calls are additionally marked with a phone icon, which can be clicked to access the call description in the call history.
All histories on the page are sorted from new to old. In the old interface, each data table had its own sorting, confusing dispatchers.
Collapsed Actions
Expanded Actions
From radio buttons to the main function
With this feature, dispatchers work every time they open an appeal. There were many complaints about its design. The use of radio buttons was unsuccessful — it was difficult to aim at the desired option. The "Send" button was intentionally moved to the right because dispatchers would often click on it automatically without understanding what they had selected in the functions above.
If a user makes a mistake in working with the interface, it doesn't mean they are bad at navigating it, rushing, or being inattentive. It means the interface is poor.
If a user makes a mistake in working with the interface, it doesn't mean they are bad at navigating it, rushing, or being inattentive. It means the interface is poor.
The interface should adapt to and prioritize the user, not the other way around.
In the new version, each function is implemented as a tab, and frequently used ones additionally have icons. The fields have been enlarged, and the button is in the familiar place for forms.
Visual identifiers
Color identification has been added not only to the action block but also throughout the entire interface because we have introduced some additional functions that dispatchers need to recognize at a glance.
Green is used for actions within the appeal (urgent call to the performer, file viewing, information copying, data uploading, etc.).
Orange is designated for transitioning to other sections and launching external programs.
By maintaining the colors from the old interface, distinguishing between what is a link and what is not becomes impossible without hovering the cursor over the element.
Green is used for actions within the appeal (urgent call to the performer, file viewing, information copying, data uploading, etc.).
Orange is designated for transitioning to other sections and launching external programs.
By maintaining the colors from the old interface, distinguishing between what is a link and what is not becomes impossible without hovering the cursor over the element.
Number Format Changes
When numerous digits are placed next to each other, or when there are many zeros or optional symbols, it creates visual noise that can confuse system users. Dispatchers do not pay attention to seconds in time; hours in duration are extremely rare.
I modified the formats to display only the necessary information, with a primary focus on quick orientation. For example, time is now consistently written using a slash without seconds, and hours in duration are only added when applicable.
I modified the formats to display only the necessary information, with a primary focus on quick orientation. For example, time is now consistently written using a slash without seconds, and hours in duration are only added when applicable.
Dark and white theme modes
The client requested the development of two themes. It's done as requested.
New calls history
Before
After
Preliminary calculation
The "Preliminary Calculation" function is essential for the dispatcher to understand the cost of future work.
In the old interface, it involved a series of pop-up windows where the dispatcher first had to click on the "Add Services/Works" button, then find and select the service. There are also estimate services, the cost of which is calculated individually. This is a separate button where you also need to find the service in a list in a separate window, but then manually enter the amount.
In the old interface, it involved a series of pop-up windows where the dispatcher first had to click on the "Add Services/Works" button, then find and select the service. There are also estimate services, the cost of which is calculated individually. This is a separate button where you also need to find the service in a list in a separate window, but then manually enter the amount.
1st pop-up
2nd pop-up with the services list
I changed the sequence of actions, streamlining them. I moved the service search into the main window, increased the touch areas to accommodate more services, eliminated duplicate elements such as the "Close" button, and made the hierarchy of elements more explicit.
Needs to be changed
New pop-up
Drop-down list with the services
Main pop-up with all types of info
This was the second stage in working with the Gorserv system. Based on this interface, the Requests section will be developed.
The work does not stop, as the system is set to undergo a complete update to enhance the convenience and speed of operation for dispatchers, performers, and clients.
The work does not stop, as the system is set to undergo a complete update to enhance the convenience and speed of operation for dispatchers, performers, and clients.
