I’ve been taking an increased interest in the “tech startup” trend that has been occurring over the past few years and this concept is especially pertinent for anyone trying to make a success of a startup. If your startup is going to take on Goliath corp. then feature parity should absolutely not be the goal.

I’d even argue that if it’s possible to compete on a single key feature and ignore everything else (which is likely to be falling somewhere within Pareto’s principle) then you’re very likely to be able to offer a far simpler, far superior product.

Of course there is a lot of context dependence on such a statement but certainly for a startups consideration then it’s much easier to compete on a single feature than many. I’ve written similar thoughts on the Moov2 on Business Software blog in the past but it’s recently returned to my attention.

Always assume the call you’re making will work.

Some context for the above, I recently got sick of my iPhone and decided to give Android a spin, side-stepping the obvious discussion here, one of the things that has irked me about the Android experience is that it just doesn’t feel as responsive as the iPhone for certain applications, specifically email. So I started to compare the two and realised that the iPhone reacts to my interactions immediately whereas Android seems to wait for approval from the server. This eye-opening discovery led to me imposing a new standard here at Moov2:

Every user interaction must have an immediate and obvious reaction.

Proud and smug feelings of wearing my user experience hat were soon interupted when challenged to explain wtf I actually meant by this. So, for example, deleting an email from a list of viewed email messages. When I hit delete I expect that message to be removed from the list and if that happens as soon as I press the delete button, I’m a happy chap. Conversely, if I have to wait, even a couple of seconds, I may think I missed and try hitting it again… and again… etc. So developers, quite simply, as soon as that delete button is hit, remove the message from the list and THEN send your call informing the server to do it’s part. This approach can be applied to pretty much any application development that involves a rich user interface, Flash, Flex, Silverlight, AJAX, Android, iPhone, native desktop apps and whatever.

But what if something goes wrong?

Of course, just throwing the message away willy-nilly is reckless, there’s a whole host of things that could prevent that message from being deleted. The user might be offline, the email list might not be up to date or there may just be some other bug elsewhere making the delete email process just plain not possible at the moment. In this case, sheepishly, politely and unobtrusively, let your user know the fact and pop the email back where it came from. This will obviously be a nuissance to the user, but how often does this really happen in comparisson to how often it works? Very rarely, and it’s no less annoying for the user than having to sit there waiting with no response only to find out the action failed.

What if I NEED the response in order to update the UI?

So deleting is a fairly convenient example because we’re taking away from an already viewable interface, what about if we’re adding to our interface based on the response from our call? For example displaying the list of emails in the first place. Well, for this I suggest you present all of the interface elements that you know are going to be available and just provide some indication that something else is going on to reassure the user that their input has been acknowledged. So when the user chooses to view their inbox, immediately react and change the view, present them the ‘Inbox’ title, show them any user controls they might be able to interact with and display the space those messages are going to load into with some form of preloader/spinner and note indicating their messages are being retrieved.

So take a minute and review your result handlers to see how much UI stuff is being done there. Could it be moved to before the call was made? This sometimes means you need to think about how to best back-track when things go wrong but for the 95% of the time when you just get the result you’d expect you’ll deliver a MUCH more responsive feeling interface that your users will thank you for.

By the way, if you’d like to actually see some code demonstrating this concept tweet the following message to Pete who has prepared a very clean implementation of this for a Flex application we’re currently working on: “Hey @peterkeating, codez pls http://bit.ly/f8HOyp. I’m sure he’ll oblige with a sample soon enough.

Below are some key questions you should be asking about your data retrieval process with regards to user interaction:

Do I need to stop the user interacting?

Should the user be able to continue working whilst the application retrieves this data? For example, loading your latest company news via an RSS feed into your applications home screen should not prevent them from doing anything they are actually there to do. However, if a user has just selected an entry from a list they wish to make ammendments to its understandable they might not be able to do so until that entity has been fully saturated into the application.

Does the user need to know what is going on?

Is visual feedback required for the user to continue productively using the application? Typically if the data being loaded is as a result of an interaction instigated by the user then probably. If however you’re doing some form of background data loading then it may be sufficient to surpess any distracting feedback unless the user interacts with that part of the application. For example, if a search facility needs to build an index and the user doesn’t try to search, they don’t need to know about it. As soon as they try to use the search facility a user-friendly message to indicate the search is being prepared only then becomes relevant. Note: “Search index compilation in progress” is most probably NOT a user-friendly message, pick a tone and language most appropriate to the intended audience.

