15 Steps To Better Usability (and Happier Users)

[rvinay88]

Originally published at: http://www.sitepoint.com/making-happy-users-better-usability/

To get started, today I want to focus on new users who are getting acquainted with your website. We will look at some of the common and often-overlooked usability issues in web apps. We will also learn how we can enhance the usability during the initial stages of a user’s interaction with our web / mobile app.

Clear and concise communication

Usable font sizes

With the mobile web increasingly dominating our web usage, there has already been a shift towards bigger font sizes on most websites. Thanks to concepts like responsive web design, there has been an increase in the number of websites focusing on usable font sizes for mobile devices.

A good base font size is imperative for mobile experience. Often websites focus a lot on the usability buttons, icons, accordions, tabs and other click targets. Sometimes, they forget to focus on how important it is to have text links clickable.

Error Messages

The language and tone used in error messages can be easily overlooked as unimportant or secondary to other development items. However, lack of usability in error messages could have a direct impact on conversions.

If users are not instructed clearly about recovering from errors, you will lose business. Error messages are a great opportunity to be playful but at a minimum, we should allow the users to quickly diagnose and recover from the error.

The language used in errors should be non-technical. Do not give out information that the user does not have any use for. Validation errors can easily be rephrased to more user-friendly terms.

Compare the below with the earlier versions of the same.

Usability of forms

Go easy on password requirements. It is common practice to mandate high security passwords. This should be an encouraging experience not one that hinders or prevents people from signing up.

Usability of forms have been one of my pet peeves forever.

A lot of forms are beautifully designed to be unusable.

As discussed before, forms are and will always have a direct impact on your business. Sign up forms, login forms and checkout forms are all critical parts of any web app. Hence, the focus for usability on forms needs to be laser-sharp.

Select boxes, for instance, have historically been difficult to style. A lot of existing options including bootstrap’s dropdown or Harvest’s chosen tend to hide the original select input, clone it into a more styleable DOM element. Then bind the data on the cloned element back to the original input. That’s a whole lot of work just to get the dropdown to look beautiful. But, is it worth all the trouble? Considering how mobile users are accustomed to the native controls on their OS.

Windows mobile users are more used to being presented dropdown options as a full screen of choices as opposed to a field within the form itself. This is vastly different from what android users are accustomed to – a modal window.

Going through great lengths to undo this behavior to achieve consistency or for design purposes is counter-intuitive. It might end up slowing your users, who work on similar controls all day and expect it to behave in a certain way. This will pose more challenges than help them.

Using the right input forms

A lot of people recommend using appropriate input types for forms. Adding input[type="email"], input[type="tel"] helps by switching the keyboard input appropriately. This is counter-intuitive and actually prevents them from quickly filling out the form.

If you have a form with multiple fields it is better to stick to one input type, because it is easier for the user to be presented with the same keyboard for every input, rather than providing them with a different keyboard for every new item on the form.

The right place to use the various HTML 5 input types are when the changes are minimal. Google’s 2 factor authentication has a single form of input and this expects only numbers. This is a great place to provide the user with the number keypad.

However, in more complex forms, such as lyft’s signup as a driver form, it can be frustrating to be given a different keyboard for every different type of input. It actually increases cognitive load. Especially when switching between regular keyboard and a numeric keypad.

Give a stellar onboarding experience

Lack of good onboarding is analogous to being a rude host.

It is easy for developers to overlook how the naive user would interact with their app for the first time. A dashboard full of icons and sections isn’t exactly intuitive. Friendly tooltips and alert messages that can be dismissed help ease the onboarding process.

Continue reading this article on SitePoint

[StevieD]

While generally I agree with the article, there’s a couple of things I would add, to point out that it is rarely as simple as you would like…

Small things like defaulting the cursor to the first input field on a form can go a long way to making the experience faster and more seamless.

But only do that if you can guarantee that your form will load instantly. When I try to log into my online bank website, I frequently get enough of the page on the screen that I can click in the first field, type in my memorable word, tab to the next field and type in my passcode … except that the page hadn’t finished loading, there was still some background crap going on, so I’m half-way through typing my passcode in and the cursor jumps back to the first field and suddenly I’m typing in the wrong place and it won’t let me log in.

Checkout workflows are another good use case where chunking items into logical groups is a great way to avoid overwhelming the user. …
You want the user to think “Wow that was simple” instead of “Oh dear. This is gonna take a while”.

But by the same token, you need to provide a progress indicator. I’m a pretty patient person, the kind who tries to persevere rather than give up. But on plenty of occasions, I’ve got half-way through filling in a multi-step web form and just got so bored that I have bailed, because the form gave me no indication how far through I was. For all I know, I might have been on the last screen … or I might have been barely a quarter of the way through. If I had known I was nearly at the end, I might have stuck with it.

