Timesheets Module

Context

When conducting a round of meetings with potential clients, some features were identified that would be interesting to all users. In addition, there had been no updates to the timesheet module since its first versions. In simplified terms, the module allowed:

• Select the projects worked on during the day, assigning hours worked according to their workload.

• With these hours, it was possible to calculate the time spent per project and per employee.

• These hours were also used to calculate the salary received according to the time worked each month.

1) Problem identification

Through discovery meetings, we identified some points that our software did not cover at the time: The ability to copy and paste days worked. In other words, if the worker has a very similar routine, he or she would not be able to copy and paste easily using our solution.

Another point was the functionality to block hours entered if a project was disabled by administrators. In other words, if a project was blocked on a specific date, after that date it would not be possible to add hours worked.

Below is an image of the old version, we can notice some major problems right away:

• No visual information indicating that values ​​can be entered into cells.

• Activity inputs containing project, study and activity on the same line, making it impossible to see the names of the entities..

• Gray visuals with lots of information scattered on the screen, causing a large cognitive load for initial use.

2) Analysis of other potential improvements and prototype

In addition to the problems raised during the discovery interviews, a series of conversations were held with some users who used the module more frequently. From there, other potential points for improvement were raised through a joint analysis.

Some of the improvements included:

• Improving the hierarchy and the amount of content in each line.

• Separating projects using the same icons defined in other areas that were redesigned.

• Adding a view so that managers can see the hours worked by employees from different sectors, in a simple, visual way and on a single page.

• Limiting the minimum and maximum amount of hours worked by groups. Previously, it was only possible to define global limits for all employees in the company.

• Highlighting some features that were only visible after users used the right click, leading to the belief that it was not possible to add comments or remove old projects from the main view. This problem of removing/cleaning projects had an aggravating factor, which was the icon/label used. He suggested that the project would be suppressed with the scheduled hours, which caused fear of losing the data provided by users.

The prototyping phase was relatively simple, since the module was not extensive. The most important thing was to carry out iterations according to the feedback from internal and external users.

To do this, we created 4 problem statements that can be seen globally in the image below (it was blurred for confidentiality reasons), along with the versions created:

3) Moderated usability tests

After mapping the companies that used the timesheet module the most previously, we invited some users to participate in demo tests in a free manner, that is, without having many pre-defined questions.

The objective of these meetings was to:

• Confirm that the problems raised were being covered.

• Test which previously hidden functionalities were visible and intuitive.

• Check how users felt about the reduction in the cognitive load of the main tables.

• Validate that the new functionalities were easy to understand.

After testing with about 5-10 current and potential users, we come back with pertinent notes to iterate on the prototype before moving into the development phase.

4) Results and success metrics

After developing the new version and sending it to users, we wait about 1 month of use to be able to collect real feedback. This is the time we normally wait for the learning curve to be completed and for the user to get used to the new system, allowing us to compare it with the previous version with less bias.

For comparison purposes, here is a comparison between the old version and the new one:

We chose to use the Customer Satisfaction Score (CSAT) to obtain user feedback. In addition to the question regarding satisfaction from 1 to 5, we have included an optional field to add any positive or constructive feedback for future improvements.

After collecting the responses, 95% satisfaction was obtained regarding the new Project Browser. It can be concluded that almost all users were satisfied with the modifications.

Also due to the modifications it was possible to sign two new contracts with customers interested in our software, showing that the new implementations pleased both internal and external users.