Menu Zamknij
Leave Scheduler

An app that improves leave
scheduling in enterprises.

Leave Scheduler

An app that improves leave planning in enterprises.


Please note

The project was designed for Polish users, therefore wireframes are in Polish.

My role

  • Working in a team with the product owner, business analyst and developers.
  • Conducting research and designing the final product.


Problems to solve

  • Complicated and different process of scheduling leaves in many companies.
  • Additional effort for the manager in the reconciliation of employees leave (especially in large factories).

Who are we designing for?

The Manager - most often has higher education. Efficiently uses applications regardless of the device. Uses more advanced programs to generate statements and work on data sets. Can create statements in Excel sheets for this purpose.

The Employees - mainly production line workers, between 18 and 59 (women) or 64 (men) years old. Some of them prefer paper solutions, some use "kiosk" devices located in the hall, and the younger part would like to use the application on their phones.

Depending on the organization, the process may also be attended by a person accepting or checking leave schedules - Director or an employee of the HR department.

Different interface design for manager and employee (final app, screens in Polish).

Desk Research

Getting to already existing information speeded up the research process. Knowing tips for the Managers on how to schedule employee leave made further conversations more detailed. When the team knew the basic issues of leave scheduling in companies, and how Polish Labor Law defines it, we started digging for more specific and complex information.

Competitor Analysis

The analysis covered direct and indirect competition. In addition to the interesting functionalities of competing applications, the analysis also covered their business model. I noted other apps features that seemed confusing/redundant from our point of view, and how the user is guided when leave scheduling is a part of a larger system. This gave us a picture of how our project can fit into already existing solutions.

Leave scheduling is a terribly disliked topic - nobody wants to create an app that will handle it.
Alex, Manager in a production company

In-depth Interviews (IDI)

The interviews were semi-structured. We interviewed 11 participants (6 managers and 5 employees). Questions were based on the general research questions:

  • What do managers pay attention to when checking employees' leave schedules?
  • How do managers and employees help each other when they have to schedule leave - what applications are they currently using?
  • How do managers remind employees of the need to schedule leaves?
  • How do managers motivate employees?
  • What unpleasant situations occurred when leaves were scheduled?
  • What is the context for planning and checking leave plans?
  • What if there is a conflict between employees' leave schedules?
  • What is most important when employees plan their leaves?

Process Mapping

To map the general process I needed to combine processes from different companies and find their common features.

General scheme of the leave scheduling process.

User Stories

I used User Stories to organize the information and needs collected in the research. Thanks to User Stories, the research results became more accessible to the entire team and were easier to modify. By specifying the target user at the beginning of each sentence ("As [user], I want to ..."), each team member could empathize with the appropriate role, and in case of doubt, ask the appropriate people for the details of the identified needs.

At this stage, we identify a few user needs that would be too costly to implement - those have been postponed for further development.

In the later stages of the project, user stories will be used to check what stage of the work we are at and whether everything has been done.


Redesigning The Process

I started creating a new process by analyzing the current one. The main observation was, that in every company the process was iterative. With that in mind, my team and I started to design a more efficient process, without harming current regulations of our future clients.

Final leave scheduling process in the application.


The next step was to make an interactive low-fidelity prototype in Axure RP. Thanks to the simple form, the team could focus on more general elements, and each correction was added quickly, which did not generate additional project costs.

According to previous research, the manager mainly uses desktop applications and very rarely uses mobile solutions for business purposes - the desktop interface was designed in the first place.

The employee does not have any device provided by the employer. The most convenient is a smartphone or a public device provided in production halls in some companies. However, when planning a leave, we are dealing with planning employee's free time. In order to plan free time, the employee compares various data, mainly on the desktop (calendar, holiday offers, family plans), so for the employee, I designed desktop and mobile prototype.

I focused on specific user paths, which I wanted to test or share, so not every element in the prototype is interactive.

» See prototype (Axure Share)

Modal with options to begin scheduling leave for employees (screen in Polish).

Usability Testing

After the prototype was finished, we asked interviewees to take part in usability testing. I prepared separate scenarios for Manager and Employee.

The usability test was recorded with the consent of the participant. The conclusions were classified according to the significance and frequency of occurrence. After they were fixed, another series of tests took place. We conducted 3 series of usability testing - 5 tests in each.

Graphic Design

By creating graphic designs for developers, I created elements that were missing in the prototype design. To handoff designs, I used Sketch app and Zeplin.

Desktop screen with month view for the Manager (screen in Polish).



At the coding stage, I participated on an ongoing basis in clarifying Developers' doubts. Of course, it was not possible to predict all the branches of the interface elements in earlier stages, so we defined the details of the solution on an ongoing basis together with the team.

Receiving The Application

When the coding was over, I started reporting elements that weren't styled as in provided graphic designs. I also provided instructions on how to fix them. A team of testers started their work in parallel to test the functionality of the new application.

The verification with user stories made it possible to confirm whether the application contains previously selected functions that will meet the users' needs.

Application Release

The application has been released. The user feedback was positive. Reported and found bugs were fixed on an ongoing basis. Except analyzing feedback from users, we were also looking forward to design features, that were not included in the first version of the app.

Mobile screens for employee (screens in Polish).


While working on this project, I had to face a lot of data as well as many limitations resulting from the Polish Labor Law or the variety of leave scheduling in various companies.

The initial simple idea of the application turned into a more advanced tool for the manager while maintaining a simple (with fewer features) interface for the employee.

Working in an interdisciplinary team allowed me to control the project from different perspectives. This allowed me to gain more knowledge about designing and developing an application.

Adam Klimas
Adam Klimas
Get in touch