More about product design...

Just to balance my karma a little after my last gripe about product designers, I have to make mention of the FujiXerox printer that recently came into my 'possession'. A3, double-sided, colour laser printer. Networked (via Ethernet), three trays... all the things you want in a printer.

Installation and configuration took under 10 minutes from opening the box to first printing. That includes time spent exclaiming over the size!!

For those interested in such things, it's a DocuPrint C2428.

Lovely; easy; efficient.

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.