Black is back

I've become aware of a rather strange anti-usability movement amongst consumer electronics manufacturers. It's an underground movement - you won't see these 'features' in their advertising - but apparently gaining momentum.

My wife and I recently purchased a new DVD player - a fairly middle-of-the-road replacement for our old one which had developed several glitches. The player is a Pioneer model and works extremely well except for one annoying feature: the open/close button on the player itself is a black button set into a black faceplate. Sitting here, about 12 feet from the machine it's impossible to see it. It isn't labelled; it's the only black button on the player.

Of itself this wouldn't constitute a trend, but we have just finished setting up a new Canon photo-copier/scanner/printer. When we started setting up the printer it was late afternoon and the light was a little low. (The room we were in was suffering from several blow lightbulbs.) We reached a part of the instructions that spoke about the 'Open' button so we looked; and looked. I eventually changed the lightbulbs and, in the enhanced light, saw the open button: on the front of the machine, which is mostly black with silver trim, is an unlabelled black button, set flush on the black faceplate. This black button opens the output tray. It's the only unlabelled button on the printer.

When I was younger my parents, teachers &etc used to espouse the view that working for something would make us appreciate it all the more. It appears that the product designers at Canon and Pioneer hold the same views, which is kind of sad.

User requirements need to get precedence

Over the past five weeks we've been working on an information architecture and user experience project to design the interface for an internal business application for a client. They have their own development team and business analysts, but no IA, so they asked us to assist with the interface.

Our brief was to interview the end users of the proposed system and gain an understanding of their needs from the application; how they work; how they'd like to interact with the data; their needs for reports and the like; and to encapsulate those findings into a series of wireframes for the system. At the time we were engaged for the project the Business Requirements had just been finalised, so we appeared to be starting out on the right foot.

The day after we commenced our user research we received the first draft of the functional requirements for the system.

Now, generally I would expect a fair degree of user research to be carried out before any work commenced on functional requirements - particularly elements like workflows and the like - but it quickly became evident that our actual role in the project was more symbolic than it was central. Suggestions for changes to the workflows based on user feedback were dismissed; arguments about user work practices being in conflict with the functional requirements were bandied back and forth without ever actually agreeing that the user's perspective was actually inherently more valid than the internal business analyst who would never use the system.

My belief is that the functional requirements for a system should not be written until after initial user research has been completed so that user requirements can be integrated into the specification rather than overlaid onto an existing view of the system. If all the user experience professional is doing is modifying button labels and the placement of form elements from a pre-determined set of elements, then the impact of their knowledge, research and expertise is being severely undervalued and undermined.

In most cases the functional requirements should be driven primarily by the user requirements and balanced against the needs of the business to ensure project objectives are being met - not the other way around. The likely outcome of driving the functional requirements from the business requirements - with a dash of UED thrown in - is a system that dictates to users the functions they can and will carry out, and will be poorly-received by those users as a result.

I don't hold out much hope that the end result for this project will be a thrilling experience for the users, who welcome the improvements to their work practices that it brings. At this point it feels more like a backlash against head office prescriptiveness waiting to happen, and that's a shame given the amount of effort going in to eking out each small interface improvement we can. We're fighting small battles around the fringe rather than the major battles in the centre and that doesn't provide for good user experiences in the main.

How hard is it to change your name?

My new wife has spent the last two weeks researching what she needs to do to have all of her accounts, records &etc with insurance companies, banks, motor registry office and work updated to show her married name. She put together a very detailed spreadsheet for each company showing what information she needed to present, proofs etc and where she could go to make the change be it online or at one of the branch offices.

Last Friday she went about visiting those Web sites and branch offices attempting to get her name changed and it's been interesting to see just how easy or difficult it has been in each case. In some cases, the online forms have been so poorly designed and implemented that she gave up and called them. Vodafone, for example, presented an unsecured form, poorly labelled, which required the user's account security code for submission.

Mostly, it was pretty straight-forward. The motor registry (our RTA) visit was painful only for the amount of people present, but in less than an hour she had a sparkling new license. NRMA was also painful, but in their case because the counter staff chose to use their lack of systems knowledge as an excuse to chat to the support staff about their plans for the weekend and the weather. In a much longer period than should have been required, those accounts were updated as well. The staff also fully expected my wife to be lacking some form of documentation required, and so approached the whole exercise with the slow, methodical questioning aimed at discovering exactly what it was she'd forgotten.

St George, ING and the Teacher's Credit Union were all painless, quick and trouble-free and only one of those were carried out online. Which goes to show that a good service process doesn't always have to be an online one.

'Doc'