Danny-T.co.uk

Tony MacDonell of Teknision has a great post over on InsideRIA about The supply and demand of user experience.

I left a comment there but whilst it’s in moderation but it’s raised some more thoughts for me so thought it deserved it’s own post.

Tony writes about how an investment in user experience is driven by supply and demand of said experience. In slow moving uncompetitive markets, this added value of a slick user experience isn’t necessary and therefore is unlikely to receive heavy recognition and investment. You only need to look at many banking systems, trading platforms and data entry software to believe this is the case (N.B. these being slow movers rather than uncompetitive).

Tony also mentions the example of router interfaces as something that blatantly receives little UX attention because it’s more appropriate for router manufacturers to compete on price rather than improving user experience.

The general cycle of things seems to be as follows:

1 - New product enters market, has no competition, focuses on functionality over form, it works, it does the job, reaches x% of market.
2 - Competition appears, attention on products grows, market grows, slice of pie desired grows, product’s prices reduced.
3 - Prices reach lowest reasonable point, value needs to be added, user experience rears its head, flash/flex guy gets a new contract.

This sucks. And in my view is stupid. At point 3 we’re still trying to generate more sales/users/whatever so we try to build desire through improving the product experience. Yet we’re now making less per unit than ever before.

Had we invested in a suitable UX in the first instance the costs of doing so would have been less (I.e. not having wasted time and money on the first iteration crappy implentation), we’d have a much better, more desirable product, we’d have benefited from the additional interest whilst we’re charging a premium and we’d be raising barriers to entry for any future competition.

You could argue the new interface extends the product lifecycle which would otherwise have dropped off sooner but in my opinion the advantages of doing it right first time far outweigh that.

Adobe’s Ethan, Ted and Ryan recently gave a big thumbs up to Firebrand an RIA for watching adverts.

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 been tasked with planning a real (as in get a load of people together) forum focus group (edit: I think focus group is a better term than forum) for assessing the usability of a website. I’ve always wanted to do such an excercise but to date none of the projects i’ve worked on have either had the budget or appreciation for the value of such a task.

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.

Larry Constantine writes about an alternative to User Centred Product Development (a development approach focusing on users). The discussed alternative is Activity Centred Development which moves focus towards the job in hand that is to be done by the users.

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

Last month myself and Colin travelled up to London to attend the LFPUG and saw two excellent presentations from Rob Bateman and Tink.

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.