Should the user be able to cancel?

Unfortunately, some operations have to take a long time. Obviously any efforts made to reduce the time of intensive processes are well placed but, if after you’ve squeezed every possible millisecond of performance out of a hefty process it still takes a long time then the least you can do is offer the user a means of cancelling that process.

Niels Bruin responded with what I think is a very good wake-up call to the starry eyed approach to reviewing web apps with lots of transitions, reflections and other shiny bits. Niels highlights some real basic usability faux pas that Firebrand made such as mystery meat navigation, red punishing looking confirmation messages and inconsistent design touches.

To be honest, I read all the commotion and Niels put down before I looked at the site and to be fair to Firebrand I probably wouldn’t have picked up on those points myself. But then I’m not and would not claim to be a UX hotshot of any kind. The key point for me is that the points raised by Niels do not require a magical usability eye and could very easily be a printed checklist and implemented as part of a quality control assessment before final delivery of a product. To be fair I do also agree with the points Ryan makes in his followup and I’m also all too familiar with things such as expectation and deadlines which can all to easily prevent this much-needed attention to detail. However, if we keep reminding ourselves of it then hopefully it will become second nature and not needed as a time consuming afterthought.

If you’re responsible for the creation, delivery or quality of a customer facing project, take 20 minutes, open up your word-processor of choice (perhaps use it as an opportunity to try out Buzzword) and hack together a simple list of quality control checks.

Here’s a handful of checks plagerised from Niels post and an old post I remembered by Aral to get you started, copy the below and paste into a document, print out 10 copies, run through your current project and tick each one off and you’re well on your way to becoming a quality control engineer!

Niels’ Firebrand wrist-slap:

• Make sure any icons/metaphors are extremely obvious or explained with tooltips or other indicators
• Make confirmation messages look positive and warnings look like warnings (I.e. don’t positively confirm an action in red)
• Is everything laid out consistently? How much effort would it really be to tweak that button a few pixels to line up properly?
• Can familiar controls be used in a familiar manner? E.g. can I scroll a scrollbar using my mousewheel, drag it and click up/down arrows?
• Have you tested on all likely platforms/browsers? At least WinXP, Vista, Linux, OSX with IE6 & 7, Firefox, Safari, Opera

Aral’s old post on UI principles (interpretation by moi for checklisting purposes):

• I can use it but am I a ‘typical user’? Even better: can I get an intended user (or several) to use it?
• Does validation “prevent not scold”? Does the user get scolded “YOU IDIOT, WHY DIDN’T YOU SELECT A GENDER BEFORE CLICKING THAT BUTTON?!” or do we just make the button un-clickable until the gender has been selected with some unobtrusive instruction to do so?
• Does the user receive sufficient feedback? If the user makes an interaction, is it obvious that interaction has been acknowledged by the app and the expected result has happened? (see Niels point on adding to faves).

There’s a load of other things that can be added to this list, for generic testing and I’m sure for specific audiences/companies/application types etc. I’m going to do some digging on other principles people have come up with as I know there are a ton out there but whilst this is topical I thought I’d add my opinion and throw in a call to action to anyone reading.

I’ve a few ideas and some textbook definitions of what such a forum should consist of but I thought I could come up with something far better if I abuse leverage the full potential of the MXNA audience.

My current plan is as follows:

Sessions
We need to do four sessions, i’m thinking about 5 attendees per session and about an hour per session. Any longer and I think we’ll struggle to get people to attend (even with a token financial incentive).
Will hire a private room with no distractions.

Setup
Am going to setup ‘caves’ (XP speak for private single PC desks) with remote monitoring software so I (or the facilitator) can watch but not interfere with user operation. This is so we can replicate how they would likely use the site if they were using the site for real.

Monitoring
Each attendee will be given 5 minutes to familiarise themselves with the site with no other instruction than play around and see what you find. Then 10 minutes to complete a set of tasks.
I intend to have a list of objectives I can assess each user on by giving a score out of 4 on their competence in using the site (using 4 not 5 so there’s not fence sitting, it’s either Very Bad, Bad, Good or Very Good) also note any other relevant observations.
I’ll also probably record the screens and maybe the user themselves for the option of further review later.

