Don't change that menu

We are rolling along with Part 5 of my blog series that I am writing while building our latest web app HR Partner.  The earlier posts can be found on this site, and I will shortly put together an index page, so all the posts can eventually be cross referenced in the one place.

Today is a short post, and it is to do with a tiny design decision that we made today.

Clutter, specifically screen clutter, is a pet peeve of mine.  I dislike having more than is necessary on my app screens.  This must be a habit going back to my flying days.  Most aircraft cockpits have been designed by ergonomic and efficiency engineers to make the capturing of information as easy as possible.  Under IFR (instrument flight rules), the pilot has to minimise moving his whole head to avoid disorientation that can occur with no external frame of reference.

I try to always abide by these rules when designing my interfaces.  No extra clutter that will distract.  On the left hand side of the HR Partner page, is a menu showing the different HR 'modules' that the user can work with, i.e. Employee Training, Document Attachments, Absence Details, Assets on Loan etc.

I wanted to have the module menu so that whenever the user clicked on a module, it would disappear from the menu.  After all, if you were in the 'Absence' area, it would make no sense to have the 'Absence' menu option still available to click, was there?  It was another line in an already long list.  Removing it would make the list shorter and easier to scan for the user.

Or so I thought.

The module menu in question, on the left.

It turned out, that having the module list change (even subtly) via the removal of a single line tended to throw our test users off.  It turns out that most users will subconsciously memorise the placement of menus and clickable areas on the screen - even if they scroll up and down!  They tended to keep a mental map of where everything was, and had already calculated the minimum distances required to reach those spots.

Moving them by one line or so tended to throw out their entire frame of reference and result in confusion and pauses when trying to find where they wanted to go.

In the end, we decided to leave the module list exactly 'as is'.  I would appreciate any thought anyone out there might have on this.  Also, if you have any scientific research that would back up my theory about users mapping the screen layout subconciously, I would appreciate a heads up.

Making deletion non-automatic

This is now part four of my ongoing blog posts on writing our latest web app HR Partner.  Parts one, two and three are here.

One of the things that we have realised from previous web apps we have written, is that the process of deleting critical data is almost automatic for most of our users.  Even putting the usual "stop and confirm" dialog box in front of them to make the absolutely sure they want to delete a piece of data becomes an automated response after doing it a few times.

For minor data like lookup files etc., this is not really a problem.  However, in HR Partner, the most critical data we have is the employees themselves.  We wanted to make the process of deleting an employee a tad difficult - to be absolutely sure that they could not do it accidentally.

To this end, we came up with the idea of the user having to type in a short deletion code, very similar to a Captcha code, each time they wanted to delete an employee.  Thankfully deleting employees is not a task done regularly, so we hope that the added thinking and stopgaps involved will not irritate users too much, but instead that they may be grateful for it.

When generating these codes, we also discovered that users could easily get confused between the letter O and the number 0 etc., so we decided to 'borrow' an algorithm that we spotted on StackOverflow to generate a non confusing code.  There should not be any guessing between the characters.  Here is the short helper code to generate the deletion code:

def generate_activation_code(size = 6)
  charset = %w{ 2 3 4 6 7 9 A C D E F G H J K M N P Q R T V W X Y Z}
  (0...size).map{ charset.to_a[rand(charset.size)] }.join
end

Have we gone overboard with this?  Would love to hear from other programmers and designers out there as to what you think about our approach.

Making user onboarding a smooth and pleasurable experience

This is part three of my regular blog posts describing the building of our new web app product, HR Partner.  Previous posts are available here and here.

In part one, I explained about the sign on methodology used - more specifically, how we would separate the user authentication system from the company databases.  This was to facilitate one user being able to work across multiple companies easily.

This workflow also meant that is user Bob wanted to work with company Acme Industries, then Bob would have to request an invitation to join Acme Industries as a user.  To do this, Bob simply clicks a link on the login screen and fills out his name and email address.

This information is then sent to the Acme Industries company admin user.  They can then log in to HR Partner and in 2 clicks, approve Bob's application to join (or ignore it).

In our early Alpha testing, whenever the company admin approved a user's request, the requesting user (Bob in this case) would automatically have an account created for him, and be sent back a generic congratulatory email telling them that they could now log into the system and begin working with Acme Industries.

But wait - we have an edge case here that needs to be looked at more closely.

