When your hard work becomes invisible

In my latest project, I have been working very hard on getting the UX right.  I want the interface of my web app to NOT fight the user every step of the way, and to make some semi-intelligent guesses as to what they want to do.  Wherever part of the interface looks clickable, I want the user to be able to click on it and get the result they expected.

That sort of precognition takes hard work - LOTS of hard work.  Just today I spent pretty much ALL day on one small piece of functionality, that at the end of the day, my users will probably never really notice.

Come to think of it, *I* pretty much don't notice it now that it is finished, but I know it is there, and it is making my movements through my web app a lot smoother and logical.  

Just this evening I was thinking about it, and I was a little sad that all my work was essentially invisible to the end user - after all, they only usually notice things when they DON'T work.

But I was reassured by something a wise man once told me - "Character is what you do when no one is watching".  I like to think that my app has good character.

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.