Well, we are busy building our latest web app project, and this particular one is interesting in that it has clearly demonstrated how this niche target industry has changed in the last decade.
Backstory: We design an HR management app call HR Partner a long time ago in 2004. Back then, it was a Windows based app, and was tied in very specifically to a particular legacy payroll system. We did very well out of that application, but lack of support from the legacy payroll vendor and other reasons meant that we let that project slowly die on the vine.
However, we have had a solid core of users still using that system to this day, and who keep asking us when we are going to update it and add more to it.
Well, that lead me to decide to take up the mantle again, but this time, we are doing it differently. While the core of the product will be similar, we will now be (a) building it as a purely web based application, rather than Windows, and (b) we will not be locking it into one vendor, but instead be able to integrate with several other more modern payroll systems out there.
In talking to existing users though, one point that I had never considered became more apparent.
Back in 2004, it was quite normal for most medium to large companies to have an internal HR manager on the staff. Quite frequently, the Payroll manager also acted as the HR manager, instead of having a complete separation of duties. In any case, it was really easy to just have internal team members working on their own isolated HR system, and everyone seemed happy.
However, the current batch of users that we have been talking to are painting a completely different picture. Nowadays, it seems that more and more of the HR work is being outsourced to external consultants who are not attached directly to the company.
When we spoke to some of these consultants, they in turn gave us a look at their typical work patterns; which was to provide services to multiple companies, either in the same or totally different fields. They explained that a lot of the times, internal staff and managers wanted to have complete control of the data, but they would look to external agencies to analyse that data and tell them how they could actually make better use of it.
This threw our design specs off kilter a bit. In all our other web apps, building the sign on and authentication systems was easy. You had one company, that all the data belonged to. And within that company, you have one or more users who could create accounts directly attached to that company so they could work on the data. If a user wanted to do work on another company, they would have to create a new sign on account for the other company to do work there.
We looked at our audience, and figured that this old method would not work. The considerations we had were:
- We would have users that would still want to only work on their own company, and are not interested in working in others, and
- We would have users who would not 'belong' to any one specific company, but instead would be working on several and jumping back and forth on a regular basis.
Trying to cover all these bases proved to be quite tricky. There were a lot of edge cases where we were not sure that things would flow well. Maintaining security and privacy in this industry is quite critical, but at the same time, we didn't want that to put up too many roadblocks to people onboarding and using the system.
What we decided to do was to divorce the user authentication system from the company database system.
How it works is - Users could still sign on and create a new company. They would then become the 'owners' of that company.
Other users could then apply to be invited to a company. The company owners would have to approve them joining up. Other users could apply to join multiple companies if they liked, and use a single sign on to interact with all the companies they belong to.
I know this is not new ground, and that plenty of other systems utilise this methodology, but it was a new thing for us to tackle in our own design and development work.
Technologically, it was quite simple to manage. What really had us stuck was the UX factors. We wanted to make the process as easy and seamless as possible. As I mentioned, I was surprised at the number of edge cases we came across with this new paradigm. Problems that we had to think through were:
1. The new user conundrum
What happens when a completely new user wants to join a company? Should we make them go through the whole process to set up their account details first, verify their account, then shoot a request to the company to see if they will be allowed to join?
Our answer to this one was NO. We would simply collect their name and email address on the request form and send it to the company admin. IF the company admin approved them joining, then we would quietly create their account in our system using this information, and send the invitee an email asking them to click a link to set a password on their newly created account and log in straight away.
BONUS - As part of the '2 click' approval steps the company admin has to do, they are presented with a screen where they can customise the security parameters for the applicant. They can, for instance, opt to lock the new applicant out of certain sensitive screens or prevent them from editing employee information etc. That way, when the applicant first logs in, they are already preconfigured for what they are allowed/not allowed to see.
2. The old user failing to remember
To enable quicker sign ons, we give every company on HR Partner their own custom sign on URL link. The problem with a consultant who signs on to a dozen companies is remembering these links.
To solve this, we make it easy from the sign on screen for the user to get an email from us listing all the companies that they have been approved to work with, and a 'one click' sign on link for each company. No need for them to write it down or save it. If they move to another machine (or mobile device) without the bookmarks, they can easily get another list sent to them within seconds.
BONUS - The user does not have to remember different passwords. Just the URL, which is actually just the subdomain of the company, in the form of [company id].hrpartner.io/user/login
3. Dealing with bad users
One problem we are still working on is - what do we do with users who are removed from a company because of bad behaviour? Say someone did something naughty in Company A, and were booted out by the admin. Do we then have an obligation to tell Company B and C (if the user is authorised to use those companies as well)?
At this stage, we don't collect any information as to WHY the user was dissociated from a company. We simply let the admin 'deauthorise' them. Perhaps later we can collect reasons, and look at a process for vetting out problematic users to protect all our customers.
4. Handing over admin control
At present, we allocate the first company who created a company as the site administrator, who is responsible for approving new users who want to join. We have not yet built in a mechanism for handing over control of a company to another user, but given the transient nature of so many people's jobs these days, I am thinking this is something we will have to do.
Once again, this will have to be carefully managed, as the company admin is essentially 'god', with many powers over the data and privacy of information. We will have to build in safety checks with respect to the handover, but once again without affecting the UX negatively.
I would appreciate some feedback from anyone else out there who has tackled these sorts of issues in the past, or who could offer some tips and suggestions as to how we handle further development. I intend to post a few more posts like this as we come across design issues on HR Partner. Hopefully it will prove useful to the design and development community.
