Speed, Usability and Speed

When looking at making UX improvements to web apps, I tend to obsess about speed and performance. For me a fast experience is a good experience.

I really think that speed outweighs all other factors. If you can keep all loading and waiting times very short, ideally under a second, it keeps the user engaged and efficient in what they’re trying to achieve. As soon as anything takes longer than a couple of seconds it’s easy to let your mind wander, switch context and then take longer to get back into what you were doing. If this is happening lots of times across a lengthy session it really adds up, not to mention the frustration it causes.

Usability is obviously important too. It needs to be obvious what screen elements you can interact with – is that an underlined heading or a link? It needs to be clear what an interaction with that element will do. Unexpected behaviour makes people feel uneasy and suspicious about other potential interactions. And it’s always good if the user can see how the whole piece fits together, how you get from A to B, B to C, etc.

The usual causes of things being slow are not network issues but bad design. The most common problem is simply trying to send too much too soon. Requirements often ask for a high number of items to be displayed with a high level of detail against each. It’s always worth asking if this can be broken down to show fewer items or less detail with more being available on demand.

If a screen lists 20 items with all their details and it’s taking 5 seconds to load we still don’t have to load it all at once. Rather than the user waiting for 5 seconds, why not just load the first 3 items quickly, so the user has something to see within a more acceptable time frame (before the mind wanders), and then load the other 17 in the background while the first 3 are keeping them occupied.

Even if your app is working at acceptable speeds if you haven’t already done so you should still try to make it faster. Use a strategy for how you’re going to load new data and use the usual performance tricks – caching, bundling, minification, pre-fetching – to really give the UX a boost.

Is UX Design Really a Thing?

This might seem an odd question as user experience (UX for short) obviously has become a thing in the last few years. I think the question I’m really asking is this – isn’t UX design just design? The whole UX thing is kind of meaningless. I know, can of worms…

In any other industry things get designed but they don’t have special titles for designing for the people using the product – that’s obvious. I can’t imagine that a car designer would be called a driver experience designer. The driver having a positive experience is an inherent part of the design process.

I guess that the area of UX exists to give some separation from purely aesthetic design. It’s about making things easier to use rather than just pretty. I’ve always seen design as being both. You can’t really have one without the other.

My other UX gripe is that it’s not really a hard skill, not like development work. It’s something that anyone can do. It’s a blend of common sense, empathy, pretending to forget everything you know and a willingness to fight for what’s best for the user not the developer. When trying to come up with the best user experience for, say, a form, I feel the easiest approach is simply to build something, use it a few times, see where the pain points are, develop alternatives, repeat.

It’s true that with experience you get it right first time more often but you also get that by imitating the big guns – Amazon, Google, Facebook, BBC. These guys know what they’re doing and have usually done the thinking for us.

 

Displaying Options in a UI

One of my pet hates in UIs is seeing a drop down list (select tag) in a form with only a single option in it. As a user you have to click it to see the other available options only to find that there are none. This is a clear example of developer convenience being put before user experience.

I’m sure it seems obvious now I’ve highlighted it but if there’s only one option then there isn’t a choice to be made at all and we don’t need a form input. The code should conditionally show the drop down list only when there is a selection to be made, more than one item.

Depending on the UI design, we could even take this a step further. Maybe a drop down list isn’t the best choice for selecting between 2 items? A radio button list is probably better as it enables the user to see all of the available options at a glance and make a selection with a single click/touch. We can test the number of options and if it’s below 5 show the options in a radio button list. <ol> might be a better choice than <ul> for the list if the items are in a specific order, e.g. years.

Another example I see is displaying disabled form controls where the control is never enabled, e.g. a checkbox which is disabled because the user doesn’t have permissions to change it. If it’s not an option, don’t show it. Disabling it is the lazy option, easy for the developer. Hiding it is much better but may involve a change to layout. The UX should always be put first. It’s usually no more difficult, it’s just not considered.

A/A Testing

I’m guessing most people know what A/B Testing is. It’s publishing 2 variations and monitoring the responses. A typical example might be a web page with a sign up call to action. There would be 2 versions of the page and visitors would be directed to one or the other. After a certain number of page views the number of sign-ups would be counted for each version. Version A might have had 4% sign ups whereas version B might have had 7%. Typically, the best performing page is then either used or put up against another version for another iteration of improvements.

A/A Testing is the control. Visitors are again directed to one of two pages only this time both versions are exactly the same. Let’s call them A1 and A2. Suppose A1 comes in with 5% sign-ups but A2 comes in with only 1%. What does that tell us? It basically tells us not to read too much into the A/B Testing as the differing results were probably just random chance.

With A/A Testing, as you monitor more and more users the split should get closer to 50/50. It’s a good way of discovering what is a suitably large sample size for your A/B Tests.

The other problem with A/B Testing is its format. It’s often set up to work like a knockout, winner stays on tournament – A vs. B, B vs. C, C vs. D, etc. This is flawed. If B beats A, then C beats B, C is the winner. But what if A would beat C? It’s quite possible. For it to work all variations need to put pushed out at once so we’re now doing A/B/C/D Testing and this will require a larger sample size.

Personally, I’m not convinced it’s very scientific in most cases. I think it can work well if you’re Amazon or Google and have the traffic to get meaningful results but most companies using A/B Testing probably fall way short and are more or less flipping a coin to make their UX decisions.

A/A Testing is a great way of debunking small scale A/B Testing as it proves that random chance plays a significant part in the outcome.

Click Fear

I recently read this excellent article by Jakob Nielsen:

The Distribution of Users’ Computer Skills: Worse Than You Think

It highlights just how bad most people are with using software and websites and how we should not judge our users by our own standards and preferences. As I read it I thought to myself that I don’t really know anyone with poor skills – everyone I know is pretty good at this kind of stuff. Later the same day I was proved wrong.

I got a call from a friend asking for my help on going through a process online. The options provided seemed obvious to me, even over the phone. They described what they wanted to do and then the 2 options on screen. The first was an exact match for their intention; the second something completely different. It made me realise that it’s often not so much a case of not understanding what to do as being afraid to commit to it and wanting that extra reassurance.

Some people have a fear that once they’ve pressed a button that’s it and there’s no going back and they’re scared that they may make the wrong choice. I’ve noticed that a lot of websites have “call to action” buttons with text like “Sign up” or “Buy now”. For these users with the fear, this could be a red light – they will see that action as a commitment they may not want. Those of us who know, know that this is just to initiate a process rather than to commit to it. It might be prudent to be cautious with actions and reflect more faithfully what will actually happen.

There shouldn’t be any need for this fear. Anything that can be done can be undone, or changed later. Well, almost anything. I can think of a few instances where choosing a username is a permanent choice but it’s usually made clear if something cannot be changed.

To use a not-particularly-thought-through analogy, navigating through any kind of process online is a bit like driving around a car park. Whichever route you take you can always loop back around and get back to where you were. Worst case scenario – you can always exit and enter again.