Often, the UX design is considered to be mainly a creative process, undertaken as part of the graphic or web design phase of the project. It is then down to the developer to implement the UX as specified.

In this case, I’m building the back-end functionality first but that doesn’t mean I don’t need to think about making using the application a smooth painless experience, regardless of what improvements will be made as part of the front-end design.

Key Idea – Remove Barriers

To make interactions as painless as possible, I’ve sought inspiration from not only web applications but also desktop and mobile apps.

• Adobe Air has given flash developers the capacity to create and publish desktop applications. These guys are often at the forefront of designing great user experiences and it shows in the slickness of many apps.
• Apple’s iPhone has thousands of applications available and the limited screen size combined with the touch screen interface has resulted in some interesting new application design conventions. The native applications such as e-mail and the iPod interface present examples of functionality honed down to just the most essential interactions.

Example #1: Registration

In the conventional scheme, a user would enter their registration details, receive a confirmation e-mail, activate their account and then login to the site. This is often required even for a free trial of the application.

Automatic Login

I’ve built the registration system so it will automatically log the user into the app once their registration has been successfully processed. Rather than wait for an account activation, I’m doing a simple check to ensure the mailbox for the e-mail address that they entered exists. If I wanted to use an activation code, I could add a grace period during which the user could use the application before requiring an activation code to confirm the account.

Trial without registration

I’ve coded my app so the user can dive straight in and try out the application (in a limited form). All the data that they enter is held in a session cookie so if no further action is taken, it will expire soon after the user leaves the site. If the user decides to go ahead and register, all the data entered in the session is recorded into the database against their new account. This, combined with the automatic login provides a seamless transition from free trial to registered user without having to re-enter any information.

Example #2: Item Selection

One part of my app involves selecting an item from a list. It’s unknown how many items might be in the list so the conventional developer solution would be to create a drop-down list with either an automatic update when an item is selected or a button to confirm the selected item.
I see problems with each of these approaches, a drop-down list could potentially be quite long, requiring scrolling to navigate. If the user accidentally selects an item while scrolling, an automatic update is unforgiving. The use of a confirm button negates that problem but needs an additional interaction after the user has found the item that they were looking for. The confirm button becomes an unnecessary obstacle in the flow of the application.

One click selection

My solution is to generate a list of links, each of which can be clicked to make the selection. Initially this looks like a good solution for small numbers of items, but bad for longer lists.
The reason that I’ve chosen to go this way is that the mechanism is good, a single click once you’ve found the item. How the list is presented can be tackled as part of the front-end design. In this case I might use something like the jQuery ListNav plugin from iHwy Inc.

Some Tips

While in development mode you can improve user experience by making choices based on mechanisms and functionality, not on presentation. If, like my current project, you don’t have a specific design to work to, these tips can still make a difference.

• Look for inspiration – A good designer will keep scrapbooks of design elements, textures, colours, shapes etc. similarly, you can make a note of good experiences from any source, not just software applications – video games, information kiosks, gadgets, DVD players, whatever makes you think “that was simple/easy/nice”.
• Create a smooth application flow – remove unnecessary steps wherever possible. A single click to advance creates momentum rather than an obstacle to overcome.
• Don’t think about presentation – provide all the required output for building the front-end design. Strong front-end UX design should build on good application flow rather than try to impose it on to cumbersome application functionality.
• Follow people logic, not application logic – Think of the simplest path from one application state to another, regardless of whether it matches your database schema or object methods.
• Conventions are compromises – tried and tested conventions only became so because most people have come to accept them. At some point in the past, somebody went out on a limb and built them first. Don’t be afraid to break convention if it makes sense to do so.

Working on code is generally a hyper-focused task. I usually find that what I’m doing is writing the code according to a mental model of the program that I’ve constructed. When I get interrupted – even just to answer a question, that mental model dissolves and I need to spend 15-20 minutes reconstructing it before I’m back up to the level of productivity I was at prior to the interruption. If interruptions occur within 15 minutes of each other, productivity can drop close to zero – ever had one of those days when you feel like you’ve got nowhere?

For dealing with interruptions there are various techniques you can use. some examples:

Block everything out

I like to put my headphones on and play something loud enough to blot out all noise. For people who find music too distracting, I know a developer who wears noise cancelling headphones without playing any music just for the effect of making outside noise indistinguishable.

Make it clear

Let people know that you are “in the zone”, tell them, put up a sign, wear a special hat or even all three. If somebody is hanging around near my desk then sometimes I have no choice but to try and obviously ignore them – I don’t want to be rude but sometimes it just doesn’t seem worth breaking a good flow of work to look up a password for somebody who can’t be bothered to search their email inbox.

Switch off distractions

If I can get away with it, I close my email client, switch my phone to silent and ignore them until I choose a suitable time to “come up for air” e.g. lunchtime and then deal with emails and missed calls all in one go. I had a manager who did a similar thing – he made it public knowledge that he only dealt with email between 9 and 9:30 in the morning so any email sent after that time wouldn’t get a reply until the following day. His reasoning was that if something was really important then people would phone him about it.

What’s the cost then?

Given that in my company, we work to estimated timescales, it can be very important to either minimise interruptions or take them into account when estimating development time. I’ve had fairly basic tasks which should have taken no more than a couple of hours, go on for a couple of days due to ongoing requests for information, opinions, meetings, conference calls etc.

I’ve also had programming tasks where the time taken to provide ongoing status reports on request actually exceeded the time spent doing the work.

Now I’m not suggesting that developers should be left entirely alone to get on with tasks as they also have a duty to keep managers informed of progress, I just wonder if anybody has a good method by which developers can schedule their interruptions and not get stuck in zero productivity hell.

Here’s what a few other people have to say on the subject, following a brief prayer at the altar of Goog:

• Jason Fried – Getting in too-much touch (interruption is not collaboration)
• Brett Kelly – 6 ways to limit interruptions at work (that you can use right now)
• Joel Spolsky – Where do These People Get Their (Unoriginal) Ideas?
• Stephen Jenkins – Concerning Interruptions

From the reviews, Peopleware: Productive Projects and Teams appears to be a good book with views on this subject and I’m also going to make time to read some of the research work collected at interruptions.net.

I’m interested in hearing anybody else’s thoughts or findings in this area.

In web design, it doesn’t take a huge amount of time or effort to try things out. We are blessed with an infinite playground in which to let our imaginations run riot, and yet there are still those who would rather crank out the same work time and time again.

It seems to me that doing something in a particular way just because somebody else did it that way is lazy. We can only progress if we question ourselves at every step and then ask ourselves if the question is the right one. At least if we look for alternatives, or at least try and fail to make improvements, we are pushing at the edges of what is possible and one day might find ourselves breaking through into new territory.

Doing things the way Dan Cederholm, Jeffrey Zeldman or Eric Meyer do may work as well as anything, but you can’t be sure that they have discovered the best methods for everything – why else do they continue to innovate and refine their own techniques? I’d be surprised if any of those guys had ever put together a web page and then sat back and earnestly declared it to be the best page that had ever been or ever would be created.

Just as it seems to be something of a sport to pick apart anything said by Jakob Nielsen concerning usability, I refuse to blindly accept any web design technique from somebody else (even a self-appointed emperor guru like Nielsen). I have an in-built need to test and tweak until I’m satisfied that it will do the job – at least for the time being.