[alexmwalker]

@StevieD

But only do that if you can guarantee that your form will load instantly. When I try to log into my online bank website, I frequently get enough of the page on the screen that I can click in the first field, type in my memorable word, tab to the next field and type in my passcode … except that the page hadn’t finished loading, there was still some background crap going on, so I’m half-way through typing my passcode in and the cursor jumps back to the first field and suddenly I’m typing in the wrong place and it won’t let me log in.

That’s a really good point, StevieD.

I guess the real issue in that situation is the slow page load. Sometimes you can’t control when some resources arrive, but you can treat those items differently, and load them invisibly. If they’re crucial to the way the page works, then you need to find a way to deliver them quickly.

If you look at the load time, I find it’s usually some kind of third party JS library or third-party service that the page is waiting for.

[rvinay88]

@StevieD, All these pointers are guidelines for better usability. Every website requires to study their user bases. In your case, if a majority of the bank’s users face a similar problem, then it is definitely not worth auto-focusing the cursor. But the general expectation is, if there is a field right on top, save the user a click.

Regarding checkout indicators, they are usually step wizards similar to this link. They usually have numbered steps. I think that should solve the progress indication problem?

[bootle]

Very good tips, but couldn’t get my head around:

Modals are a useful pattern, but don’t modals is to make them block the user. Preventing them from proceeding further unless they respond to what is in the modal.

[rvinay88]

Woah! Looks like a typo. Will work on getting that fixed. Thanks for noticing.
What I wanted to communicate there was never block the user. Sometimes there are modals that won’t let you do anything else until you take care of them. That’s great if the use case is “save a file” because that is inevitable. But sometimes websites use that to ask people to sign up for their newsletters or create an account. Unless they part with this information, people cannot continue using the site. That is a bad pattern and should be avoided. I hope this clarifies.

[alexmwalker]

@bootle

http://www.sitepoint.com/making-happy-users-better-usability/

Oops, I missed that one in the edit. Fixed. Thanks for the headsup, @bootle.

[IanVS]

Technically, isn’t the traditional definition of a modal window one which prevents further action until dealt with?

[rvinay88]

@IanVS Technically, yes. I am glad you pointed that out. I think, the terms modal and non modal are understood better in a desktop environment. This is just my opinion, but on the web, a modal is more akin to a popup or a lightbox. Because, that’s the vocabulary used by most popular frameworks. Bootstrap calls it modal and foundation call is Reveal modal. But if we are talking semantics, you’re absolutely right. In that case, my recommendation for usability is to avoid modals. Non modals are okay. Even those I wouldn’t use too much. I hope this clarifies

[nvrau]

+1 on form drama…

Suggestion: When an address is required in a form, start with the broadest required range first.

e.g. Don’t ask the user to enter address, suburb, state, post code and then country. Start with country, post code (This will typically allow the user to skip state and possibly suburb when using a smart form) and then filter address as the user types the street name.

Just because we read addresses in the former order doesn’t mean we should enter them in the same order.

[rvinay88]

True. It looks like the current state of forms are mostly just developer convenience. And, I get that. There is so much to be improved in that space. Addresses and credit cards are similar in that fashion. We don’t have to require all the fields we currently do. Some of them can be deduced, like whether a card is visa or mastercard.

Imagine, this is where someone is giving you money out of their pocket. I’d do anything to make this process easier for the user. I want that money

[StevieD]

@nvrau

Suggestion: When an address is required in a form, start with the broadest required range first.

e.g. Don’t ask the user to enter address, suburb, state, post code and then country. Start with country, post code (This will typically allow the user to skip state and possibly suburb when using a smart form) and then filter address as the user types the street name.

Just because we read addresses in the former order doesn’t mean we should enter them in the same order.

This strikes me as one of those things that’s a bit like the “content before navigation improves accessibility” theory that was doing the rounds a few years ago. It’s one of those things that could help people, but actually probably won’t, because (in most countries that I know of, at least) people are completely habituated into writing their address along the lines of
1 Alphabet Street Town State P05T COD3
and so anything that breaks that mould is going to require more cognitive processing for them to realise that they are being asked for the information in reverse than it will save them in workstream by having the information asked for in a more streamlined and personalised way.

And the programming that would be required to get an internationally compatible form that recognises address formats in even a dozen major countries is going to be a headache.

A lot of websites in the UK that are aimed at a UK audience will ask for your postcode first, because that typically pinpoints your address to within about 50 properties, and then all you have to do is pick your house number or name off a list and you’re there, which massively reduces both the effort needed from the site user and the risk of people making a mistake when typing their address in (or the age old problem of people who insist on not using the post office’s preferred form of their address). But to generalise that to more than one country? That’s a whole lot more work. I’m not saying it can’t be done, of course it can, but you have to look at whether it is worth your while to do it.