design

Getting stuck into design

While I consider myself a ‘full stack’ developer, taking care of everything from the back end to the front end of town, one area that I tend to lack is in my design skills. I am trying to learn more about good graphic and user experience (UX) design principles, so that I can improve the software I write without having to resort to a third party expert every time.

What better way to start than with my flagship SaaS HR product, which is in use by over a thousand people all over the world? Looking at the stats on Google Analytics, I see that the most common screen used on my app is the employee Leave Request screen, which employees of our customers use to ask for time off from their managers.

While we haven’t really heard any real complaints about this screen, I knew we could make it easier for people to use, without too much effort. Here is the original screen:

Employee_Leave_Request_OLD.png

I thought the blue bordering on this screen made it look a little dated. Plus the title at the top which says “Request Leave or Time Off” seems a little disconnected from the rest of the screen. Lastly, the one bit of feedback we’ve heard from employees was that they would like to see the company leave calendar on here which was useful to them when planning time off.

So, I sat down for a morning, and reworked the screen to remove the borders, and make it look more like a plain paper leave application form:

I removed the top title as it was redundant, and removed the borders around the window. I also squashed the main form down a little to increase white space around it and make it look more like a paper form that the employees would have been used to filling out before.

I also removed a lot of extra words within the form (i.e. the help text below each field) and made them popups that would appear when the user clicked on the ‘?’ icon above each field. Just to make things cleaner and have less word clutter.

At the bottom of the screen, you can see where I have ‘squished’ the old list of leave balances down, which is still readable, and added the company leave calendar to the system.

After some initial testing, I made some finer touches for the final version:

Employee Portal Leave.png

Not much that is immediately obvious, but they did make the form seem aesthetically better. I fixed the alignment of text across the form, plus I added a background colour to the form fields themselves so they stood out a little and didn’t make the form look so washed out and overly white.

What do you think? We actually saw an uptick of activity on this form already this week since we put out the update to production, and so far no one has emailed in to complain about anything, which is a good sign IMO.

Because I am all about constant learning and improving, I would love to hear from some experienced designers out there as to how I could make things better.


Errors don't have to be boring

This is part 7 in the chronicles of building HR Partner, our latest web app.

A short one today.  I was designing the 404 and 500 error screens for our Ruby framework, and decided to go outside the box a little.

Usually, the 404 error page is a fairly boring affair, telling the user that they have tried to load an invalid page.  I thought to make it more interesting, I would incorporate an ever changing background for the error pages.

I am using a dynamic CSS background for the error pages, which links to unsplash.it to load up a random grayscale image as the background.

This way, every time that a user hits an error page, they will still get the large '404' or '500' error number, but overlaid on a different background each time.  I have no control over what image gets shown, but I find myself just hitting invalid pages every now and then during my development routine - just to see what pretty landscapes show up.

The body style tag looks something like the following:

<body class='black-bg' style='height: 100%; background:url(https://unsplash.it/g/1000/800/?random) no-repeat fixed center center;'>
  ... rest of 404 error info
</body>

So as I said - error message certainly do not have to be boring!

Don't hide the delete button

Welcome to part 6 of our series on designing HR Partner, our latest web app that is slated for release in 2016.

This episode, I'd like to go through a design consideration that I had with the file upload library module in our app.  In this module, the user can create 'categories' for their files, and upload an unlimited number of files to that category.

They also have the option to delete a category if it is not needed any more.  The problem is, we won't allow them to delete while they still have files allocated to that category.

The question was how do we deal with this restriction?  On our early Alpha version, we simply hid the delete button if there were still files within the category.  However, this gave the user no indication that they COULD delete the category, at least unless the category was already empty, in which case they would see the button.

We thought that this was counter intuitive.  We wanted the give the user an indication that they could delete, as long as they deleted the files first.

So in the second iteration, we put the delete button back, but disabled it when there were active files in the category.  This still wasn't optimal, because there was no explanation as to WHY the button was disabled.

So we went to the next level, and made the button active.  If the user presses it while there are still active files, they will get a popup telling them why they cannot yet delete.  If there are no active files, then they will see the usual delete confirmation dialog.

We hope that this method means we don't clutter the interface with too much extra text, yet still gives the user an idea of what they can and cannot do within a particular screen.


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.