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'

The Holidays are well and truly over!!

After a nice and mostly relaxing break over the Christmas holiday period, where I spent a good deal of time watching Australia take on South Africa in the cricket, I started back at work on the 9th. In the lead-up to the break there'd been signs of a build up in demand for Web development services - across the board: design, IA, strategy, development - and I was expecting a busy start to the year.

Instead, it's been more than simply busy. I haven't seen the year start off in this way for nearly five years. And I'm not alone. All across the local industry we're seeing the same thing: companies with more work than they know what to do with; and difficulty finding experienced staff.

Clients are expecting more than they have previously, but not without expecting to pay for the service. Happily, among the most frequently-asked-for 'extra' are information architecture and user experience services, a sign that the Australian market has well-and-truly caught up with the global trend we've been witnessing for the last few years.

The local IA professionals I've spoken with have uniformly seen the same increased demand for their services, which further supports the belief that this is neither isolated nor short-lived.

Closer to home I've been working on formalising an integrated UCD approach that places more emphasis on the characteristics of the clients' business as a means of counter-balancing the requirements derived from direct user research. Perhaps counter-balance is the wrong word. It's more a sense that those user requirements can be addressed in a variety of ways and the most appropriate way for a particular business is that which is most closely-aligned with the characteristics of the firm.

Anyway, you may get the opportunity to read an article on the subject in an up-coming issue of UX Matters (www.uxmatters.com) - if I can produce a draft worthy of being published!

That will have to be all for now, but if I can I'll post some exerpts for comment.

Bye for now.

'Doc'