In a small company, it’s easy to manage 5 employees, their leaves, benefits and training programmes. In a larger organization however, it is becomes impossible to maintain a good overview of how employees are doing as a whole. Larger organizations manages training programmes for different disciplines and recruiting processes. So they implement this information system to support their employees. Employees hated this systems, not the fault of human resources, but largely because these systems are often cumbersome and inpersonal.
The leave application system user interface
In a Singapore company I worked for, the old system to apply for leave involves printing out leave forms, writing the amount of days you want to apply and getting them signed. We moved to a new system using a bespoke web application that basically looks like that:
There are many things wrong with this user interface (UI):
- You are allowed to choose a from date that is after the to date. You get an angry error only after submission.
- You are allowed to apply a leave for, say, Monday to Tuesday, with Monday Morning and Tuesday Afternoon selected. That counts as 1 day of leave and meant you have to work on Monday afternoon and Tuesday Morning. This is just too complicated.
- There are many Leave Types but really 99% of the time, just quoting numbers from thin air, people only use Annual and Medical leaves.
- Stand In is bolded for no apparent reasons. Users think it is a required field. It isn’t.
- The required fields is not just Leave Type as suggested by the asterisk. From and To dates are required too.
The user experience and UI is just full of bad I could go on and on. My major gripe on the UI is that is not one that a new user can know how to use in a couple of seconds despite leave being rather straightforward. It needs user to guess the intent of the system. What does it mean “Stand In”, for example.
After the user apply for the leave, the system sends an email to the approval where the leave approval, who typically is the direct superior and/or the HR, then signs in to the human resource management system (HRMS) to approve the leave. This workflow has several issues (some technical):
- Emails do not get delivered successfully all the time. And even when it does some superiors claimed to have not received them as an excuse for not approving their subordinate’s leave in time. There isn’t proper accountability; we do not have a system to monitor email delivery and to redeliver should it fail.
- Users who received the email outside of the company network cannot access the HRMS as it is part of local intranet. They understand it, but since the email has been marked as read in their email clients (Thunderbird), some forget to access the HRMS to approve leaves when they get back in their offices.
- Approvers prefer to approve multiple leaves at one go so they hold back. This causes some employees to wait longer than the old paper method where they just walk to their approvers to get the signatures.People dislike the new system as it is seemingly slower. Some approvers wait to consolidate leaves for too long and forgot about it. There are no email reminders.
- Some approvers forgot to approve before their subordinates went on leave. This creates a problem for the HR department.
These are just some of the many scenarios I heard from people. Now for the embarrassing part — my team is responsible for the aforementioned system.
Why is it this way?
In the development stages, we have two HR managers, one programmer and a IT project manager. This is an internal company project. I sat the meetings when I was new and sat through this as a observer.
Most of the meetings went on this way:
- HR requests for a feature, for example, employees can apply leave.
- IT project manager says okay and creates/updates a list of deliverables for the programmer.
- Programmer tries to clarify with IT project manager and HR.
- And it goes to Step 2 and iterates.
Eventually a list is finalized and the targeted date of completion is proposed. The task list is agreed upon by involved parties and they will all receive an email on that. The programmer goes back and fulfills the tasks sits in the next meeting.
What gets produced is everything but what the HR managers imagined. What went wrong:
- HR managers have preconceptions of how a leave application system must encompass. The project manager and the programmer never used one from the perspective of HR and imagined how it would look like for the administration UI. The programmer also haven’t seen an HRMS before.
- Programmer uses scaffolding to quickly achieve what is on the list. The checklist isn’t comprehensive enough, validation tends to be forgotten.
- There lacks a designer and the programmer is has limited experience with HTML, CSS and usability.
- Project manager is preoccupied with other tasks and did not discover issues till it is too late.
- HR managers are not typical users for the leave system. They understand the domain well enough to know what the terms means. A small focus group might work better here.
- Project manager emphasized on functionality over design, presuming that design can be improved over time. That did not happen as everyone just moves on.
At the next meeting there is often a huge disconnect in expectations of the various parties. It is a case where the checklist is all fulfilled but everyone’s not pleased.
- You get HR managers not seeing what they want but they fail to communicate what went wrong. Also HR thinks validation and business logic is easily understood and there is not need to specify such things in the task list; programmer disagrees.
- The project manager got frustrated that there is so much change requests from the HR.
- The programmer is unwilling to refactor and simply add new components to suit the needs without removing redundant code. The system becomes quite “patchy” after a month of development. The codebase is a huge mess but the programmer works alone and there is no one who will validate the code.
These issues get reflected on the whole application. Failure to communicate led to poorly designed components; the frustration in the committee is largely responsible for the uninspiring UI; the messy codebase later haunts the programmer who takes longer time maintaining the system.
Fast forward one year later, these issues still persist. The web developer left the company. I left the company too. There now is a team of two web programmers and they are assigned to work on another application. The leave application needed attention but there is little incentive to look into it.