design

Designers, please stop doing this...

Spotted this thread on Twitter today, these are the thoughts of a designer, retweeted by another designer I follow:

Morse_1.png
Morse_2.png
Morse_3.png

Given the pithy responses to the original tweet, I will give the designer the benefit of the doubt that he was just yanking everyone’s chain with this thread, but I have seen designers who post stuff like this without irony.

To those that do this - Just. Stop. Please.

I applaud that you perceive that there may be a problem with something you see in the universe, and that you think it could be better. But before putting your critique’s hat on, please take the time to become more familiar with the domain of the thing/concept that you are critiquing.

To cover the above scenario: I used to be a pilot, and had to learn morse code as part of my studies to obtain my license. I initially thought the same as above - what a confusing jumble this seems. But guess what? When I actually started to USE morse code, I realised what an incredibly efficient method of communication it is. The series of dots and dashes are not seemingly random, as pointed out by one of the replies above, rather they reflect the frequency of usage (‘E’ is the most commonly used letter in the English language, and is denoted by a single dot), and are also designed to prevent ambiguity of similar sounding letters.

To suggest that the series of dots and dashes are dependent on the ‘numerical position within the set’ is flawed thinking. Quick - who can tell me the 16th letter of the alphabet? The 11th? As you can see - this is a pointless strategy.

(On the other hand, morse depiction of NUMBERS uses a flowing pattern system that is logical and consistent).

I was blocked on Twitter last year by a certain ‘high profile’ designer who is considered a darling of the Twitter Design community. She raised questions about something that is commonly used in the aviation industry, and when I (politely) pointed out the flaws in her thinking, based on my actual real world knowledge of the topic, she immediately Tweet shamed me and blocked me to prevent any further discussion on the subject.

This was quite an arrogant and myopic stance to take, and I hope that she is still not considered a role model for new up and coming designers in the field. (Note that she raised questions, but like the above example, didn’t actually use her designer expertise to come up with any sort of solution for the problem).

I know plenty of great designers. Some of them have even worked on my own creations and made them better than I could have ever envisaged.

Questioning something is perfectly valid. But before you voice your opinions on a particular facet of the existing design, please take the time to study the history and immerse yourself in the context of that design, and ask yourself WHY it is as it is currently? There are always forces that hold things in place, and sometimes those forces exist for a good reason, and shouldn’t be bent or altered unless your way forward is significantly better.

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.