Elinext. Leave Management
Elinext. Leave Management
Information
Region:
Worldwide
Industry:
HR and Recruiting
Type:
Web Application
Engagement model:
Internal Use
Duration:
3 years for different versions
Staff:
Back-end developer/Tech lead, Back-end developer, Front-end developer, QA engineer, Business analyst, UX/UI designer
Technologies used
NUnit
NewtonSoft
Dependency Injection
Z.EntityFramework
OpenXML
SCSS
RxJS
Oidc-client
Angular 11
Healthchecks
Swagger
Hangfire
Prime NG
Identity Server 4
.Net 5
MS SQL Server
ASP Net Core
Fluent Validation
Auto Mapper
Moq
HTML5
Entity Framework Core
TypeScript

Client

An internal web application tailored to the specific needs of the Elinext company. The previous version of Leave Manager was active till 2021 and became outdated, so it was decided to develop a new version of Leave Manager

Project Description

Elinext, a custom software development company, has been in the market for over 25 years, and during this time, our workforce has expanded to over 700 employees.

Naturally, managing vacations, sick leave, and days off in such a sizable company is essential. For an extended period, we relied on an outdated service with subpar UI realization which proved difficult and non-intuitive for our team to use.

In response, in 2021, our company made the pivotal decision to revamp the existing solution and launch an entirely new product. A dedicated team of UI/UX designers, developers, business analysts, and QA engineers collaborated on this project, and we continue to actively support and enhance our new product.

As our company is now an alliance of international affiliates, it was impossible to operate across multiple jurisdictions with an old solution built on an outdated tech stack.

Challenges

The Leave Manager had to be an all-encompassing solution designed to streamline vacation and sick leave management within a company. This service should offer a range of functionalities catering to regular employees, resource managers, and HR specialists. Here is the list of challenges:

  • Employees should be able to effortlessly monitor their accrued vacation days, request time off, report sick leaves, and view upcoming absences of their colleagues.
  • Resource managers should have an opportunity to easily engage with various employees and teams, ensuring they stay updated on their team's plans.
  • Employees should have time to familiarize themselves with the updated application as redesign is radical, and basically, this is not an update of an app, but a new version of it.
  • Get feedback on user interactions with the system, act on identified issues, and propose improvements.

Process

It was important for the development team to assess the effectiveness of our hypotheses regarding user interaction with the application, examine and evaluate the user experience, identify any issues, understand how they can address them, and overall, determine what to be improved to make working with the service more enjoyable and straightforward.

To achieve this, the team utilized several tools that allowed us to track various metrics and gather analytics. We integrated three tools into our system: Google Analytics, Mixpanel, and Hotjar.

To study the interaction with the system, the development team used session recordings and heat maps provided by Hotjar. We reviewed approximately 500 screen recordings and identified key interaction scenarios with the application.

During the development process, we implemented minimal adaptability for mobile devices. However, upon reviewing the recordings, it became evident that this is insufficient, and there is a need to optimize the application for mobile devices, at least in the part used by regular employees.

This is especially important for sick leave requests because if someone wakes up with a fever in the morning, they are unlikely to use a desktop device to submit a request; instead, they would prefer to use what's at hand — a smartphone or a tablet.

Solution

There are 7 different roles in the system, many of which are very similar and have comparable functions. Therefore, we have identified 3 roles that are most commonly used within the system.

The first role is that of a regular company employee, who can submit requests for vacation/sick leave, view the calculation log, and their profile, as well as see requests from their teammates.

The second role is that of a project manager. In the system, in addition to the functions of a regular employee, they also can add requests for their teammates, process requests from their team members, export requests, generate reports on teammates working hours, and manage teams.

The third role is that of a resource manager. In our internal hierarchy, this person is responsible for an entire department consisting of numerous employees who may belong to different teams. They have all the permissions available to regular employees and project managers, and in addition, they are capable of managing the location of subordinates.

There is also an admin role that allows fine-tuning the app to the business requirements of the team. Admin has access to virtually all the functions of the app, superior even to the resource manager.

When it comes to modules, certain ones are available to all 7 types of users, like My Profile and My Requests. The module that requires Managing Requests of Employees is only available to project managers and resource managers (as well as to administrators).

The View Calculation Log (Vacation/Illness) module is available to everyone while Resource Managers have access to other people’s data.

The ‘Manage Profiles of Employees’ module allows viewing employee lists, editing profiles, and relocation of employees via territories. As well as creating unpaid periods, and updating counters’ values, and locations for users. Then there is the Reports module that allows managers to report on the working hours and approved days off.

The ‘Manage Teams’ module allows managers to view, add, and edit teams and participants to the team. Notifications are also realized, for all types of users as well as a couple of supplementary modules that allow requesting help and viewing the glossary.

Results

The system is widely used within the company. The development team received reports indicating that the system is actively used on weekdays and is practically unused during weekends. On average, approximately 40 people utilize the system per day, with an average interaction time of 7 minutes.

The most common locations are Belarus, Poland, Vietnam, and Georgia.

Mainly, our employees use the web version of the application, with less than 4% accounted for by mobile devices.

As you can guess, the development team studied user behavior for this product, and if you’re curious about the shown results, we will tell you more in the next section.

More Details on the Use Case of the App

After reviewing the recordings using Hotjar, the development team has identified the main user scenarios for system usage by users with different roles.

Ordinary employees spend the least amount of time in the system; they rarely use filters and sorting in tables, and rarely adjust the column width or table display settings.

Mainly, they interact with two application pages: "requests" and "my requests."

Occasionally, they access their profile (presumably to see when their additional days off are accrued and to recall how many vacation days they are entitled to in a year) and the calculation log.

Most often, an employee logs into the system submits a request for a day off or sick leave, and immediately logs out, a process that takes less than two minutes.

Sometimes employees check their colleagues' requests but this is not the most common scenario.

Predictably, project managers and resource managers spend more time in the system, and their interaction scenarios are slightly different.

They check notifications, process requests, and submit requests on their own or others' behalf.

They often use filters and sorting in tables but also hardly ever use column settings and table display options.

Thus, the analysis conducted by our team confirmed the hypotheses we formulated during the development stage. The research did not reveal any significant problems with user interaction.

The development team did not notice any noteworthy difficulties in using the system, and those that were identified were so rare and insignificant that they could be attributed to statistical error.

Users do not need to spend a considerable amount of time learning the application to find the necessary functions; they easily and swiftly address their tasks, spending a minimal amount of time in the system. All the features proposed are adequately utilized and facilitate the users' experience.

The only aspect requiring improvement and refinement is adaptability to mobile devices.  And the development team has already started working on such a task.

1-159
2-151
3-129
4-109
5-100
6-71
7-59
8-52
10-33
11-32
12-23
13-17
14-13
15-12
16-11
17-5
18-5
19-5
20-4
21-6
22-5
23-5
24-3
25-2
27-2
28
29
30
31-2
32-2
33
34
35
36
37
38
39
40
Do you want the same project?
Got A Project Idea? Lets Discuss It With Us
Contact Us