About Humanforce
Humanforce is a workforce management software company. Their products are used to onboard new employees, create timesheets, roster people, manage leave and availability, and export data for payroll.
Humanforce brings a whole new approach where you can simplify the process, see everything at once, and stay ahead of the curve. That’s why thousands of businesses of all sizes – hotels to hospitals, resources to recreation, stadiums to shops and more use Humanforce to get ready for the next shift.
The project
The purpose of this project was to redesign the two current timesheet sections in Humanforce Web product.
Why? We know they are clunky, there are many UX issues (such as usage of really bad patterns, inability to filter, many buttons on screen that do the same thing, etc.), and many important features are missing.
We had two options for the redesign.:
- Improve UX in the current screens, and add missing features to them;
- Completely redesign the screens, and start from scratch.
After talking to both customers and developers, I realised that the first option wouldn’t work in the long term. I found that:
- Current sections were coded using javascript – something the business stopped using years ago. All the new development was done using Angular, and there was an ongoing plan to address “tech debt”, focusing on converting old javascript sections to angular. Sooner or later, the existing timesheet sections needed to be rebuild in Angular anyway, and it made no sense to invest time and resources into improving something that will be scrapped.
- Because sections were build using javascript, we couldn’t reuse our pattern library (the library was created by me when I started for the newer screens, the old sections were created over a decade earlier without any design involvement). That meant that regardless of the UX improvements in the current screen, the experience will not be consistent with the rest of the product, and really, it will never be “solved”. The disparity in patterns alone would increase cognitive load for our users, and potentially result in more work for our customer support team. It would also keep the need for training new customers – but the goal is to make the product so intuitive that the customers wouldn’t need in-person training at all.
I have presented this argument for starting from scratch to the CPO, and he agreed. He supported my vision for the new design throughout the project.
Understanding the problem
I was very excited to lead this project. Timesheet sections are the most used for all Humanforce customers, and we could have a massive impact in making our customers’ lives easier by changing this screen.
I have previously heard “second-hand” complaints from customers about it – mostly from sales, customer support, and implementation teams – so I knew there would be a lot of low-hanging fruit and quick wins.
At the same time I was conscious that all timesheet screens are very complex, and don’t necessarily do the same thing across different products. This was an opportunity to make something very complex into something relatively simple, and help Humanforce as an organisation to step into the future.
Before I could get started on the redesign itself, I needed to have a very good understanding about our current products. I knew Humanforce Web very well – this is the product I was improving from the first day at the company. However, Humanforce also had legacy software – Back Office – and by the time I started they wanted to retire this product altogether. Therefore, there was no design work done on it, and minimum development (only critical fixes). Because of it, I was unfamiliar with what it currently can do, and how our customers use it.
I did know that it’s very complex and has many more features than Humanforce Web, which is exactly why our customers continued using it and why Humanforce couldn’t remove it altogether.
To get started, I mapped out a high-level view of screens and their background:
Next step was understanding where we wanted to be as a result of this redesign. What are the business goals we are trying to address here, and how will we know we are there? In other words, I needed to create our design strategy.
Strategy
Every successful Product Design starts with strategy. While it sounds complicated, in reality it means answering four simple questions.
Working together with Chief Product Officer, I defined the design strategy for this project as follows:
What are we trying to do?
We are combining two existing screens in Humanforce into one, adding missing features (both those that exist in Back Office and those that we don’t currently offer anywhere), and improving user experience along the way.
Who are we doing it for?
Our users are line managers, team leads, rostering managers, and payroll officers – in short, everyone in our customer’s business who needs to approve timesheets.
How do we define success?
In the short term, we want to see 10 of our customers use the new screen instead of the two existing ones. In the long term, we want our customers to stop using Back Office for anything timesheet-related, and use Humanforce Web instead.
How will we measure it?
We will be able to track usage of screens in Amplitude and see if more and more customers are opting in to use the new section.
Research
Feature mapping
The first step was to understand all the features in the existing sections, and how they are used by our customers. I did that by documenting all the features that exist across both Humanforce Web and Humanforce Back Office.
Next, I spoke to Sales and Implementation Consultants to find out if there are any other features that customers need but we don’t currently offer. There were quite a few of those, and I added them to the grid as well. Regardless of whether they were going to be part of MVP, they were worth investigating further, especially since customers from different industry verticals were requesting the same features.
The list of all the features ended up being quite long, and took some time to compile. It was further complicated by access level permissions – depending on the industry and the type of user, some of these features were not available. At this point, however, I have included them all, deciding to tackle access level permissions later, when I had workable design.
Research
User groups
Because different types of users needed different functionality and followed a different process, I have broadly grouped them into three groups. This grouping was based on what we knew about the customers. Later, when I was validating ideas and testing designs, it was remarkable how consistent these groups were across different industry vertiicals.
Line managers
People in this group have very restricted access to information and functionality. In most cases, they can only see their tram, and are able to approve timesheets one day at a time.
Rostering managers
This user group can usually see multiple teams. They also have the ability to see timesheets for a range of dates, instead of one day at a time.
Superusers
The most demanding group of them all. People in this group usually work as payroll officers and need to follow a very specific process when checking timesheets.
Research
User Flows
Now that I had the list of all features, I understood the full scale and complexity of the project. Many of the features were forming their own flows, and these flows were forming larger flows of accomplishing bigger goal. In order to understand how to optimise new design, I needed to understand what was the process for our customers right now.
Design
First version of design
After understanding all the features, I proceeded to create the first iteration of designs. Because it was for an existing product, I was able to use existing components, and work on wireframes digitally. This also ensured that the new designs were consistent with the product.
One thing I had to keep in mind: timesheet section is very data-heavy. While the conventional design wisdom dictates that we must introduce a lot of white space, after talking to our customers I knew that it would make their experience worse. Because of the nature of what they do with timesheets, they want to see as much data on screen as possible. My challenge was to display all of that data, but still making it easy to manipulate.
There were many things that by this point I knew we need to display in the new design – such as all the timesheet details, as that was consistent across all products. But at the same time I had several ideas that were not implemented anywhere, and I was really curious to test them out.
User feedback
Our customers were really excited to see the new design – as they has many problems using existing functionality. As the result, I got a lot of feedback on the first version. It confirmed that while the general direction of the new design was right, there was still a lot of fine-tuning left.
Below is the most interesting feedback that came after the round of user testing:
Design:
Feedback:
Keeping tabs to allow users to see different types of timesheets
While experienced Humanforce Users were used to tabs (as they are used in Daily Authorisation), new users really struggled with this interaction. Both experienced and new users found it somewhat clunky.
Allowing users to group timesheets per employee, per time period
This was a really popular addition, but many customers were asking if they can instead group all timesheets by start date instead of by employee.
Ability to select pay company
This was a very popular feature for Superusers, particularly among larger clients who had multiple pay companies. However, they also wanted the ability to select pay periods. In this version, they did have the ability to select dates from the calendar picker, but during testing they couldn’t remember the exact dates for past pay periods and had to look them up in the system.
Ability to create, save, and flick through layouts
This was a bit of a failure. While it sounded good in theory, in reality none of the users wanted to use this. When asked to follow through, it made their current process more difficult than ever. This was definitely something we should not pursue in the next iteration.
Design
Second version of design
After getting feedback from customers on the initial design, I set to making changes and adding missing features.
The tabs that caused so much confusion in the first round were replaced by dropdown menu with options. Layouts were gone and instead replaced by more sophisticated filters. Ability to select pay company was complimented with selection of pay periods, and now users had the ability to group timesheets by employee, start date, base roster, or to skip grouping altogether.
With updated design, I went to do another round of testing. For this round, we had all of the participants from round one, plus several new participants.
User feedback
Overall feedback was very positive – the changes from round 1 were very well received. But now customers were asking for other features, that didn’t come up in the first round of testing.
Below are the most important bits of feedback from this iteration:
Design:
Feedback:
Replacing tabs with dropdown menu
I wasn’t sure if this will make it easier to use, as now the information is hidden in the dropdown. However, to my surprise, all participants had no issues using the dropdown (compared to tabs previously).
Ability to group by employee, start date, base roster, and no grouping
Different ways of grouping were popular in different industry verticals. Events clients were delighted by the ability to group by base roster, but customers from other industries don’t use base rosters, so they wouldn’t be using it to group timesheets.
Ability to select which columns to display in the main screen
Ability to customise view made some of our customers very happy. Particularly after they learned that their settings will be automatically saved per user, so that next time they log in, they will see the same view.
However, people wanted to see more options for columns – we were still missing quite a few in the design. They also wanted to customise how many and which action buttons they would see against each employee.
Additional requests
At this most most of the participants were asking if there was an option to delete timesheets in bulk. While it would be rarely used, on those occasions it would save users a lot of time, instead of deleting timesheets one by one.
Design
Many iterations later...
As part of the design process, I did many more iterations of design and user testing. All of which led to the final design.
Creating design based on what our customers are doing, and how we can make their job easier, led to many UX improvements for existing features, not all of them obvious.
Popular features
Throughout the process of iterating design and doing user testing, I have identified many features that were missing from the current products. Including them into design made our customers really excited about the release of new timesheet section. Below are some of the most popular features I designed:
Filters
Ability to filter not only by the standard Location, Department, Role, and Area, but also a simple way to see everyone who is reporting to the manager.
Status
Ability to use dropdown when reviewing all timesheets with a particular status. Counts display how many will be in each group.
Screen settings
Ability to filter not only by the standard Location, Department, Role, and Area, but also a simple way to see everyone who is reporting to the manager.
Timesheet grouping
Ability to review timesheets individually or drill into groups by Employee, Start Date, or Base Roster.
Actions
Ability to easily access all the actions needed to process timesheets all in one place.
Alerts
Ability to see and easily cycle through alerts.
MVP and consequent releases
Since not all of the features were included in the MVP, we made a decision to keep existing timesheet sections as well as the new design. That way if an important feature was missing from the new section, our customers still had the option to use old sections.
It would also allow us to see if after the release to everyone customers were discovering and using new section unprompted.
The MVP was released in September 2020, and since then we have been continuously adding missing features. As of May 2021, 84% of all features have been released. Once all work is completed, the old screens (daily and period authorisation) will be removed from the product.
Early Adopters
After understanding all the features, I proceeded to create the first iteration of designs. Because it was for an existing product, I was able to use existing components, and work on wireframes digitally. This also ensured that the new designs were consistent with the product.
Rollout and results
Since not all of the features were included in the MVP, we made a decision to keep existing timesheet sections as well as the new design. That way if an important feature was missing from the new section, our customers still had the option to use old sections.
The new timesheets section was released in September 2020. Since then it has been consistently growing in use. What we’ve seen is as we keep adding missing features, the uptake increases accordingly.
The feedback from customers has been really positive – in some cases allowing them to transition to Humanforce Web use, and keeping Back Office for payroll processing only.