Discussion
Once all 5 have used the site we will move to a ‘commons’ area where the group can have an open discussion about their experience in using the site. I’ll have some leading questions for if the conversation needs any steering or kick-starting but I’d like to keep it as much led by the attendees as possible, whilst I can make claims of being the usability guru, they are the users and will have a far more valuable collective opinion than my own blinkered, tech-led view.

Your Help
I’m interested in any comments you might have on the rough approach outlined about, any suggestions you can make to add to, remove or improve.
Ideas on what to look out for when monitoring users.
The biggest unknown to me is where to get the attendees from, we have some ideas but it’s not something we’ve been tasked with before, if anyone knows of any London-based companies who can arrange this type of thing then i’d be interested to know.
Also any ideas on how to summarise findings and make recommendation, I’m goign to try to record and note as much as possible from the sessions so any decent ideas on how to best summarise and present findings would be much appreciated.
And finally if anyone has any useful references for this type of activity that would also be very useful.

If anyone can offer comment I’d be extremely grateful and I’m intending to blog the progress and findings as we go.

Some interesting points that stand out to me:

Designing for use rather than for users is a way to focus design more sharply.

“Focus upon humans,” he wrote, “detracts from support for the activities themselves.” The result can be cool technology that doesn’t work and complex applications that don’t help people do the stuff they need to do.

paying too close attention to users and what they say can lead to timid, overly conservative design that does little more than repeat the mistakes of the past in a pretty new package

A third problem with users is that there are so many of them. And they are all different. They want different things and like different things and react differently.

I think that some of the argument touches grey areas that a good user interface designer/application developer can assess for themselves but overall an interesting view on the focus of application development.

Read the full article here

During Rob’s presentation on Optimising visual interfaces for the human brain something was brought up that I hadn’t considered previously; the difference between “Intuition” and “Conditioning”. This wasn’t a major part of the presentation but something that got me thinking nonetheless.

Intuition, for the sake of this discussion, is similar to instinct, they are a form of common sense that perhaps cannot be associated to any specific learning experience.
Conditioning, is a more manufactured type of action that we may perform, we’ve been told to do it this way, we’ve been doing it like this for some time, so when we want to do something, we’ll try to do it this way.

The above are two very crude explanations, I have no psychological knowledge and so have drawn these explanations from the presentation last month and some brief further reading. Please feel free to offer any comments below, agreeing or otherwise.

Anyway, what has this got to do with interface design? Actually quite a lot I have realised. Usability is obviously a very important factor of interface design, the user has got to instantly feel comfortable with their environment and almost know where to look and what to click in order to achieve a desired action. Even if they have never before performed this action. When designing an interface, we have to make a concious decision on whether we feel it is appropriate to target a user’s intuition, conditioning or both or even if there is a distinction between the two.

This is perhaps best explained by example, of which there were several in Rob’s presentation which I am unashamedly going to borrow.

Here are two “OK” / “Cancel” dialogue prompts, one is for Mac one is for Windows. Despite aesthetics, the fundemental difference between the two is that for Mac the Cancel option is to the left, for Windows this is to the right. Aparently, the rationale for Mac putting their cancel button on the left and the OK button on the right is because it is synonomous with the Escape and Return keys on a keyboard. I would assume the Windows approach is based on the typical left to right reading and expected order of events, confirm or reject.

Another example is one I thought of whilst getting my mind in knots trying to get my head around this. If I were to launch a completely new program, with a save option, it would be perfectly reasonable for me to offer access to the save feature by way of a floppy disk icon. Why is this? Is a floppy disk icon the most intuitive approach? No it’s probably not, I’m sure many new and younger computer users wouldn’t even know what a floppy disk was (maybe most would at present but give it another few years), when was the last time you saved to a floppy disk? This is what I would consider conditioning, we’re used to doing it this way so we’ll continue to do so even if it might not be the most appropriate approach for new and future users.

I’m not sure there is a distinct line between intuition and conditioning. It almost seems as if they are both results of a way we get used to doing things only intuition is more towards being hard-wired as part of who we are as opposed to conditioning being something we are more recently used to doing. Thats not to say i think intuition is not affected by our development within our individual surroundings. For example, would someone who reads arabic, or other right to left language, expect to see the first option on the right, second on the left? Do operating systems even take this into consideration in translated versions? It’s all food for thought but definitely worth bearing in mind when thinking about your application audience. If you get a chance do check out the online video of Rob’s presentation as there is a lot more interesting and useful information about much more than just intuition.