User Experience Done Quick

They say that beauty is in the eye of the beholder – that is never truer than when thinking about user experience. Whilst having a great looking web site with glorious fonts and beautiful pictures might seem to be where we should be heading, is it all that we have to think about? (Hint: answer is no!)

What users _really_ think is beautiful is having a system that lets them do what they want to do quickly and easily without getting in the way. How intuitive is to an average user - not to some geek with a Comp Sci degree who thinks the command line is UI nirvana! Many web sites and back office systems look great but, frankly, are just annoying to use because you have to do an extra click or two to get to the key information, or users are faced with screens that sometimes seem to “hang” for no apparent reason when you make a request. Users feel that performance just does not seem to be consistent and that is annoying.

How do we know how if that extra cool feature we just added is really getting in the way? We are lucky in working for a smaller company. We can go just go and talk to users and watch them at work. See if you can get to speak to some of our site users, go sit with the traders and watch what hoops they have to jump through, look at the steps the marketing guys have to do to get content onto the site. Think of it as social networking the old fashioned way. Would you want to have to do all those extra clicks if that was your job? How might we change the order of events to make it easier? What can we _remove_ from the system to make it faster for users to get _their_ job done.

We have now managed to remove loads of “features” – great. What next? How fast does the user _think_ the system is? Perception matters here and anything you can do to make a user think a system is faster than it really is, has got to be A Good ThingTM. Human reactions mean we can’t really tell if something takes less than 100ms (give or take) to appear but we sure can tell if it takes longer. How fast can you get the system to start responding? It doesn’t have to be the whole page immediately – just something to let the user know stuff is happening. See if you can make that response time consistent. How about setting an SLA of a page must render in 250ms. What guarantees does that mean we need to ask for from systems further down the food chain? If the response takes longer than 250ms what will you do? Rather than building a page sequentially can we do it in parallel and make multiple calls at once? Many large sites will “degrade” gracefully if their backend systems take longer than a certain amount of time to respond. Can’t get a response from a sub system? How about returning some default text saying “oops something is slow at the moment, we are dealing with it” in that area of the page.

One of the biggest annoyances people have with a system is when they hit a button and then have to wait, and wait, and wait, and wait for something to come back. Has the system crashed?, Did it really get my click? WTF? Often this type of behaviour is caused because a synchronous call has been made and everyone is blocking on the return value. The system might be slow due to extra demand or a sick server. The impatient user doesn’t care, he now hits the button a second time or opens up another copy of the app to repeat the process elsewhere – merely adding more load to the system and making things worse. So what can you do? Try turning your synchronous call into an pseudo asynchronous one. How about making the initial request start an asynchronous process and return a fast response which gives a URL of the where the end result can be found. Have the user poll that new URL for status updates –> pending, pending, pending, final result returned. Behind the scenes you have handed the request off to another process to deal with and that will update the URL when it is finished. This set up means that the user is not blocked waiting for a response, the behind the scenes system can be scaled independently, requests for the same information can be returned the same polling URL – meaning only one process has to deal with it and hence reduce peak load – irrespective of how many clients are calling. Don’t be constrained to think in a sequential manner if it means that the user gets a meaningful response faster.