We have to consider whether Bob is a brand new user to the HR Partner ecosystem, or whether he has been around for a while and already has an active logon account.

If he already has an account, then he does not need to do anything more than to click on the custom company HR Partner URL to log in immediately.

If he is a NEW user, then his account would have been created automatically when he was approved, and now he has to create his password before he can log in.

TWO distinct paths of action, depending on their initial status.  However, our initial version of the invitation process had only ONE generic email back to the invitee, asking him or her to either login or go through the password reset process.

Actually, to be honest, the initial version was clunkier than that.  We actually sent back the congratulatory email, and added a proviso that if they were a new user, they were to expect a SECOND email shortly with the password reset instructions, upon which we would generate and send them a password reset email (the same password resent email as if the user had asked for one on the site).

I thought that it was ridiculous - getting one, sometimes two emails back from us depending on their status.  I resolved to make this easier by only sending back ONE email to the user, and changing the content according to their initial status.

So now, the user gets back a nice congratulatory email, and within the email, they are EITHER shown a link to the company sign up page, OR they are given a link to the password reset page (our app now generates the password reset token before sending then the email, if they are a new user).

User already has an account with HR Partner and was approved to join a company.

User is new and has had their account auto created.

The end result is much less email clutter, and (hopefully) less confusion for the end user as part of his or her onboarding process.

NB: Upon further consideration, we are now working on the change password screen a little more too.  We want to customise this screen a little more so that when the app detects that it is a new user changing their password for the first time, that it shows up a little welcome message in there too - just to make the screen a little more friendly than the usual stark password reset form.

Normal password reset screen.

Password setup screen for new users.

Both the above screen are actually exactly the same - it is just the wording that has been changed depending on the context - whether they are a brand new user, or an existing user wanting a reset.

Reducing 'browser detritus'

In part two of my notes and observations about designing our new web app, HR Partner, (part one here) I would like to talk about 'browser detritus'.  What is it?  Well, consider the following scenario.

In most web apps, if you forget your password, there is usually a handy little button or link on the login page somewhere that the user can click.  Usually, this will present him or her with a simple form where they enter their username or email address, and a password reset email will be sent to them post haste.

It is what happens after this that concerns me.  You see, in nearly all cases, the user is sent back to the original login form, along with some sort of notice to check their email for further instructions on resetting their password.

Now, most users would then either switch tabs or apps to their favourite email client, and check their email.  Naturally, most of these reset emails have a special link to click on which will ask the user to reset their password.

But...

Clicking on this link always, always, always opens up a NEW browser window with the reset form on it.  Meaning that the old login screen is still sitting, waiting, in the back there somewhere - now lost among a sea of browser tabs (in MY case, those tabs are spread across 3 different browsers usually).

Invariably, after going through this scenario myself, I will go to do some 'tab housekeeping' at the end of the day, and I will come across sign on screens still waiting for me like a faithful puppy at a train station.  Some days I cannot remember if I indeed reset that password yet, or if it was still something I had to do?

But look - I am as guilty as the next programmer/designer.  Our own web apps to date follow this same paradigm.

I decided to change that with HR Partner though.

At the risk of incurring the wrath of UX specialists everywhere, I actually introduced 'dead ends' in our web app sign on procedure.  When you tell HR Partner that you have lost your password, you will still get that form asking for your email address, but then, you will see a screen that tells you to check your email, and nothing else.  The screen does not even link back to any other screens in HR Partner, but instead asks you to close that browser window down now.

Our normal sign on screen - Whoops, I have forgotten my password.  No problems, click on the link...

This is easy - I'll just type in my email address here...

Aaaand - dead end! No going back, no going forward. Just close the browser window and wait to open another one automatically when you get the email...

Is this too regimented? I think it is a step towards avoiding tabmageddon myself.  We are still in development with our web app, so might change this later, but for now, we have introduced these dead ends in a few spots during the onboarding process, including:

1. When the user asks for a password reset. [We have a password reset link in the email]

2. When the user asks for a reminder email with their company specific sign on link. [We have links in the email which take them straight to their required company link]

3. When the user reaches out to a company admin to be invited to join an existing HR Partner company. [We have to wait for the request to be approved by an admin, after which an email will be sent out with a link to complete their sign on process]

I must admit that deliberately designing this many 'dead ends' in an app made me pause at first, but I think at the end of the day it might be a good thing for the end user experience.  What are you thoughts?