People hate long questionnaires..
Ok, so that's pretty obvious really. As a user when I start filling out some kind of form, I need to have a sense of how long is this going to take. I don't really need a clock, but showing 'next/next/next' without the knowledge that there are only 3 more pages to go, is frustrating, and leads to a higher drop-off. On Hydra the simple 1.2.3.....12 at the top does that job.
The other trick is to slowly increase the complexity as users go along. The first few pages of Hydra ask quite simple questions, there are only about 5 on each page. it's not until the 10th page, that we start asking the more time consuming questions, like skills and some free text fields on experience. Our sense here, is that once someone has committed a reasonable amount of time doing the easy quicker questions, they are less inclined to just give up near the end.
Make mistakes and omissions less annoying.
Having decided that we have a multiple paged form, from experience, the next pain point is the next button that always tells you that you have done something wrong....
An early decision we made was to make sure that you can technically just complete step 1 and 10 (or basically no steps) and get to the end. This proved a good decision early on, as although we saw a low completion rate, we already had some engagement in Hydra. What tended to happen was that people came back later to complete the form.
As time went by however we realized that there we still had a significant percentage of users who never completed the form. To address this we added two features,
added a warning box on the last step, which tells the user which part they are missing
next to the steps, we added ticks to indicate that a page had been completed.
The end result of all these changes is that we get a very high completion rate (over 90% of candidates now complete 100% of the required questions).
Save the form for the user, don't ask them to save or post.
So how many drafts of this blog post did I loose because I forgot to save (well lucky none so far), but when creating a document, or using an online application, the number of hours wasted over the years must have been huge, browser crashes, or in the good old days Word crashing and loosing all that work. Most of these issues have since been solved by auto-saving, use google docs, and you don't even think to save the document. However forms these days still have a save button.
Hydra's forms are all AJAX based, so changing from one tab to the next causes a background save. This ensures that even the worst PC should not loose to much when the browser crashes.
However in some of our testing, we also discovered that not everyone's internet connection is that great. Very early on, one of the founders did a bit of testing at an airport using the free wifi. After going through a few demo's they realized that some of the data they had entered had been lost. We where shocked.. we had put in a warning that if the data did not save, we would show a dialog.
What had happened was that the user just pressed OK on the warning, not realizing what to do.. In this scenario, the classic "Do you want to install this virus" dialog box had proved to be pointless, as the users did not understand the implication of just pressing 'OK'
In the end, we had to modify the dialog to say two thing "Try again" or "Reload the page and loose data".. That way there was no chance of them loosing data without knowing about it, and trying to resolve the connection issue.
A Rich range of input elements.
Hydra is built with the
Roo Bootstrap library
, using a tool we developed called the
(yes, it needs a better name..), an advanced drag and drop Graphical User Interface builder. This enables us to re-purpose very quickly User interfaces from other applications, or even within the same form, reducing the amount of new work. It also enables us to recreate the Hydra Platform for other industries very quickly, altering the set of questions and search criteria for the Recruiters.
This collection of elements started off with the basic features like forms and inputs, along with layout elements. It now has started to include complex containers like masonry. So rather than creating a mishmash of jQuery elements which add random untraceable behavior to parts of the site. It's very simple to locate and modify the behavior of any element of the site.
During the creating of Hydra, we both increased the number of Bootstrap elements, and enhanced the features of the existing ones. So the library now includes things like Google Map elements, A very advanced combo selector (for single, multiple selection, along with searching lists). An enhanced paging tab element, which can also be used as a slideshow.
As we monitored usage of the Platform, we also realized that users often could not easily spot which form element was required and completed correctly. So we added visual hints on inputs to show when the input was completed correctly or was invalid. All this was done to the core
Roo bootstrap library
, so just by adding a few extra boolean properties to an input it would dynamically include a visual feedback.
Date input's where an area where we also had to get quite creative. Our initial design had used a classic date picker. It turns out these types of date pickers you see on airline websites, or dumb forms are very useful for picking a date in the recent past or near future (next month or previous month). but are very klunky when you have to pick a date from a few years ago, or for some off us old farts it's a nightmare finding our birthday.... Which is why we opted for a 3 part day/month/year entry for some of the input.
Monitor it and change it.
, It's a tool that you can add to your website to basically spy on your users.
A lot of the work we have done in the past is for intranet or SME in-house applications, we are pretty good at this, having gone through the development cycle of quite a few projects, we have a pretty good knowledge about how users expect interfaces to work.
At various points of our projects, we end up sitting down with the users and watching how they use the product. This normally results in quite a few changes, as the 'theoretical' user that you normally design for, somehow never ends up looking like the real one. (in less polite terms this is sometimes referred to as "there is always a better idiot out there".). Things that you though where obvious turn out to be real pain points where users spend ages looking for a button you put at the bottom right of the screen...
For an online website, finding enough users to sit down with can be quite costly and time consuming. This is where fullstory comes in.
A friend also recommended
, both do similar things, but I think fullstory has a slight edge at present as it's cleaner and easier to use.
What both enable you to do is watch a video of a users interaction with the website, you see what they saw, and watch how they moved their mouse around and clicked on buttons.
Over the months of using these tools, the changes we have made have been quite substantial, and have affected decisions we make on other projects. While we only worked with 10's of users before, studing their behaviour, we now have seen thousands of users.
Changes that we had to do covered all area's of the sites functionality, from the user sign-up flow, where we added extra buttons to suggest actions, rather than just giving confirmation. To changing how users where driven to enter their location, hydra geographically match candidates, unlike any other recruitment tool on the market. This interaction while still not perfect, is a world away from where we started.
We continue to watch huge numbers of talent joining Hydra, and now have a number of Recruiters and large companies using the tool to find staff. The feedback has been pretty amazing, people are saying that this is the best recruitment tool they have ever seen.
It has been an interesting few months getting Hydra up and going, now we are over the hump of the work,
we are looking for more interesting projects to take on, so if you know of any, please